Controllo bug 0xEA: THREAD_STUCK_IN_DEVICE_DRIVER
Il controllo dei bug THREAD_STUCK_IN_DEVICE_DRIVER ha un valore pari a 0x000000EA. Ciò indica che un thread in un driver di dispositivo sta ruotando senza fine.
Importante
Questo articolo è destinato ai programmatori. Se si è un cliente che ha ricevuto un codice di errore della schermata blu durante l'uso del computer, vedere Risolvere gli errori della schermata blu.
parametri THREAD_STUCK_IN_DEVICE_DRIVER
| Parametro | Descrizione |
|---|---|
1 |
Puntatore all'oggetto thread bloccato |
2 |
Puntatore all'oggetto DEFERRED_WATCHDOG |
3 |
Puntatore al nome del driver che causa un'offesa |
4 |
Nel debugger del kernel: Numero di volte in cui è stato raggiunto il controllo del bug "intercettato" 0xEA Sullo schermo blu: 1 |
Causa
Un driver di dispositivo sta ruotando in un ciclo infinito, molto probabilmente in attesa che l'hardware diventi inattiva.
Questo indica in genere un problema con l'hardware stesso o con il driver di dispositivo che programma l'hardware in modo errato. Spesso, questo è il risultato di una scheda video non valida o di un driver di visualizzazione errato.
Risoluzione
L'estensione di debug !analyze visualizza informazioni sul controllo dei bug e può essere utile per determinare la causa radice.
Usare il comando .thread (Set Register Context) insieme al parametro 1. Usare quindi kb (Display Stack Backtrace) per trovare il percorso in cui il thread è bloccato.
Se il debugger del kernel è già connesso e in esecuzione quando Windows rileva una condizione di timeout. DbgBreakPoint verrà quindi chiamato invece di KeBugCheckEx. Verrà stampato un messaggio dettagliato nel debugger. Per altre informazioni, vedere Invio di output al debug.
Questo messaggio includerà i parametri di controllo dei bug. Poiché non è stato eseguito alcun controllo di bug effettivo, il comando .bugcheck (Display Bug Check Data) non sarà utile. I quattro parametri possono essere recuperati anche dalle variabili globali di Watchdog usando dd watchdog!g_WdBugCheckData L5" in un sistema a 32 bit o watchdog dq!g_WdBugCheckData L5" in un sistema a 64 bit.
Il debug di questo errore in modo interattivo, ad esempio, consentirà di trovare un thread che causa un errore, impostare i punti di interruzione in esso contenuti e quindi usare g (Go) per tornare al codice rotante per eseguirne il debug.
Nei computer multiprocessore (build del sistema operativo 3790 o versioni precedenti), è possibile raggiungere un timeout se il thread rotante viene interrotto da un interrupt hardware e una routine ISR o DPC è in esecuzione al momento del controllo dei bug. Ciò è dovuto al fatto che l'elemento di lavoro del timeout può essere recapitato e gestito nella seconda CPU e nello stesso tempo. In questo caso, è necessario esaminare più a fondo lo stack del thread che causa l'errore per determinare il codice rotante che ha causato il timeout. Usare il comando dds (Visualizza parole e simboli) per eseguire questa operazione.