Fehlerprüfung 0xEA: THREAD_STUCK_IN_DEVICE_DRIVER

Die THREAD_STUCK_IN_DEVICE_DRIVER-Fehlerüberprüfung weist den Wert 0x000000EA auf. Dies weist darauf hin, dass ein Thread in einem Gerätetreiber endlos gedreht wird.

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.

THREAD_STUCK_IN_DEVICE_DRIVER Parameter

Parameter	Beschreibung
1	Ein Zeiger auf das hängen gebliebene Threadobjekt
2	Zeiger auf das DEFERRED_WATCHDOG-Objekt
3	Ein Zeiger auf den namen des beleidigenden Treibers
4	Im Kerneldebugger: Die Häufigkeit, mit der die "abgefangene" Fehlerprüfung 0xEA erreicht wurde Auf dem Bluescreen: 1

Ursache

Ein Gerätetreiber dreht sich in einer Endlosschleife und wartet höchstwahrscheinlich darauf, dass die Hardware in den Leerlauf wechselt.

Dies weist in der Regel auf ein Problem mit der Hardware selbst oder darauf hin, dass der Gerätetreiber die Hardware falsch programmiert. Häufig ist dies das Ergebnis eines schlechten Video-Karte oder eines schlechten Anzeigetreibers.

Lösung

Die !analyze-Debugerweiterung zeigt Informationen zur Fehlerüberprüfung an und kann bei der Ermittlung der Grundursache hilfreich sein.

Verwenden Sie den Befehl .thread (Set Register Context) zusammen mit Parameter 1. Verwenden Sie dann kb (Display Stack Backtrace), um den Speicherort zu finden, an dem der Thread hängen bleibt.

Wenn der Kerneldebugger bereits verbunden ist und ausgeführt wird, wenn Windows eine Timeoutbedingung erkennt. Dann wird DbgBreakPoint anstelle von KeBugCheckEx aufgerufen. Eine ausführliche Meldung wird an den Debugger ausgegeben. Weitere Informationen finden Sie unter Senden der Ausgabe an die Debugge.

Diese Meldung enthält, was die Fehlerüberprüfungsparameter gewesen wären. Da keine tatsächliche Fehlerüberprüfung ausgeführt wurde, ist der Befehl .bugcheck (Fehlerüberprüfungsdaten anzeigen) nicht nützlich. Die vier Parameter können auch aus den globalen Variablen von Watchdog abgerufen werden, indem dd watchdog!g_WdBugCheckData L5" auf einem 32-Bit-System oder dq watchdog!g_WdBugCheckData L5" auf einem 64-Bit-System verwendet wird.

Wenn Sie diesen Fehler auf interaktive Weise wie diese debuggen, können Sie einen beleidigenden Thread finden, Haltepunkte darin festlegen und dann g (Go) verwenden, um zum sich drehenden Code zurückzukehren, um ihn weiter zu debuggen.

Auf Multiprozessorcomputern (Betriebssystembuild 3790 oder früher) kann ein Timeout auftreten, wenn der sich drehende Thread durch einen Hardwareunterbrechung unterbrochen wird und eine ISR- oder DPC-Routine zum Zeitpunkt der Fehlerüberprüfung ausgeführt wird. Dies liegt daran, dass das Arbeitselement des Timeouts auf der zweiten CPU und zur gleichen Zeit übermittelt und verarbeitet werden kann. In diesem Fall müssen Sie den Stapel des beleidigenden Threads genauer untersuchen, um den sich drehenden Code zu ermitteln, der das Timeout verursacht hat. Verwenden Sie hierzu den Befehl dds (Wörter und Symbole anzeigen).