Fehlerüberprüfung 0x133: DPC_WATCHDOG_VIOLATION

  • Artikel

Die DPC_WATCHDOG_VIOLATION-Fehlerüberprüfung hat den Wert 0x00000133. Diese Fehlerüberprüfung gibt an, dass der DPC-Watchdog ausgeführt wurde, entweder, weil er einen einzelnen DPC(Long-Running DeFerred Procedure Call) erkannt hat oder weil das System eine längere Zeit auf einer Interruptanforderungsebene (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 kumulativ einen längeren Zeitraum am IRQL DISPATCH_LEVEL oder höher verbracht hat. DPCs sollten nicht länger als 100 Mikrosekunden ausgeführt werden, und ISRs sollten nicht länger als 25 Mikrosekunden laufen, aber die tatsächlichen Timeoutwerte im System sind viel höher festgelegt.

Weitere Informationen zu DPCs finden Sie unter Introduction to DPC Objects and 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. 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.

DPC_WATCHDOG_VIOLATION Parameter

Parameter 1 gibt die Art der Verletzung an. Die Bedeutung der anderen Parameter hängt vom Wert von Parameter 1 ab.

Parameter 1 Parameter 2 Parameter 3 Parameter 4 Fehlerursache
0 Die DPC-Zeitanzahl (in Ticks) Die DPC-Zeitkontingentierung (in Ticks). cast to nt! DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, die zusätzliche Informationen zu diesem einzelnen DPC-Timeout enthält Ein einzelner DPC oder ISR hat seine Zeitkontingentierung überschritten. Die beleidigende Komponente kann in der Regel mit einer Stapelablaufverfolgung identifiziert werden.
1 Der Watchdog-Zeitraum cast to nt! DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, die zusätzliche Informationen zu diesem einzelnen DPC-Timeout enthält Reserviert Das System hat kumulativ einen längeren Zeitraum bei IRQL DISPATCH_LEVEL oder höher verbracht. Die beleidigende Komponente kann in der Regel mit einer Stapelablaufverfolgung 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 mithilfe der Windows-Debugger (WinDbg)

Analysieren einer Kernel-Mode-Dumpdatei mit WinDbg

Verwenden der !analyze-Erweiterung und !analyze

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

Beispiel 1

Die Debugerweiterung !analyze zeigt Informationen zur Fehlerüberprüfung an und kann hilfreich sein, um die Grundursache zu ermitteln.

Parameter 1 = 0

In diesem Beispiel überschreitet die Tickanzahl von 501 die DPC-Zeitkontingentierung von 500. Der Imagename gibt an, dass dieser Code ausgeführt wurde, als die Fehlerüberprüfung aufgetreten ist.

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 dem Parameter 0 zu sammeln:

k (Display Stack Backtrace), um zu untersuchen, welcher Code ausgeführt wurde, als der Stoppcode aufgetreten ist.

Sie können den Befehl u, ub, uu (Unassemble) verwenden, um die Besonderheiten eines ausgeführten Codes genauer zu untersuchen.

Die Erweiterung !pcr zeigt den aktuellen status der Prozessorsteuerungsregion (Prozessorsteuerungsregion, PCR) auf einem bestimmten Prozessor an. In der Ausgabe ist die Adresse des Prcb

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 (Anzeigetyp) verwenden, um zusätzliche Informationen zu den DPCs und dem DPC Watchdog anzuzeigen. Verwenden Sie für die Adresse den prcb, der in der !pcr-Ausgabe aufgeführt ist:

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

Beim Parameter 1 darf der Code nicht im beleidigenden Codebereich angehalten werden. In diesem Fall besteht ein Ansatz darin, die Ereignisablaufverfolgung zu verwenden, um 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 Informationen darüber 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 DPCs in der Warteschlange 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 spezifische Ursache zu ermitteln und eine Codekorrektur zu erstellen, sind Programmiererfahrungen und Zugriff auf den Quellcode des fehlerhaften Moduls erforderlich.

Hinweise

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

Wenn Sie nicht in der Lage sind, den Windows-Debugger für dieses Problem zu verwenden, sollten Sie einige grundlegende Techniken zur Problembehandlung verwenden.

  • Wenn in der Meldung zur Fehlerüberprüfung ein Treiber 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 Ereignisanzeige auf zusätzliche Fehlermeldungen, die dazu beitragen können, das Gerät oder den Treiber zu identifizieren, das die Fehlerüberprüfung 0x133 verursacht.

  • Vergewissern Sie sich, dass alle installierten neuen Hardwareversionen mit der installierten Version von Windows kompatibel sind. Für Windows 10 können Sie beispielsweise Informationen zur erforderlichen Hardware unter Windows 10 Spezifikationen abrufen.

  • Weitere allgemeine Informationen zur Problembehandlung finden Sie unter Bluescreen-Daten.

Weitere Informationen

Absturzabbildanalyse mithilfe der Windows-Debugger (WinDbg)

Analysieren einer Kernel-Mode-Dumpdatei mit WinDbg

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