Fehlerprüfung 0x9F: DRIVER_POWER_STATE_FAILURE

Artikel
10/26/2023

Die DRIVER_POWER_STATE_FAILURE-Fehlerüberprüfung weist den Wert 0x0000009F auf. Diese Fehlerprüfung gibt an, dass sich der Treiber in einem inkonsistenten oder ungültigen Energiezustand befindet.

Wichtig

Dieser Artikel richtet sich an Programmierer. Wenn Sie ein Kunde sind, der während der Verwendung Ihres Computers einen Bluescreen-Fehlercode erhalten hat, finden Sie weitere Informationen unter Behandeln von Bluescreenfehlern.

DRIVER_POWER_STATE_FAILURE-Parameter

Parameter 1 gibt den Typ des Verstoßes an.

Parameter 1	Parameter 2	Parameter 3	Parameter 4	Ursache
0x1	Das Geräteobjekt	Reserviert	Reserviert	Das freigegebene Geräteobjekt verfügt noch über eine ausstehende Energieanforderung, die noch nicht abgeschlossen wurde.
0x2	Das Geräteobjekt des Zielgeräts, sofern verfügbar	Das Geräteobjekt	Das Treiberobjekt, sofern verfügbar	Das Geräteobjekt hat das E/A-Anforderungspaket (IRP) für die Systemstromzustandsanforderung abgeschlossen, aber poStartNextPowerIrp nicht aufgerufen.
0x3	Das objekt des physischen Geräts (PDO) des Stapels	nt!_TRIAGE_9F_POWER.	Die blockierte IRP	Ein Geräteobjekt blockiert eine IRP zu lange.
0x4	Timeoutwert in Sekunden.	Der Thread, der derzeit die Plug-and-Play-Sperre (PnP) hält.	Nt! TRIAGE_9F_PNP.	Das Timeout des Energiezustandsübergangs wurde auf die Synchronisierung mit dem PnP-Subsystem gewartet.
0x5	Physisches Geräteobjekt des Stapels	Das POP_FX_DEVICE-Objekt	Reserviert: 0	Das Gerät konnte einen gerichteten Stromübergang nicht innerhalb der erforderlichen Zeit durchführen.
0x6	Das POP_FX_DEVICE-Objekt	Gibt an, ob es sich um einen Abschluss mit gerichtetem Herunterschalten (1) oder Einschalten (0) handelt.	Reserviert: 0	Das Gerät hat seinen Rückruf für den gerichteten Energieübergang nicht erfolgreich abgeschlossen.
0x500	Reserviert	Das Geräteobjekt des Zielgeräts, falls verfügbar	Geräteobjekt	Das Geräteobjekt hat die IRP für die Systemstromzustandsanforderung abgeschlossen, aber poStartNextPowerIrp nicht aufgerufen.

Ursache

Eine Beschreibung der möglichen Ursachen finden Sie in der Beschreibung der einzelnen Codes im Abschnitt Parameter. Häufige Ursachen sind:

Freigegebenes Geräteobjekt mit ausstehender, nicht abgeschlossener Energieanforderung
Timeout beim Übergang des Energiezustands
Geräteobjekt, das eine IRP blockiert
Abgeschlossenes IRP, aber kein Aufruf von PoStartNextPowerIrp

Lösung

Um die spezifische Ursache zu ermitteln und eine Codekorrektur zu erstellen, sind Programmiererfahrung und Zugriff auf den Quellcode des fehlerhaften Moduls erforderlich.

Debugfehlerprüfung 0x9F, wenn Parameter 1 gleich 0x3

Verwenden Sie in einem Kerneldebugger den Befehl !analyze -v , um die erste Fehlerprüfungsanalyse durchzuführen. Die ausführliche Analyse zeigt die Adresse des nt! TRIAGE_9F_POWER Struktur in Arg3.

kd>!analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver has failed to complete a power IRP within a specific time.
    Arguments:
    Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
    Arg2: fffffa8007b13440, Physical Device Object of the stack
    Arg3: fffff8000386c3d8, nt!_TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
    Arg4: fffffa800ab61bd0, The blocked IRP

Wenn ein Treiber identifiziert werden kann, der für den Fehler verantwortlich ist, wird sein Name auf dem Bluescreen gedruckt und im Speicher am Speicherort (PUNICODE_STRING) KiBugCheckDriver gespeichert. Sie können dx (Debuggerobjektmodellausdruck anzeigen) verwenden, einen Debuggerbefehl, um folgendes anzuzeigen: dx KiBugCheckDriver.

Der nt! TRIAGE_9F_POWER-Struktur bietet zusätzliche Informationen zur Fehlerüberprüfung, die Ihnen bei der Ermittlung der Ursache dieser Fehlerüberprüfung helfen können. Die -Struktur kann eine Liste aller ausstehenden Power IRPs, eine Liste aller Power IRP-Arbeitsthreads und einen Zeiger auf die verzögerte Systemworkerwarteschlange bereitstellen.

Verwenden Sie den Befehl dt (Anzeigetyp), und geben Sie nt! TRIAGE_9F_POWER Struktur mithilfe der Adresse aus Arg3.

    0: kd> dt nt!_TRIAGE_9F_POWER fffff8000386c3d8
       +0x000 Signature        : 0x8000
       +0x002 Revision         : 1
       +0x008 IrpList          : 0xfffff800`01c78bd0 _LIST_ENTRY [ 0xfffffa80`09f43620 - 0xfffffa80`0ad00170 ]
       +0x010 ThreadList       : 0xfffff800`01c78520 _LIST_ENTRY [ 0xfffff880`009cdb98 - 0xfffff880`181f2b98 ]
       +0x018 DelayedWorkQueue : 0xfffff800`01c6d2d8 _TRIAGE_EX_WORK_QUEUE

Der Befehl dt (Anzeigetyp) zeigt die Struktur an. Sie können verschiedene Debuggerbefehle verwenden, um den LIST_ENTRY Feldern zu folgen, um die Liste der ausstehenden IRPs und die Power-IRP-Workerthreads zu untersuchen.

Verwenden Sie den Befehl !irp , um den blockierten IRP zu untersuchen. Die Adresse dieses IRP befindet sich in Arg4.

    0: kd> !irp fffffa800ab61bd0
    Irp is active with 7 stacks 6 is current (= 0xfffffa800ab61e08)
     No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
         cmd  flg cl Device   File     Completion-Context
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-00000000    

                Args: 00000000 00000000 00000000 00000000
    >[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
                0 e1 fffffa800783f060 00000000 00000000-00000000    pending
               \Driver\HidUsb
                Args: 00016600 00000001 00000004 00000006
     [N/A(0), N/A(0)]
                0  0 00000000 00000000 00000000-fffffa800ad00170    

                Args: 00000000 00000000 00000000 00000000

Verwenden Sie den Befehl !devstack mit der PDO-Adresse in Arg2, um Informationen anzuzeigen, die dem fehlerhaften Treiber zugeordnet sind.

    0: kd> !devstack fffffa8007b13440
      !DevObj           !DrvObj            !DevExt           ObjectName
      fffffa800783f060  \Driver\HidUsb     fffffa800783f1b0  InfoMask field not found for _OBJECT_HEADER at fffffa800783f030

    > fffffa8007b13440  \Driver\usbhub     fffffa8007b13590  Cannot read info offset from nt!ObpInfoMaskToOffset

    !DevNode fffffa8007ac8a00 :
      DeviceInst is "USB\VID_04D8&PID_0033\5&46fa7b7&0&1"
      ServiceName is "HidUsb"

Verwenden Sie den Befehl !poaction, um die Threads anzuzeigen, die die Energievorgänge und alle zugeordneten Power IRPs verarbeiten.

    3: kd> !poaction
    PopAction: fffff801332f3fe0
      State..........: 0 - Idle
      Updates........: 0 
      Action.........: None
      Lightest State.: Unspecified
      Flags..........: 10000003 QueryApps|UIAllowed
      Irp minor......: ??
      System State...: Unspecified
      Hiber Context..: 0000000000000000

    Allocated power irps (PopIrpList - fffff801332f44f0)
      IRP: ffffe0001d53d8f0 (wait-wake/S0), PDO: ffffe00013cae060
      IRP: ffffe0001049a5d0 (wait-wake/S0), PDO: ffffe00012d42050
      IRP: ffffe00013d07420 (set/D3,), PDO: ffffe00012daf840, CURRENT: ffffe00012dd5040
      IRP: ffffe0001e5ac5d0 (wait-wake/S0), PDO: ffffe00013d33060
      IRP: ffffe0001ed3e420 (wait-wake/S0), PDO: ffffe00013c96060
      IRP: ffffe000195fe010 (wait-wake/S0), PDO: ffffe00012d32050

    Irp worker threads (PopIrpThreadList - fffff801332f3100)
      THREAD: ffffe0000ef5d040 (static)
      THREAD: ffffe0000ef5e040 (static), IRP: ffffe00013d07420, DEVICE: ffffe00012dd5040

    PopAction: fffff801332f3fe0
      State..........: 0 - Idle
      Updates........: 0 
      Action.........: None
      Lightest State.: Unspecified
      Flags..........: 10000003 QueryApps|UIAllowed
      Irp minor......: ??
      System State...: Unspecified
      Hiber Context..: 0000000000000000

    Allocated power irps (PopIrpList - fffff801332f44f0)
      IRP: ffffe0001d53d8f0 (wait-wake/S0), PDO: ffffe00013cae060
      IRP: ffffe0001049a5d0 (wait-wake/S0), PDO: ffffe00012d42050
      IRP: ffffe00013d07420 (set/D3,), PDO: ffffe00012daf840, CURRENT: ffffe00012dd5040
      IRP: ffffe0001e5ac5d0 (wait-wake/S0), PDO: ffffe00013d33060
      IRP: ffffe0001ed3e420 (wait-wake/S0), PDO: ffffe00013c96060
      IRP: ffffe000195fe010 (wait-wake/S0), PDO: ffffe00012d32050

    Irp worker threads (PopIrpThreadList - fffff801332f3100)
      THREAD: ffffe0000ef5d040 (static)
      THREAD: ffffe0000ef5e040 (static), IRP: ffffe00013d07420, DEVICE: ffffe00012dd5040

Wenn Sie mit einem KMDF-Treiber arbeiten, verwenden Sie die Windows-Treiberframeworkerweiterungen (!wdfkd), um zusätzliche Informationen zu sammeln.

Verwenden Sie !wdfkd.wdflogdump<Ihren Treibernamen>, um zu ermitteln, ob KMDF auf ausstehende Anforderungen wartet, bis Sie ACK erhalten.

Verwenden Sie !wdfkd.wdfdevicequeues<Ihres WDFDEVICE> , um alle ausstehenden Anforderungen und ihren Zustand zu untersuchen.
Verwenden Sie die !stacks-Erweiterung , um den Status jedes Threads zu untersuchen und nach einem Thread zu suchen, der den Energiezustandsübergang möglicherweise blockiert.
Um die Ursache des Fehlers zu ermitteln, stellen Sie sich die folgenden Fragen:
- Welche Merkmale hat der Treiber für physische Geräteobjekte (PDO) (Arg2)?
- Können Sie den blockierten Thread finden? Worin besteht der Thread, wenn Sie den Thread mit dem Befehl !thread debugger untersuchen?
- Gibt es E/A, die dem Thread zugeordnet sind, der ihn blockiert? Welche Symbole befinden sich auf dem Stapel?
- Was fällt Ihnen auf, wenn Sie die blockierte Leistungs-IRP untersuchen?
- Was ist der PnP-Nebenfunktionscode der Leistungs-IRP?

Debugfehlerprüfung 0x9F, wenn Parameter 1 gleich 0x4

Verwenden Sie in einem Kerneldebugger den Befehl !analyze -v , um die erste Fehlerprüfungsanalyse durchzuführen. Die ausführliche Analyse zeigt die Adresse des nt! TRIAGE_9F_PNP Struktur, die sich in Parameter 4 (arg4) befindet.

    kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_POWER_STATE_FAILURE (9f)
    A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
    Arguments:
    Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
            subsystem.
    Arg2: 00000258, Timeout in seconds.
    Arg3: 84e01a70, The thread currently holding on to the Pnp lock.
    Arg4: 82931b24, nt!TRIAGE_9F_PNP on Win7

Der nt! TRIAGE_9F_PNP-Struktur bietet zusätzliche Informationen zur Fehlerüberprüfung, die Ihnen bei der Ermittlung der Fehlerursache helfen können. Der nt! TRIAGE_9F_PNP-Struktur stellt einen Zeiger auf eine Struktur bereit, die die Liste der verteilten (aber nicht abgeschlossenen) PnP-IRPs enthält, und stellt einen Zeiger auf die verzögerte Systemworkerwarteschlange bereit.

Verwenden Sie den Befehl dt (Anzeigetyp), und geben Sie nt ! TRIAGE_9F_PNP Struktur und die Adresse, die Sie in Arg4 gefunden haben.

    kd> dt nt!TRIAGE_9F_PNP 82931b24
       +0x000 Signature        : 0x8001
       +0x002 Revision         : 1
       +0x004 CompletionQueue  : 0x82970e20 _TRIAGE_PNP_DEVICE_COMPLETION_QUEUE
       +0x008 DelayedWorkQueue : 0x829455bc _TRIAGE_EX_WORK_QUEUE

Der Befehl dt (Anzeigetyp) zeigt die Struktur an. Sie können Debuggerbefehle verwenden, um den LIST_ENTRY Feldern zu folgen, um die Liste der ausstehenden PnP-IRPs zu untersuchen.

Um die Ursache des Fehlers zu ermitteln, stellen Sie sich die folgenden Fragen:

Ist dem Thread ein IRP zugeordnet?
Gibt es E/A in der CompletionQueue?
Welche Symbole befinden sich auf dem Stapel?
Weitere Informationen finden Sie unter Parameter 0x3.

Hinweise

Wenn Sie dieses Problem nicht mithilfe der oben beschriebenen Techniken debuggen können, können Sie einige grundlegende Problembehandlungstechniken verwenden.

Wenn kürzlich neue Gerätetreiber oder Systemdienste hinzugefügt wurden, versuchen Sie, diese zu entfernen oder zu aktualisieren. Versuchen Sie, zu ermitteln, was sich im System geändert hat, wodurch der neue Fehlerüberprüfungscode angezeigt wurde.
Suchen Sie in Geräte-Manager, um zu sehen, ob Geräte mit dem Ausrufezeichen (!) gekennzeichnet sind. Überprüfen Sie das in den Treibereigenschaften angezeigte Ereignisprotokoll auf jeden fehlerhaften Treiber. Versuchen Sie, den entsprechenden Treiber zu aktualisieren.
Überprüfen Sie das Systemprotokoll in Ereignisanzeige auf zusätzliche Fehlermeldungen, die möglicherweise helfen, das Gerät oder den Treiber zu ermitteln, das den Fehler verursacht. Weitere Informationen finden Sie unter Öffnen Ereignisanzeige. Suchen Sie im Systemprotokoll nach kritischen Fehlern, die in demselben Zeitfenster wie der Bluescreen aufgetreten sind.
Um zu versuchen, die Ursache zu isolieren, deaktivieren Sie den Stromsparmodus vorübergehend mithilfe der Systemsteuerung und der Energieoptionen. Einige Treiberprobleme stehen im Zusammenhang mit den verschiedenen Zuständen des Ruhezustands des Systems und der Unterbrechung und Wiederaufnahme der Energieversorgung.
Wenn Sie dem System kürzlich Hardware hinzugefügt haben, versuchen Sie, diese zu entfernen oder zu ersetzen. Oder erkundigen Sie sich beim Hersteller, ob Patches verfügbar sind.
Sie können versuchen, die vom Systemhersteller bereitgestellte Hardwarediagnose auszuführen.
Wenden Sie sich an den Hersteller, ob ein aktualisiertes ACPI/BIOS-System oder eine andere Firmware verfügbar ist.

Siehe auch

Absturzabbildanalyse mithilfe der Windows-Debugger (WinDbg)

Analysieren einer Kernel-Mode-Dumpdatei mit WinDbg

Bug Check Code Reference (Referenz zu Fehlerüberprüfungscodes)

Freigeben über