Freigeben über

Fehlerüberprüfung 0x133: DPC_WATCHDOG_VIOLATION

  • Artikel

Die DPC_WATCHDOG_VIOLATION-Fehlerüberprüfung hat einen Wert von 0x00000133. Diese Fehlerprüfung zeigt an, dass der DPC-Watchdog ausgeführt wurde, entweder da er einen einzelnen lang andauernden DPC (Deferred Procedure Call) erkannt hat oder da das System längere Zeit auf einem Interrupt Request Level (IRQL) von DISPATCH_LEVEL oder höher verbracht hat.

Der Wert von Parameter 1 gibt an, ob ein einzelner DPC ein Timeout überschritten hat oder ob das System einen längeren Zeitraum für IRQL-DISPATCH_LEVEL oder höher aufgewendet hat. DPCs sollten nicht länger als 100 Mikrosekunden ausgeführt werden, und ISRs sollten nicht länger als 25 Mikrosekunden laufen, die tatsächlichen Timeoutwerte auf dem System werden jedoch viel höher festgelegt.

Weitere Informationen über DPCs finden Sie unter Einführung in DPC-Objekte und Windows Internals 7th Edition Part 1 von Pavel Yosifovich, Mark E. Russinovich, David A. Solomon und Alex Ionescu.

Wichtig

Dieser Artikel richtet sich an Programmierer*innen. Wenn Sie ein Kunde sind, der während der Verwendung Ihres Computers einen Bluescreen-Fehlercode erhalten hat, lesen Sie Problembehandlung bei Bluescreen-Fehlern.

DPC_WATCHDOG_VIOLATION-Parameter

Parameter 1 gibt den Typ des Verstoßes an. Die Bedeutung der anderen Parameter hängt von dem Wert von Parameter 1 ab.

Parameter 1 Parameter 2 Parameter 3 Parameter 4 Fehlerursache
0 Die DPC-Zeitzählung (in Takten) Die DPC-Zeitzuteilung (in Takten). umgewandelt in nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, das zusätzliche Informationen zu diesem einzelnen DPC-Timeout enthält Ein einzelner DPC oder ISR hat sein Zeitkontingent überschritten. Die problematische Komponente kann in der Regel mit einer Stapelüberwachung identifiziert werden.
1 Der Watchdog-Zeitraum umgewandelt in nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, das zusätzliche Informationen zu diesem einzelnen DPC-Timeout enthält Reserved Das System verbrachte kumulativ einen längeren Zeitraum auf dem IRQL DISPATCH_LEVEL oder höher. Die problematische Komponente kann in der Regel mit einer Stapelüberwachung identifiziert werden.

Ursache

Um die Ursache zu ermitteln, sind der Windows-Debugger, Programmiererfahrung und Zugriff auf den Quellcode des fehlerhaften Moduls erforderlich.

Weitere Informationen finden Sie in den folgenden Themen:

Absturzabbildanalyse mit den Windows-Debuggern (WinDbg)

Analysieren einer Kernelmodus-Dump-Datei mit WinDbg

Verwenden der !analyze-Erweiterung und von !analyze

Weitere Informationen zu Windows DPC erhalten Sie unter Windows Internals 7th Edition Part 1 von Pavel Yosifovich, Mark E. Russinovich, David A. Solomon und Alex Ionescu.

Beispiel 1

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

Parameter 1 = 0

In diesem Beispiel überschreitet die Taktanzahl von 501 die DPC-Zeitzuteilung von 500. Der Bildname gibt an, dass dieser Code beim Auftreten der Fehlerüberprüfung ausgeführt wurde.

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

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000000, A single DPC or ISR exceeded its time allotment. The offending
    component can usually be identified with a stack trace.
Arg2: 0000000000000501, The DPC time count (in ticks).
Arg3: 0000000000000500, The DPC time allotment (in ticks).
Arg4: 0000000000000000

...

IMAGE_NAME:  BthA2DP.sys
...

Verwenden Sie die folgenden Debuggerbefehle, um weitere Informationen für Fehler mit einem Parameter von 0 zu sammeln:

k (Display Stack Backtrace), um zu sehen, welcher Code ausgeführt wurde, als der Stoppcode auftrat.

Möglicherweise möchten Sie den Befehl u, ub, uu (Unassemble) verwenden, um genauere Einzelheiten zum ausgeführten Code zu erfahren.

Die Erweiterung !pcr zeigt den aktuellen Status der Processor Control Region (PCR) auf einem bestimmten Prozessor an. In der Ausgabe wird die Adresse des Prcb angezeigt.

0: kd> !pcr
KPCR for Processor 0 at fffff8035f5a4000:
    Major 1 Minor 1
	NtTib.ExceptionList: fffff80368e77fb0
	    NtTib.StackBase: fffff80368e76000
	   NtTib.StackLimit: 0000000000000000
	 NtTib.SubSystemTib: fffff8035f5a4000
	      NtTib.Version: 000000005f5a4180
	  NtTib.UserPointer: fffff8035f5a4870
	      NtTib.SelfTib: 000000b6d3086000

	            SelfPcr: 0000000000000000
	               Prcb: fffff8035f5a4180
	               Irql: 0000000000000000
	                IRR: 0000000000000000
	                IDR: 0000000000000000
	      InterruptMode: 0000000000000000
	                IDT: 0000000000000000
	                GDT: 0000000000000000
	                TSS: 0000000000000000

	      CurrentThread: fffff80364926a00
	         NextThread: ffffe40b77c12040
	         IdleThread: fffff80364926a00

Sie können den Befehl dt (Display Type) verwenden, um zusätzliche Informationen zu den DPCs und dem DPC Watchdog anzuzeigen. Verwenden Sie als Adresse den in der !pcr-Ausgabe aufgeführten Prcb:

dt nt!_KPRCB fffff80309974180 Dpc* 

0: kd> dt nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK fffff803648fa320
   +0x000 Signature        : 0xaebecede
   +0x004 Revision         : 1
   +0x006 Size             : 0x10
   +0x008 DpcWatchdogProfileOffset : 0x84a8
   +0x00c DpcWatchdogProfileLength : 0x8200

Beispiel 2

Parameter 1 = 1

Bei einem Parameter von 1 darf der Code nicht im fehlerhaften Codebereich anhalten. In diesem Fall besteht ein Ansatz darin, die Ereignisablaufverfolgung zu verwenden, um zu versuchen, nachzuverfolgen, welcher Treiber die normale Ausführungsdauer überschreitet.

Verwenden Sie die Debugerweiterung !analyze, um Informationen zur Fehlerüberprüfung anzuzeigen.

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

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
	DISPATCH_LEVEL or above. The offending component can usually be
	identified with a stack trace.
Arg2: 0000000000001e00, The watchdog period.
Arg3: fffff803648fa320, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
	additional information regarding the cumulative timeout
Arg4: 0000000000000000

Wandeln Sie die Adresse des nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK um, um Informationen dazu anzuzeigen.

0: kd> dt nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK fffff803648fa320
   +0x000 Signature        : 0xaebecede
   +0x004 Revision         : 1
   +0x006 Size             : 0x10
   +0x008 DpcWatchdogProfileOffset : 0x84a8
   +0x00c DpcWatchdogProfileLength : 0x8200

Verwenden Sie den Befehl !dpcs, um die in die Warteschlange gestellten DPCs anzuzeigen.

3: kd> !dpcs
CPU Type      KDPC       Function
 0: Normal  : 0xfffff8035f5ac290 0xfffff80363e15630 nt!PpmPerfAction
Failed to read DPC at 0xffffe40b77190dd8
 0: Threaded: 0xfffff8035f5ac3d8 0xfffff80363f27d70 nt!KiDpcWatchdog

Lösung

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

Hinweise

Im Allgemeinen wird dieser Stoppcode durch fehlerhaften Treibercode verursacht, der unter bestimmten Bedingungen seine Arbeit nicht innerhalb des vorgegebenen Zeitrahmens abschließt.

Wenn Sie nicht mit dem Windows-Debugger für dieses Problem ausgestattet sind, sollten Sie einige grundlegende Problembehandlungstechniken verwenden.

  • Wenn ein Treiber in der Fehlerüberprüfungsmeldung identifiziert wird, deaktivieren Sie den Treiber, um das Problem zu isolieren. Wenden Sie sich an den Hersteller, um Treiberupdates zu erhalten.

  • Überprüfen Sie das Systemprotokoll in der Ereignisanzeige auf weitere Fehlermeldungen, die Ihnen helfen könnten, das Gerät oder den Treiber zu identifizieren, das bzw. der die Fehlerüberprüfung 0x133 verursacht.

  • Bestätigen Sie, dass die neu installierte Hardware mit der installierten Windows-Version kompatibel ist. Informationen zur benötigten Hardware für Windows 10 finden Sie beispielsweise unter Windows 10-Spezifikationen.

  • Weitere allgemeine Informationen zur Fehlerbehebung finden Sie unter Analysieren von Fehlerüberprüfungs-Bluescreen-Daten.

Siehe auch

Absturzabbildanalyse mit den Windows-Debuggern (WinDbg)

Analysieren einer Kernelmodus-Dump-Datei mit WinDbg

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