Controllo bug 0x9F: DRIVER_POWER_STATE_FAILURE

Articolo
06/20/2023

Il controllo DRIVER_POWER_STATE_FAILURE bug ha un valore di 0x0000009F. Questo controllo di bug indica che il driver si trova in uno stato di alimentazione incoerente o non valido.

Importante

Questo articolo è destinato ai programmatori. Se si è un cliente che ha ricevuto un codice di errore dello schermo blu durante l'uso del computer, vedere Risolvere gli errori dello schermo blu.

parametri DRIVER_POWER_STATE_FAILURE

Il parametro 1 indica il tipo di violazione.

Parametro 1	Parametro 2	Parametro 3	Parametro 4	Causa
0x1	Oggetto dispositivo	Riservato	Riservato	L'oggetto dispositivo che viene liberato ha ancora una richiesta di alimentazione in sospeso che non è stata completata.
0x2	Oggetto dispositivo del dispositivo di destinazione, se disponibile	Oggetto dispositivo	Oggetto driver, se disponibile	L'oggetto dispositivo ha completato il pacchetto di richiesta I/O (IRP) per la richiesta di stato di alimentazione del sistema, ma non ha chiamato PoStartNextPowerIrp.
0x3	Oggetto dispositivo fisico (PDO) dello stack	nt!_TRIAGE_9F_POWER.	IRP bloccati	Un oggetto dispositivo blocca un'IRP per troppo tempo.
0x4	Valore di timeout, in secondi.	Il thread attualmente bloccato sul blocco Plug-and-Play (PnP).	Nt! TRIAGE_9F_PNP.	Timeout della transizione dello stato di alimentazione in attesa della sincronizzazione con il sottosistema PnP.
0x5	Oggetto dispositivo fisico dello stack	Oggetto POP_FX_DEVICE	Riservato - 0	Il dispositivo non è riuscito a completare una transizione di alimentazione diretta entro il tempo necessario.
0x6	Oggetto POP_FX_DEVICE	Indica se si tratta di un completamento diretto di Power Down(1) o Power Up(0).	Riservato - 0	Il dispositivo non ha completato correttamente il callback di Power Transition diretto.
0x500	Riservato	Se disponibile, l'oggetto dispositivo del dispositivo di destinazione	Oggetto dispositivo	L'oggetto dispositivo ha completato l'IRP per la richiesta dello stato di alimentazione del sistema, ma non ha chiamato PoStartNextPowerIrp.

Causa

Per una descrizione delle possibili cause, vedere la descrizione di ogni codice nella sezione Parametri. Le cause comuni includono:

Richiesta di alimentazione noncompletata dell'oggetto dispositivo liberato w/in sospeso
Timeout della transizione dello stato di alimentazione
Oggetto dispositivo che blocca un'istanza di IRP
L'IRP completato ma non ha chiamato PoStartNextPowerIrp

Risoluzione

Per determinare la causa specifica e per creare una correzione del codice, è necessario l'esperienza di programmazione e l'accesso al codice sorgente del modulo di errore.

Il debug del bug controlla 0x9F quando il parametro 1 è uguale a 0x3

In un debugger del kernel usare il comando !analyze -v per eseguire l'analisi iniziale del controllo dei bug. L'analisi dettagliata visualizza l'indirizzo del nt! TRIAGE_9F_POWER struttura, che si trova 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

Se un driver responsabile dell'errore può essere identificato, il nome viene stampato sullo schermo blu e archiviato in memoria nella posizione (PUNICODE_STRING) KiBugCheckDriver. È possibile usare dx (espressione del modello a oggetti del debugger) per visualizzare questo comando: dx KiBugCheckDriver.

Il nt! TRIAGE_9F_POWER struttura fornisce informazioni aggiuntive sul controllo dei bug che possono aiutare a determinare la causa di questo controllo di bug. La struttura può fornire un elenco di tutti gli IP di alimentazione in sospeso, un elenco di tutti i thread di lavoro di power IRP e un puntatore alla coda di lavoro di sistema ritardata.

Usare il comando dt (Tipo di visualizzazione) e specificare nt! TRIAGE_9F_POWER struttura usando l'indirizzo da 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

Il comando dt (Tipo di visualizzazione) visualizza la struttura. È possibile usare vari comandi del debugger per seguire i campi LIST_ENTRY per esaminare l'elenco degli indirizzi IP in sospeso e i thread di lavoro di Power IRP.

Usare il comando !irp per esaminare l'IRP bloccato. L'indirizzo di questa IRP è 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

Usare il comando !devstack con l'indirizzo PDO in Arg2 per visualizzare le informazioni associate al driver di errore.

    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"

Usare il comando !poaction per visualizzare i thread che gestiscono le operazioni di alimentazione e tutti gli indirizzi IP di alimentazione allocati.

    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

Se si usa un driver KMDF, usare le estensioni di Windows Driver Framework (!wdfkd) per raccogliere informazioni aggiuntive.

Usare !wdfkd.wdflogdump<il nome> del driver, per verificare se KMDF è in attesa di qualsiasi richiesta in sospeso.

Usare !wdfkd.wdfdevicequeues<il WDFDEVICE> per esaminare tutte le richieste in sospeso e lo stato in cui si trovano.
Usare l'estensione !stacks per esaminare lo stato di ogni thread e cercare un thread che potrebbe contenere la transizione dello stato di alimentazione.
Per determinare la causa dell'errore, prendere in considerazione le domande seguenti:
- Quali sono le caratteristiche del driver PDO (Physical Device Object) (Arg2)?
- È possibile trovare il thread bloccato? Quando si esamina il thread con il comando !thread debugger, qual è il thread costituito da?
- L'I/O è associato al thread che lo blocca? Quali simboli si trovano nello stack?
- Quando si esamina l'IRP di alimentazione bloccata, cosa si noterà?
- Qual è il codice di funzione secondaria PnP dell'IRP di alimentazione?

Verifica bug di debug 0x9F quando il parametro 1 è uguale a 0x4

In un debugger del kernel usare il comando !analyze -v per eseguire l'analisi iniziale del controllo dei bug. L'analisi dettagliata visualizza l'indirizzo del nt! TRIAGE_9F_PNP struttura, che è in Parametro 4 (arg4).

    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

Il nt! TRIAGE_9F_PNP struttura fornisce informazioni aggiuntive sul controllo dei bug che potrebbero aiutare a determinare la causa dell'errore. Il nt! TRIAGE_9F_PNP struttura fornisce un puntatore a una struttura che contiene l'elenco di PNP inviati (ma non completati) e fornisce un puntatore alla coda di lavoro di sistema ritardata.

Usare il comando dt (Tipo di visualizzazione) e specificare nt! TRIAGE_9F_PNP struttura e l'indirizzo trovato in Arg4.

    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

Il comando dt (Tipo di visualizzazione) visualizza la struttura. È possibile usare i comandi del debugger per seguire i campi di LIST_ENTRY per esaminare l'elenco dei PnP IRP in sospeso.

Per determinare la causa dell'errore, prendere in considerazione le domande seguenti:

C'è un'istanza di IRP associata al thread?
C'è un I/O nel completamentoQueue?
Quali simboli si trovano nello stack?
Fare riferimento alle tecniche aggiuntive descritte in precedenza in 0x3 di parametri.

Commenti

Se non si è dotati di eseguire il debug di questo problema usando le tecniche descritte in precedenza, è possibile usare alcune tecniche di risoluzione dei problemi di base.

Se di recente sono stati aggiunti nuovi driver di dispositivo o servizi di sistema, provare a rimuoverli o ad aggiornarli. Provare a determinare cosa è cambiato nel sistema che ha causato la visualizzazione del nuovo codice di controllo dei bug.
Cercare in Gestione dispositivi per verificare se i dispositivi sono contrassegnati con il punto esclamativo (!). Esaminare il log eventi visualizzato nelle proprietà del driver per qualsiasi driver di errore. Provare ad aggiornare il driver correlato.
Controllare l'accesso al sistema Visualizzatore eventi per altri messaggi di errore che potrebbero aiutare a individuare il dispositivo o il driver che causa l'errore. Per altre informazioni, vedere Aprire Visualizzatore eventi. Controllare se nel registro di sistema sono presenti errori critici verificatisi nello stesso intervallo di tempo della schermata blu.
Per provare a isolare la causa, disabilitare in modo temporale il risparmio energia usando il pannello di controllo, le opzioni di alimentazione. Alcuni problemi relativi ai driver sono correlati ai vari stati di ibernazione del sistema e alla sospensione e alla ripresa dell'alimentazione.
Se di recente è stato aggiunto hardware al sistema, provare a rimuoverlo o sostituirlo. In alternativa, rivolgersi al produttore per verificare se sono disponibili patch.
È possibile provare a eseguire la diagnostica hardware fornita dal produttore del sistema.
Verificare con il produttore di verificare se è disponibile un firmware o un ACPI/BIOS del sistema aggiornato.

Vedere anche

Analisi del dump di arresto anomalo usando i debugger di Windows (WinDbg)

Analisi di un file di dump di Kernel-Mode con WinDbg

Riferimento al codice del controllo errori

Condividi tramite