DRIVER_POWER_STATE_FAILURE (0x9F) beheben: Bluescreen beim Ruhezustand

Der Stopcode DRIVER_POWER_STATE_FAILURE (0x0000009F) unter Windows 11 und Windows 10 schlägt fast immer beim Einschlafen, Aufwachen oder Herunterfahren zu: Ein Gerätetreiber reagiert nicht rechtzeitig auf den Wechsel des Energiezustands – den Umschaltbefehl zwischen „aktiv“ und „schlafend“. In den meisten Fällen steckt ein veralteter WLAN-, Netzwerk- oder Chipsatztreiber dahinter. Wer DRIVER_POWER_STATE_FAILURE beheben will, geht am schnellsten so vor: verdächtigen Treiber im Geräte-Manager aktualisieren oder zurücksetzen und den Schnellstart deaktivieren.

Woran du erkennst, dass wirklich 0x9F dein Problem ist

Der Fehler hat ein sehr enges Muster – daran lässt er sich von anderen Bluescreens abgrenzen:

• Zeitpunkt: Der Absturz kommt beim Übergang in den Energiesparmodus oder Ruhezustand, beim Aufwachen oder kurz vor dem Herunterfahren – selten mitten im normalen Betrieb.
• Bildschirmtext: Auf dem blauen Bildschirm steht „DRIVER_POWER_STATE_FAILURE“, oft zusammen mit dem Code 0x0000009F.
• Abgrenzung: Tritt der Absturz zufällig unter Last auf, ist es eher IRQL_NOT_LESS_OR_EQUAL oder DPC_WATCHDOG_VIOLATION. 0x9F hängt dagegen fest am Energiewechsel – das ist dein wichtigstes Indiz.

Technisch beschreibt Parameter 1 die Art des Verstoßes. Microsoft listet in der Bugcheck-Referenz zu 0x9F sieben Varianten; für Heim-PCs sind vier davon relevant:

• 0x3: Ein Gerät hat ein Energie-Anforderungspaket (IRP) zu lange blockiert. Parameter 2 zeigt auf das physische Geräteobjekt, Parameter 4 auf das hängende IRP – der häufigste Fall.
• 0x4: Der Energiewechsel ist beim Abgleich mit dem Plug-and-Play-System in eine Zeitüberschreitung gelaufen. Parameter 2 enthält die Wartezeit in Sekunden; im Microsoft-Beispiel steht dort 0x258, das sind 600 Sekunden oder zehn Minuten.
• 0x1: Ein Geräteobjekt wurde freigegeben, obwohl noch eine Energieanforderung offen war – der Treiber hat aufgeräumt, bevor der Energiewechsel fertig war.
• 0x5 und 0x6: Ein Gerät hat einen gezielten Energiewechsel (Directed Power Transition – Windows schaltet dabei einzelne Komponenten gezielt schlafen, etwa im Modern Standby) nicht in der vorgeschriebenen Zeit oder nicht erfolgreich abgeschlossen.

Für die Diagnose reicht: Ein Treiber hat den Energie-Befehl nicht abgeschlossen. Die Parameter helfen aber zu entscheiden, ob du eher bei einem einzelnen Gerät (0x3, 0x5) oder beim Zusammenspiel mit Plug-and-Play (0x4) suchen musst.

Den schuldigen Treiber aufspüren

Bevor du blind Treiber tauschst, grenze den Verursacher ein. Das lohnt sich: Laut Microsofts Analyse von Stoppfehlern gehen 70 Prozent der Abstürze auf Treibercode von Drittanbietern zurück, 10 Prozent auf Hardware und nur 5 Prozent auf Microsoft-Code. Diese Werkzeuge sind schon auf dem PC:

1. Energiebericht erstellen: Eingabeaufforderung als Administrator öffnen und powercfg /energy eingeben. Das Tool beobachtet das System laut Microsoft standardmäßig 60 Sekunden lang und legt die HTML-Datei im aktuellen Pfad ab – in einer Admin-Konsole meist C:\Windows\System32\energy-report.html. Bequemer ist powercfg /energy /output "%USERPROFILE%\Desktop\energy.html". Im Browser öffnen und die rot markierten Einträge unter „Fehler“ prüfen; dort tauchen Geräte auf, die den Energiewechsel stören. Wichtig: Programme vorher schließen, sonst verfälschen sie den Bericht.
2. Weckquellen prüfen: powercfg /a zeigt, welche Schlafzustände dein Gerät überhaupt kennt (klassisches S3 oder Modern Standby). powercfg /lastwake verrät, was den PC zuletzt geweckt hat, und powercfg /devicequery wake_armed listet alle Geräte, die das dürfen. Stürzt der PC beim Aufwachen ab, ist ein Gerät aus dieser Liste ein heißer Kandidat.
3. Ereignisanzeige durchsuchen: eventvwr.msc starten, unter „Windows-Protokolle → System“ nach kritischen Fehlern im selben Zeitfenster wie der Bluescreen suchen. Oft steht dort direkt der Gerätename.
4. Absturzprotokoll auslesen: Windows legt kleine Speicherabbilder (je rund 256 KB) unter C:\Windows\Minidump\ als .dmp-Datei ab, größere Abbilder als C:\Windows\MEMORY.DMP. Mit dem kostenlosen Tool BlueScreenView siehst du den auslösenden Treiber (z. B. eine .sys-Datei) ohne Debugger-Kenntnisse.

Fehlt der Minidump-Ordner oder ist er leer, schreibt Windows gar keine Abbilder. Das stellst du so ein: Suchfeld der Taskleiste → „erweiterte Systemeinstellungen“ → Reiter „Erweitert“ → unter „Starten und Wiederherstellen“ auf „Einstellungen“ → bei „Debuginformationen speichern“ „Automatisches Speicherabbild“ oder „Kleines Speicherabbild“ wählen → neu starten. Für Stoppfehler empfiehlt Microsoft außerdem 10 bis 15 Prozent freien Speicherplatz auf dem Systemlaufwerk – ein randvolles Laufwerk ist keine gute Basis für Abbilder.

Übliche Verdächtige sind WLAN- und Netzwerkadapter, USB-Hubs und Dockingstations, Grafik- und Chipsatztreiber sowie Energieverwaltungs-Tools von Notebook-Herstellern.

Tiefer graben mit WinDbg

BlueScreenView zeigt nur die oberste Treiberzeile. Wer den ganzen Gerätestapel sehen will, öffnet das Abbild im Microsoft-Debugger WinDbg (Teil der „Debugging Tools for Windows“), setzt den Symbolpfad auf den öffentlichen Microsoft-Symbolserver und tippt !analyze -v. Bei Parameter 0x3 gibt !devstack mit der Adresse aus Parameter 2 den kompletten Gerätestapel samt Treibernamen aus. In Microsofts eigenem Beispiel steckt dort ein USB-Eingabegerät (Treiber HidUsb) an einem USB-Hub (usbhub) – der Verursacher war damit kein exotischer Systemtreiber, sondern ein angestecktes Gerät.

DRIVER_POWER_STATE_FAILURE beheben – Schritt für Schritt

Arbeite die Schritte der Reihe nach ab. Lege vorher einen Wiederherstellungspunkt an (Startmenü → „Wiederherstellungspunkt erstellen“), damit du eine Treiberänderung notfalls zurücknehmen kannst.

1. Schnellstart deaktivieren: Systemsteuerung → Energieoptionen → „Auswählen, was beim Drücken des Netzschalters geschehen soll“ → „Einige Einstellungen sind momentan nicht verfügbar“ anklicken → Häkchen bei „Schnellstart aktivieren“ entfernen → speichern. Dieser Hybrid-Modus ist ein häufiger Auslöser, weil er beim Herunterfahren einen Ruhezustand-Trick nutzt (Details unten im Hintergrund-Abschnitt).
2. Verdächtigen Treiber aktualisieren: Geräte-Manager (devmgmt.msc) öffnen, das in der Diagnose gefundene Gerät suchen, Rechtsklick → „Treiber aktualisieren“. Sicherer als der Automatiklauf: den aktuellen Treiber direkt von der Hersteller-Website (Mainboard, Notebook, WLAN-Chip) laden und installieren.
3. Treiber zurücksetzen, wenn es nach einem Update begann: Im Geräte-Manager Rechtsklick auf das Gerät → Eigenschaften → Reiter „Treiber“ → „Vorheriger Treiber“. Ist die Schaltfläche ausgegraut, gibt es keine ältere Version zum Zurückrollen.
4. USB-Energiesparen abschalten: Energieoptionen → „Erweiterte Energieeinstellungen ändern“ → „USB-Einstellungen“ → „Einstellung für selektives USB-Energiesparen“ auf „Deaktiviert“ stellen. Ergänzend im Geräte-Manager pro Gerät unter Eigenschaften → „Energieverwaltung“ das Häkchen „Computer kann das Gerät ausschalten, um Energie zu sparen“ entfernen.
5. Weckberechtigung entziehen: Taucht in powercfg /devicequery wake_armed ein Gerät auf, das beim Aufwachen abstürzt, nimmst du ihm testweise das Wecken weg: powercfg /devicedisablewake "Gerätename" – den Namen exakt so übernehmen, wie ihn die Liste zeigt. Rückgängig geht es mit powercfg /deviceenablewake "Gerätename".
6. Windows aktualisieren: Einstellungen → „Windows Update“ → nach Updates suchen und unter „Erweiterte Optionen → Optionale Updates“ auch die dort angebotenen Treiber einspielen. Damit landen freigegebene Herstellertreiber auf dem System.

Nach jedem Schritt einmal gezielt testen: PC in den Energiesparmodus schicken, ein paar Minuten warten, aufwecken, danach einmal herunterfahren und neu starten. Kommt der Bluescreen nicht mehr, weißt du, welcher Handgriff gewirkt hat – und musst die übrigen Einstellungen nicht dauerhaft verbiegen.

Wenn der Bluescreen trotzdem bleibt

Lässt sich DRIVER_POWER_STATE_FAILURE beheben, ohne dass ein einzelner Treiber schuld ist? Oft ja – führen die Standardschritte nicht zum Ziel, verlagert sich die Ursache meist auf Firmware oder Hardware:

• BIOS/UEFI und Chipsatz-Firmware aktualisieren: Prüfe auf der Support-Seite des Mainboard- oder Notebook-Herstellers, ob ein neueres BIOS oder ACPI-Firmware vorliegt – veraltete Energieverwaltungs-Tabellen sind eine typische 0x9F-Quelle,, auch Microsoft rät in der Bugcheck-Referenz zum Firmware-Update. Wichtig: BIOS-Updates nie bei drohendem Stromausfall starten und die Anleitung des Herstellers exakt befolgen.
• Zuletzt angeschlossene Hardware entfernen: USB-Hubs, externe Festplatten, Dockingstations oder frisch verbaute Karten testweise abziehen. Verschwindet der Fehler, liegt es an diesem Gerät oder seinem Treiber.
• Systemdateien reparieren: In der Eingabeaufforderung als Administrator zuerst DISM /Online /Cleanup-Image /RestoreHealth und danach sfc /scannow ausführen. Die Reihenfolge ist kein Detail: Microsoft schreibt im Support-Artikel zur Systemdateiprüfung, dass DISM vor der Systemdateiprüfung laufen soll, weil sfc seine Ersatzdateien aus dem Komponentenspeicher holt, den DISM vorher repariert.
• VPN-Sonderfall: Tritt der Absturz nur bei aktiver VPN-Verbindung über PPPoE oder ein anderes Tunnelprotokoll auf, ist der VPN-Adaptertreiber der Kandidat – aktualisieren oder testweise deinstallieren.
• Ruhezustand komplett abschalten: Als letzter Test ohne Treiberwechsel schaltet powercfg /hibernate off den Ruhezustand ab. Weil der Schnellstart auf der Ruhezustandsdatei aufbaut, fällt er gleich mit weg. Bleibt der PC danach stabil, ist klar, dass der Fehler im Hibernate-Pfad sitzt; mit powercfg /hibernate on holst du die Funktion zurück.

Letzte Instanz: die Treiberüberprüfung

Bleibt der Fehler nach all dem bestehen und lässt sich kein Treiber isolieren, kann die Treiberüberprüfung (verifier) den Schuldigen erzwingen. Sie setzt verdächtige Treiber unter Stress und löst bei einem Fehlverhalten sofort einen Stoppfehler aus, sodass der verantwortliche Treiber im Speicherabbild auftaucht. Microsoft rät, nicht alle Treiber auf einmal zu prüfen, sondern gezielt die zuletzt aktualisierten oder bekannt problematischen – bei Bedarf in Gruppen von 10 bis 20 Treibern. Das Tool frisst CPU-Leistung und kann weitere Abstürze verursachen, deshalb nur mit aktivem Wiederherstellungspunkt starten. Kommt Windows wegen der Überprüfung nicht mehr bis zum Desktop, startest du im abgesicherten Modus, weil die Treiberüberprüfung dort nicht läuft, und schaltest sie mit verifier /reset plus Neustart wieder ab.

Warum passiert das überhaupt?

Für alle, die verstehen wollen, was im Hintergrund abläuft – ein klassisches Prüfungsthema rund um ACPI und Energieverwaltung: Wenn der PC schlafen geht, schickt Windows an jeden Treiber ein sogenanntes Power-IRP (I/O Request Packet), also einen Befehl, das Gerät geordnet in einen niedrigeren Energiezustand zu bringen (etwa von D0 „voll aktiv“ nach D3 „aus“). Jeder Treiber muss diesen Befehl innerhalb einer festen Frist bestätigen und an das nächste Gerät im Stapel weiterreichen. Verschluckt ein fehlerhafter Treiber das IRP oder blockiert es zu lange, bricht Windows mit dem Bluescreen 0x9F ab, statt das System in einem halb schlafenden, instabilen Zustand hängen zu lassen. Der Fehler ist also weniger ein Absturz aus heiterem Himmel als eine Notbremse – und deshalb zeigt er fast immer auf einen konkreten Treiber, den man aktualisieren kann.

Bleibt die Frage, warum der Bluescreen auch beim scheinbar normalen Herunterfahren kommt. Die Antwort liefert der Schnellstart, den es seit Windows 8 gibt. Laut Microsofts Treiber-Dokumentation zum Schnellstart meldet Windows dabei zuerst alle Benutzer ab, schickt dann System-Power-IRPs an die Treiber, damit sie ihre Geräte auf den Ruhezustand vorbereiten, und schreibt anschließend das Kernel-Speicherabbild samt geladener Treiber in die Datei Hiberfil.sys. Für die Treiber ist „Herunterfahren“ mit aktivem Schnellstart in Wahrheit ein Ruhezustand – mit denselben Fristen und denselben Fehlerquellen. Deshalb hilft das Abschalten des Schnellstarts so oft, obwohl der PC dem Anschein nach gar nicht schlafen sollte.

Quellen

• Microsoft Learn: Bug Check 0x9F DRIVER_POWER_STATE_FAILURE
• Microsoft Learn: Behebung von Stop-Fehlercodes oder Bugchecks
• Microsoft Learn: Powercfg command-line options
• Microsoft Learn: Distinguishing Fast Startup from Wake-from-Hibernation
• Microsoft Learn: Treiberüberprüfung
• Microsoft Support: Systemdateiprüfprogramm verwenden
• NirSoft: BlueScreenView

Häufige Fragen

Was bedeutet der Fehlercode 0x0000009F?

DRIVER_POWER_STATE_FAILURE heißt, dass ein Gerätetreiber den Befehl zum Wechsel des Energiezustands nicht rechtzeitig abgeschlossen hat. Windows bricht deshalb beim Einschlafen, Aufwachen oder Herunterfahren mit einem Bluescreen ab.

Welcher Treiber löst DRIVER_POWER_STATE_FAILURE meistens aus?

Am häufigsten sind veraltete WLAN- und Netzwerkadapter, USB-Hubs, Dockingstations sowie Grafik- und Chipsatztreiber verantwortlich. Der Energiebericht per powercfg /energy und ein Blick in die Minidump-Datei zeigen den konkreten Verursacher.

Hilft es, den Schnellstart zu deaktivieren?

Oft ja. Der Schnellstart nutzt beim Herunterfahren einen Ruhezustand-Trick und ist ein häufiger Auslöser. Ihn in den Energieoptionen abzuschalten löst den Fehler in vielen Fällen, ohne dass Daten verloren gehen.

Wo finde ich die Minidump-Datei zum Auswerten?

Windows speichert das Absturzprotokoll unter C:\Windows\Minidump als .dmp-Datei. Mit dem kostenlosen Tool BlueScreenView liest du daraus den auslösenden Treiber aus, ohne einen Debugger installieren zu müssen.

Kann auch defekte Hardware den Fehler auslösen?

Ja. Wenn Treiber-Updates nichts bringen, können ein veraltetes BIOS, fehlerhafte Energie-Firmware (ACPI) oder ein defektes Gerät wie ein USB-Hub die Ursache sein. Zuletzt angeschlossene Hardware testweise entfernen grenzt das ein.