Bug Check 0x116: VIDEO_TDR_FAILURE
Le bug check VIDEO_TDR_FAILURE a une valeur de 0x00000116. Cette erreur d’arrêt indique qu’une tentative de réinitialisation du pilote d’affichage et de récupération après un dépassement de délai a échoué.
Important
Cet article s’adresse aux programmeurs. Si vous êtes un client qui a reçu un code d’erreur écran bleu en utilisant votre ordinateur, veuillez consulter la section Dépanner les erreurs d’écran bleu.
Paramètres VIDEO_TDR_FAILURE
| Paramètre | Description |
|---|---|
| 1 | Le pointeur vers le contexte de récupération TDR interne, si disponible. |
| 2 | Un pointeur dans le module du pilote de périphérique responsable (par exemple, l’étiquette du propriétaire). |
| 3 | Le code d’erreur de la dernière opération échouée, si disponible. |
| 4 | Données contextuelles internes dépendantes, si disponibles. |
Cause
Un problème de stabilité commun en graphisme se produit lorsque le système semble complètement gelé ou bloqué lors du traitement d’une commande ou d’une opération de l’utilisateur final. Généralement, le GPU est occupé à traiter des opérations graphiques intensives, typiquement pendant le jeu. Aucune mise à jour de l’écran ne se produit, et les utilisateurs supposent que leur système est gelé. Les utilisateurs attendent généralement quelques secondes, puis redémarrent le système en appuyant sur le bouton d’alimentation. Windows essaie de détecter ces situations de blocage problématiques et de récupérer dynamiquement un bureau réactif.
Ce processus de détection et de récupération est connu sous le nom de Timeout Detection and Recovery (TDR). Le délai d’expiration par défaut est de 2 secondes. Dans le processus TDR pour les cartes vidéo, le planificateur GPU du système d’exploitation appelle la fonction DxgkDdiResetFromTimeout du pilote miniport d’affichage pour réinitialiser le pilote et le GPU.
Pendant ce processus, le système d’exploitation indique au pilote de ne pas accéder au matériel ou à la mémoire et lui donne un court délai pour terminer les threads en cours d’exécution. Si les threads ne se terminent pas dans le délai imparti, le système génère une erreur d’arrêt avec 0x116 VIDEO_TDR_FAILURE. Pour plus d’informations, veuillez consulter la section Synchronisation des threads et TDR.
Le système peut également générer une erreur d’arrêt avec VIDEO_TDR_FAILURE si plusieurs événements TDR se produisent dans un court laps de temps. La valeur par défaut est plus de cinq TDR en une minute.
Si le processus de récupération réussit, un message sera affiché, indiquant que le « pilote d’affichage a cessé de répondre et a été récupéré ».
Pour plus d’informations, veuillez consulter la section Détection et récupération de dépassement de délai (TDR), Clés de registre TDR, et Modifications de TDR dans Windows 8 et versions ultérieures.
Résolution
Le GPU prend plus de temps que permis pour afficher les graphiques sur votre moniteur. Ce comportement peut être dû à différentes raisons :
- Vous devrez peut-être installer les dernières mises à jour pour votre pilote d’affichage afin qu’il prenne correctement en charge le processus TDR.
- Problèmes matériels affectant la capacité de la carte vidéo à fonctionner correctement, y compris :
- Des composants surcadencés, tels que la carte mère
- Compatibilité et paramètres incorrects des composants (en particulier la configuration et les timings de la mémoire)
- Refroidissement insuffisant du système
- Puissance du système insuffisante
- Pièces défectueuses (modules de mémoire, cartes mères, etc.)
- Les effets visuels ou trop de programmes exécutés en arrière-plan peuvent ralentir votre PC, empêchant ainsi la carte vidéo de répondre comme nécessaire.
L'extension de débogage !analyze affiche des informations sur la vérification d'un bogue et peut être utile pour déterminer la cause racine.
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
VIDEO_TDR_FAILURE (116)
Attempt to reset the display driver and recover from timeout failed.
Arguments:
Arg1: ffffe000c2c404c0, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: fffff8016470c14c, The pointer into responsible device driver module (e.g. owner tag).
Arg3: ffffffffc000009a, Optional error code (NTSTATUS) of the last failed operation.
Arg4: 0000000000000004, Optional internal context dependent data.
...
Le nom du module défaillant est également affiché.
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
Vous pouvez utiliser la commande lm (Liste des modules chargés) pour afficher des informations sur le pilote défaillant, y compris l’horodatage.
1: kd> lmvm nvlddmkm
Browse full module list
start end module name
fffff801`63ec0000 fffff801`649a7000 nvlddmkm T (no symbols)
Loaded symbol image file: nvlddmkm.sys
Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys
Image name: nvlddmkm.sys
Browse all global symbols functions data
Timestamp: Wed Jul 8 15:43:44 2015 (559DA7A0)
CheckSum: 00AA7491
ImageSize: 00AE7000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Le paramètre 1 contient un pointeur vers le TDR_RECOVERY_CONTEXT. Comme indiqué dans la sortie !analyze, si vous avez des symboles pour le code associé, vous pouvez utiliser la commande dt pour afficher ces données.
1: kd> dt dxgkrnl!_TDR_RECOVERY_CONTEXT ffffe000c2c404c0
+0x000 Signature : 0x52445476
+0x008 pState : 0xffffe000`c2b12a40 ??
+0x010 TimeoutReason : 9 ( TdrEngineTimeoutPromotedToAdapterReset )
+0x018 Tick : _ULARGE_INTEGER 0xb2
+0x020 pAdapter : 0xffffe000`c2a89010 DXGADAPTER
+0x028 pVidSchContext : (null)
+0x030 GPUTimeoutData : _TDR_RECOVERY_GPU_DATA
+0x048 CrtcTimeoutData : _TDR_RECOVERY_CONTEXT::<unnamed-type-CrtcTimeoutData>
+0x050 pProcessName : (null)
+0x058 DbgOwnerTag : 0xfffff801`6470c14c
+0x060 PrivateDbgInfo : _TDR_DEBUG_REPORT_PRIVATE_INFO
+0xb00 pDbgReport : 0xffffe000`c2c3f750 _WD_DEBUG_REPORT
+0xb08 pDbgBuffer : 0xffffc000`bd000000 Void
+0xb10 DbgBufferSize : 0x37515
+0xb18 pDumpBufferHelper : (null)
+0xb20 pDbgInfoExtension : 0xffffc000`ba7e47a0 _DXGKARG_COLLECTDBGINFO_EXT
+0xb28 pDbgBufferUpdatePrivateInfo : 0xffffc000`bd000140 Void
+0xb30 ReferenceCount : 0n1
+0xb38 pResetCompletedEvent : (null)
Le paramètre 2 contient un pointeur dans le module du pilote de périphérique responsable (par exemple, l’étiquette du propriétaire).
1: kd> ub fffff8016470c14c
nvlddmkm+0x84c132:
fffff801`6470c132 cc int 3
fffff801`6470c133 cc int 3
fffff801`6470c134 48ff254d2deaff jmp qword ptr [nvlddmkm+0x6eee88 (fffff801`645aee88)]
fffff801`6470c13b cc int 3
fffff801`6470c13c 48ff252d2eeaff jmp qword ptr [nvlddmkm+0x6eef70 (fffff801`645aef70)]
fffff801`6470c143 cc int 3
fffff801`6470c144 48ff257d2deaff jmp qword ptr [nvlddmkm+0x6eeec8 (fffff801`645aeec8)]
fffff801`6470c14b cc int 3
Vous pouvez examiner la trace d’appels en utilisant la commande k, kb, kc, kd, kp, kP, kv (Afficher la trace de la pile).
1: kd> k
# Child-SP RetAddr Call Site
00 ffffd001`7d53d918 fffff801`61ba2b4c nt!KeBugCheckEx [d:\th\minkernel\ntos\ke\amd64\procstat.asm @ 122]
01 ffffd001`7d53d920 fffff801`61b8da0e dxgkrnl!TdrBugcheckOnTimeout+0xec [d:\th\windows\core\dxkernel\dxgkrnl\core\dxgtdr.cxx @ 2731]
02 ffffd001`7d53d960 fffff801`61b8dd7f dxgkrnl!ADAPTER_RENDER::Reset+0x15e [d:\th\windows\core\dxkernel\dxgkrnl\core\adapter.cxx @ 19443]
03 ffffd001`7d53d990 fffff801`61ba2385 dxgkrnl!DXGADAPTER::Reset+0x177 [d:\th\windows\core\dxkernel\dxgkrnl\core\adapter.cxx @ 19316]
04 ffffd001`7d53d9e0 fffff801`63c5fba7 dxgkrnl!TdrResetFromTimeout+0x15 [d:\th\windows\core\dxkernel\dxgkrnl\core\dxgtdr.cxx @ 2554]
05 ffffd001`7d53da10 fffff801`63c47e5d dxgmms1!VidSchiRecoverFromTDR+0x11b [d:\th\windows\core\dxkernel\dxgkrnl\dxgmms1\vidsch\vidscher.cxx @ 1055]
06 ffffd001`7d53dbc0 fffff801`aa55c698 dxgmms1!VidSchiWorkerThread+0x8d [d:\th\windows\core\dxkernel\dxgkrnl\dxgmms1\vidsch\vidschi.cxx @ 426]
07 ffffd001`7d53dc00 fffff801`aa5c9306 nt!PspSystemThreadStartup+0x58 [d:\th\minkernel\ntos\ps\psexec.c @ 6845]
08 ffffd001`7d53dc60 00000000`00000000 nt!KxStartSystemThread+0x16 [d:\th\minkernel\ntos\ke\amd64\threadbg.asm @ 80]
Vous pouvez également définir un point d’arrêt dans le code précédant ce code d’arrêt et essayer d’avancer pas à pas dans le code défaillant, si vous pouvez reproduire systématiquement le code d’arrêt.
Pour plus d’informations, veuillez consulter la section Analyser les fichiers de vidage sur incident en utilisant WinDbg.
Si vous n’êtes pas équipé pour utiliser le débogueur Windows pour travailler sur ce problème, vous pouvez utiliser certaines techniques de dépannage de base.
Vérifiez le journal système dans l’Observateur d’événements pour d’autres messages d’erreur qui pourraient aider à identifier le périphérique ou le pilote à l’origine de cette erreur d’arrêt.
Si un pilote est identifié dans le message de bug check, désactivez le pilote ou vérifiez auprès du fabricant les mises à jour du pilote.
Vérifiez que tous les logiciels liés aux graphismes tels que DirectX et OpenGL sont à jour, et que toutes les applications intensives en graphismes (comme les jeux) sont entièrement corrigées.
Assurez-vous que tout nouveau matériel installé est compatible avec la version de Windows installée. Par exemple, vous pouvez obtenir des informations sur le matériel requis sur les Spécifications de Windows 10.
Exécutez l’outil de diagnostic de la mémoire Windows pour tester la mémoire. Dans la boîte de recherche du panneau de configuration, saisissez Mémoire, puis sélectionnez Diagnostiquer les problèmes de mémoire de votre ordinateur. Après l’exécution du test, utilisez l’Observateur d’événements pour consulter les résultats dans le journal Système. Recherchez l’entrée MemoryDiagnostics-Results pour afficher les résultats.
Vous pouvez essayer d’exécuter les diagnostics matériels fournis par le fabricant du système.
Utilisez le Mode sans échec
Envisagez d’utiliser le mode sans échec pour aider à isoler ce problème. L’utilisation du mode sans échec charge uniquement les pilotes et services système minimum requis pendant le démarrage de Windows.
- Pour entrer en Mode sans échec, allez dans Mise à jour et sécurité dans les Paramètres.
- Sélectionnez Récupération>Démarrage avancé pour démarrer en mode maintenance.
- Dans le menu résultant, choisissez Dépannage>Options avancées>Paramètres de démarrage>Redémarrer.
- Après le redémarrage de Windows sur l’écran Paramètres de démarrage, sélectionnez l’option 4, 5 ou 6 pour démarrer en mode sans échec.
Le mode sans échec peut être disponible en appuyant sur une touche de fonction au démarrage, par exemple F8. Consultez les informations du fabricant pour des options de démarrage spécifiques.
Pour des informations générales de dépannage, veuillez consulter la section Analyser les données d’erreur d’arrêt d’écran bleu.
Notes
Pour obtenir des informations sur les exigences que les périphériques matériels doivent respecter lorsqu’ils implémentent TDR, veuillez consulter la documentation du Windows Hardware Lab Kit. Par exemple, TDR2 : Test standard de deux périphériques graphiques.