Ecran bleu dxgmms2.sys : les solutions

Quand un écran bleu nomme dxgmms2.sys, Windows vous dit qu’il a tenté de réinitialiser le pilote d’affichage après un dépassement de délai et que la manœuvre a échoué. Le fichier affiché est le module pointé par l’analyse du plantage, pas forcément le coupable, et les pistes utiles restent le pilote de carte graphique, sa stabilité électrique et la mémoire.

Points clés

• Le délai d’expiration par défaut du mécanisme TDR est de 2 secondes (valeur TdrDelay), et le système laisse 5 secondes aux threads pour quitter le pilote (TdrDdiDelay) avant de déclencher l’arrêt 0x116 VIDEO_TDR_FAILURE.
• Plus de cinq événements TDR en une minute suffisent aussi à provoquer un 0x116, même si chaque récupération individuelle réussit.
• D’après l’analyse Microsoft des causes racines de plantages, 70 % viennent du code d’un pilote tiers, 10 % du matériel et 5 % du code Microsoft.
• Les clés de registre TDR sont réservées au développement de pilotes : Microsoft écrit noir sur blanc que les utilisateurs finaux ne doivent pas y toucher.
• Codes d’arrêt qui accompagnent le plus souvent ce nom de fichier : 0x116, 0x117 et 0x119, tous liés au pilote d’affichage ou au planificateur vidéo.

Ce que Windows raconte réellement derrière ce nom de fichier

Un blocage graphique classique ressemble à un gel complet de la machine : plus aucune mise à jour de l’écran, souvent pendant une partie ou un rendu. Windows essaie de détecter ces situations et de récupérer un bureau réactif tout seul. Ce mécanisme s’appelle Timeout Detection and Recovery, TDR en abrégé.

Pendant la récupération, le planificateur GPU demande au pilote miniport d’affichage de se réinitialiser via la fonction DxgkDdiResetFromTimeout. Le système interdit alors au pilote de toucher au matériel et lui laisse un court délai pour terminer ses threads. Si le délai passe, l’ordinateur s’arrête avec 0x116. Si la récupération réussit, vous voyez à la place le message « le pilote d’affichage a cessé de répondre et a été récupéré ».

Le deuxième paramètre du code 0x116 est un pointeur vers le module du pilote responsable. C’est ce pointeur qui fait apparaître un nom de fichier dans les rapports, y compris ceux des utilitaires grand public. Microsoft précise pour le code 0x119 la règle qui vaut aussi ici : si le module fautif affiché par l’extension de débogage !analyze est un pilote vidéo, il faut vérifier les mises à jour disponibles chez le fournisseur de ce pilote.

Les causes qui reviennent

• Pilote graphique instable : version trop récente, trop ancienne, ou installation superposée à une précédente sans nettoyage.
• Overclocking et sous-tension : profil mémoire GPU, courbe de tension, XMP agressif. Le GPU dépasse le délai de préemption avant de rendre la main.
• Alimentation insuffisante ou usée : à-coups de consommation en jeu, écran qui gèle une seconde avant l’arrêt.
• Mémoire système défaillante : Microsoft classe les plantages dont la mémoire est trop endommagée pour être analysée parmi les 15 % de causes inconnues, et recommande de lancer tous les tests matériels et de mémoire appropriés.
• Surchauffe et poussière : le GPU se met à ralentir, puis manque le délai.
• Mise à jour récente : cumul Windows ou pilote poussé automatiquement juste avant l’apparition des écrans bleus.
• Espace disque saturé : Microsoft recommande de garder 10 à 15 % du disque libre pour un fonctionnement sain, et le fichier de vidage a besoin de place pour être écrit.

Les solutions, de la moins risquée à la plus lourde

1. Installer les mises à jour en attente. Le guide de dépannage des codes d’arrêt commence par là : dernières mises à jour cumulatives Windows, puis BIOS et microprogramme à jour côté carte mère.
2. Réinstaller proprement le pilote graphique. Récupérez le paquet chez le fabricant de la carte, désinstallez d’abord la version en place, puis installez sans conserver les réglages précédents.
3. Revenir au pilote précédent. Si les écrans bleus ont commencé après une mise à jour du pilote, l’onglet Pilote des propriétés de la carte graphique propose la restauration de la version antérieure.
4. Annuler tout overclocking. Remettez les fréquences GPU et mémoire aux valeurs d’usine, désactivez le profil mémoire dans le firmware, testez 48 heures avant de conclure.
5. Tester la mémoire. Diagnostic de mémoire Windows (mdsched.exe) pour une première passe, puis un test plus long si le doute persiste. Une barrette fautive produit des codes d’arrêt qui changent d’un plantage à l’autre.
6. Surveiller températures et alimentation. Relevez la température du GPU en charge, nettoyez les filtres, vérifiez que les connecteurs d’alimentation PCI Express sont enfoncés à fond.
7. Vérifier les fichiers système. sfc /scannow, puis DISM /Online /Cleanup-Image /RestoreHealth si la première commande signale des fichiers irréparables.
8. Lire le vidage mémoire. Configurez un vidage noyau, provoquez ou attendez le plantage suivant, puis ouvrez le fichier avec un débogueur et lancez !analyze -v. C’est la seule façon de savoir quel module a réellement fauté.
9. Contacter le fournisseur, ou désactiver le composant. Quand le message désigne un pilote précis et qu’aucune mise à jour n’existe, Microsoft recommande de désactiver le service associé plutôt que de continuer à planter.

Isoler l’application qui déclenche le plantage

Un écran bleu qui revient toujours dans le même contexte, jeu, montage vidéo, visioconférence, se laisse cerner sans outil de développeur. Trois étapes suffisent avant de démonter la machine.

1. Relire l’Observateur d’événements. Journaux Windows, Système : les avertissements du contrôleur d’affichage juste avant l’arrêt datent précisément le BSOD et indiquent l’application active.
2. Couper l’accélération matérielle dans le logiciel suspect, navigateur compris. Si le problème disparaît, la piste graphique est confirmée sans avoir rien désinstallé.
3. Démarrer en mode sans échec pour tourner avec un pilote d’affichage minimal. Aucune erreur en mode sans échec renvoie vers le pilote DirectX de la carte, pas vers le système.

Les cartes NVIDIA, AMD et Intel réagissent de la même façon à ce test. Le résultat dit seulement si le sous-système graphique est en cause, pas quel composant lâche : c’est déjà la moitié du diagnostic, et cela évite de télécharger au hasard un logiciel de réparation censé corriger un problème de pilote.

Ce qu’il ne faut pas faire

Deux mauvaises idées circulent. La première consiste à augmenter TdrDelay dans le registre pour laisser le GPU respirer. Cette clé existe, elle est documentée, et sa documentation dit exactement l’inverse de ce qu’on en fait : réservée aux tests et au débogage pendant le développement du pilote, à ne pas manipuler côté utilisateur final. Rallonger le délai ne corrige rien, cela retarde le symptôme.

La seconde consiste à supprimer ou renommer le fichier .sys nommé sur l’écran bleu. C’est un fichier du système : le retirer transforme un plantage occasionnel en démarrage impossible. Les codes d’arrêt liés au pilote d’affichage se corrigent par le pilote, le matériel ou la mémoire, jamais en effaçant un module du noyau.

Quand ça ne vient pas de la carte graphique

Si le nom de fichier change à chaque plantage, ou si les codes alternent entre 0x116, MEMORY_MANAGEMENT et SYSTEM_SERVICE_EXCEPTION, cherchez plus bas dans la pile : mémoire, alimentation, ou stockage. Un GPU en fin de vie donne au contraire une signature stable, souvent liée à une charge précise. La méthode de diagnostic des écrans bleus aléatoires déroule les tests dans l’ordre, et le guide des écrans bleus par code d’arrêt renvoie vers la fiche du code exact affiché.

Les deux voisins directs de ce cas méritent une lecture : VIDEO_TDR_FAILURE pour le code 0x116 lui-même, et l’écran bleu nvlddmkm.sys quand c’est le pilote NVIDIA qui est nommé.

Questions fréquentes

Faut-il désinstaller le pilote graphique avant d’en installer un autre ?

Oui, dès qu’un plantage graphique se répète. Une installation empilée sur une précédente laisse des composants dépareillés, et la manœuvre ne coûte que quelques minutes. Redémarrez entre la désinstallation et l’installation.

Un jeu qui plante toujours au même endroit accuse-t-il le GPU ?

Pas nécessairement. Une charge reproductible révèle un défaut existant plutôt qu’elle ne le crée. Testez la même scène avec les fréquences d’usine et une limite d’images par seconde basse : si les écrans bleus cessent, le problème est électrique ou thermique.

Le message « le pilote d’affichage a cessé de répondre et a été récupéré » est-il le même problème ?

C’est la version réussie du même mécanisme. La récupération TDR a fonctionné, donc pas d’écran bleu. Cinq récupérations dans la même minute font en revanche basculer le système en 0x116.

Combien de temps attendre avant de conclure qu’un correctif a marché ?

Comptez plusieurs jours d’usage normal, avec au moins deux sessions de charge graphique soutenue. Les codes liés au pilote d’affichage sont irréguliers par nature, et une accalmie de quelques heures ne prouve rien.

Le Vérificateur de pilotes est-il utile ici ?

Il sert à faire tomber le masque d’un pilote fautif, mais il rend la machine instable volontairement et peut empêcher le démarrage. Réservez-le à un diagnostic encadré, après avoir noté comment le désactiver depuis le mode sans échec.

_{Photo d’en-tête : « Gigabyte GTX 1660 Ti graphics card », Chi Ho Chan, licence CC BY 2.0 via Wikimedia Commons. Le modèle photographié sert d’illustration, il n’est pas lié à ce code d’arrêt en particulier.
Sources : Microsoft Learn, Bug Check 0x116 VIDEO_TDR_FAILURE · Microsoft Learn, clés de Registre TDR pour le test et le débogage · Microsoft Learn, Timeout Detection and Recovery · Microsoft Learn, Bug Check 0x119 VIDEO_SCHEDULER_INTERNAL_ERROR · Microsoft Learn, résolution des erreurs de code d’arrêt · Microsoft Learn, générer un vidage mémoire noyau}