Partager via


Bug Check 0x133 : DPC_WATCHDOG_VIOLATION

Le bug check DPC_WATCHDOG_VIOLATION a une valeur de 0x00000133. Ce bug check indique que le DPC watchdog s’est exécuté, soit parce qu’il a détecté un appel de procédure différée (DPC) unique de longue durée, soit parce que le système a passé un temps prolongé à un niveau de requête d’interruption (IRQL) de DISPATCH_LEVEL ou supérieur.

La valeur du Paramètre 1 indique si un seul DPC a dépassé un délai d’attente ou si le système a passé une période prolongée à un IRQL de DISPATCH_LEVEL ou supérieur. Les DPC ne doivent pas fonctionner plus de 100 microsecondes et les ISR ne doivent pas fonctionner plus de 25 microsecondes, cependant les valeurs de délai d’attente réelles sur le système sont beaucoup plus élevées.

Pour plus d’informations sur les DPC, veuillez consulter la section Présentation des objets DPC et Windows Internals 7th Edition Part 1 de Pavel Yosifovich, Mark E. Russinovich, David A. Solomon et Alex Ionescu.

Important

Cet article s’adresse aux programmeurs. Si vous êtes un client et que vous avez reçu ce code d’erreur d’écran bleu en utilisant votre ordinateur, consultez Résoudre les erreurs d’écran bleu.

Paramètres DPC_WATCHDOG_VIOLATION

Paramètre 1 indique le type de violation. La signification des autres paramètres dépend de la valeur du Paramètre 1.

Paramètre 1 Paramètre 2 Paramètre 3 Paramètre 4 Cause de l’erreur
0 Le nombre de ticks du temps DPC L’allocation de temps DPC (en ticks). Converti en nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, qui contient des informations supplémentaires concernant ce délai de DPC unique Un seul DPC ou ISR a dépassé son allocation de temps. Le composant fautif peut généralement être identifié avec une trace d’appels.
1 La période de surveillance Converti en nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, qui contient des informations supplémentaires concernant ce délai de DPC unique Reserved Le système a passé une période prolongée à un IRQL de DISPATCH_LEVEL ou supérieur. Le composant fautif peut généralement être identifié avec une trace d’appels.

Cause

Pour déterminer la cause, il faut utiliser le débogueur Windows, avoir de l’expérience en programmation et accéder au code source du module défaillant.

Pour plus d'informations, consultez les rubriques suivantes :

Analyse des dumps de crash à l’aide des débogueurs Windows (WinDbg)

Analyse d’un fichier de dump en mode noyau avec WinDbg

Utilisation de l’extension !analyze et !analyze

Pour plus d’informations sur les DPC Windows, veuillez consulter Windows Internals 7th Edition Part 1 de Pavel Yosifovich, Mark E. Russinovich, David A. Solomon et Alex Ionescu.

Exemple 1

L’extension de débogage !analyze affiche des informations sur le bug check et peut être utile pour déterminer la cause principale.

Paramètre 1 = 0

Dans cet exemple, le nombre de ticks de 501 dépasse l’allocation de temps DPC de 500. Le nom de l’image indique que ce code s’exécutait lorsque le bug check s’est produit.

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
...

Utilisez les commandes de débogueur suivantes pour recueillir plus d’informations sur les échecs avec un paramètre de 0 :

k (Afficher la trace de pile) pour voir quel code s’exécutait lorsque le code d’arrêt s’est produit.

Vous pouvez utiliser les commandes u, ub, uu (Désassembler) pour examiner plus en détail les spécificités du code qui s’exécutait.

L’extension !pcr affiche l’état actuel de la région de contrôle du processeur (PCR) sur un processeur spécifique. Dans la sortie se trouvera l’adresse du 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

Vous pouvez utiliser la commande dt (Afficher le type) pour afficher des informations supplémentaires sur les DPC et le DPC Watchdog. Pour l’adresse, utilisez le Prcb listé dans la sortie !pcr :

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

Exemple 2

Paramètre 1 = 1

Pour un paramètre de 1, le code peut ne pas s’arrêter dans la zone de code fautive. Dans ce cas, une approche consiste à utiliser la traçabilité des événements pour tenter de localiser le pilote qui dépasse la durée normale d’exécution.

Utilisez l’extension de débogage !analyze pour afficher des informations sur le bug check.

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

Convertissez l’adresse du nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK pour afficher des informations à son sujet.

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

Utilisez la commande !dpcs pour afficher les DPC en file d’attente.

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

Résolution

Pour déterminer la cause spécifique et créer une correction de code, il faut de l’expérience en programmation et avoir accès au code source du module défaillant.

Notes

En général, ce code d’arrêt est causé par un code de pilote défectueux qui, dans certaines conditions, ne termine pas son travail dans le délai imparti.

Si vous n’êtes pas équipé pour utiliser le débogueur Windows pour ce problème, vous devez utiliser des techniques de dépannage de base.

  • Si un pilote est identifié dans le message de bug check, pour isoler le problème, désactivez le pilote. Vérifiez auprès du fabricant les mises à jour du pilote.

  • Vérifiez le journal système dans l’Observateur d’événements pour des messages d’erreur supplémentaires qui pourraient aider à identifier le périphérique ou le pilote à l’origine du bug check 0x133.

  • Confirmez que tout nouveau matériel installé est compatible avec la version installée de Windows. Par exemple, pour Windows 10, vous pouvez obtenir des informations sur le matériel requis sur Spécifications de Windows 10.

  • Pour plus d’informations générales sur la résolution des problèmes, consultez Blue Screen Data.

Voir aussi

Analyse des dumps de crash à l’aide des débogueurs Windows (WinDbg)

Analyse d’un fichier de dump en mode noyau avec WinDbg

Référence du Code de vérification de bogue