Boucle de crash du pilote NVIDIA/AMD : réinstallation propre correctement (DDU + Mode Sans Échec)

À quoi ressemble une boucle de crash de pilote (et ce que ce n’est pas)

Une « boucle de crash de pilote » est généralement la pile graphique de Windows qui réinitialise à plusieurs reprises le pilote d’affichage. Vous observez :

• Clignotement de l’écran vers le noir puis de retour, souvent juste après la connexion.
• Applications qui se ferment avec des erreurs « device removed »/« device hung » (DirectX/Vulkan).
• Journaux dans l’Observateur d’événements tels que « Display driver nvlddmkm stopped responding and has successfully recovered » ou équivalents AMD.
• Écran noir bloqué avec un curseur, ou bureau chargé mais inutilisable.
• Ventilateurs qui montent brièvement en régime, puis silence, puis remontée.

Ce que ce n’est pas (la plupart du temps) :

• Un plantage de jeu isolé suivi d’un bureau stable. C’est généralement le jeu, une superposition, ou un undervolt.
• Une extinction complète du système sous charge. C’est souvent l’alimentation (PSU), le câblage d’alimentation, les VRM, ou un arrêt thermique.
• Artefacts constants sur l’écran de démarrage du BIOS. C’est souvent une détérioration physique de la mémoire GPU ou du cœur.

Si vous obtenez une boucle spécifiquement après une mise à jour de pilote, une mise à jour Windows, ou un changement de GPU, considérez-le comme un problème d’intégrité d’installation jusqu’à preuve du contraire. L’objectif est de vous ramener à un pilote de base stable avec un minimum de superstition.

Blague n°1 (courte, pertinente) : Une boucle de crash de pilote GPU est le seul tapis roulant où l’ordinateur fait la course et vous perdez quand même vos progrès.

Mode d’action pour diagnostic rapide (premier/deuxième/troisième)

Premier : confirmer qu’il s’agit d’une boucle de réinitialisation du pilote, pas d’un effondrement d’alimentation/matériel

• Vérifier l’Observateur d’événements pour des réinitialisations de pilote d’affichage et des événements TDR.
• Vérifier le Moniteur de fiabilité pour des entrées récurrentes « Windows Hardware Error Architecture » ou « LiveKernelEvent ».
• Contrôle de température si vous pouvez rester dans Windows 60 secondes : si le GPU atteint instantanément les limites thermiques, c’est un problème de refroidissement ou de pâte thermique.

Décision : Si le système s’éteint brutalement, redémarre sans journaux, ou montre des artefacts dans le BIOS, arrêtez la danse du pilote et examinez le PSU, les câbles et le matériel GPU. Si ce sont des réinitialisations récupérables et des clignotements noirs, poursuivez avec un workflow d’installation propre du pilote.

Deuxième : empêcher Windows de « réparer » à votre place

• Déconnectez le réseau ou désactivez temporairement les mises à jour de pilotes via Windows.
• Identifiez si Windows réinjecte un ancien pilote juste après la désinstallation.

Décision : Si vous désinstallez et que le pilote revient au redémarrage sans votre intervention, Windows Update ou le DriverStore réinfecte le système. Vous devez isoler et contrôler cela.

Troisième : isoler la pile pilote et les surcouches

• Démarrez en Mode Sans Échec pour supprimer le pilote fournisseur actif.
• Retirez les couches de conflit connues (enregistreurs d’overlay, pilotes noyau RGB, outils de monitoring) seulement après avoir capturé les journaux.

Décision : Si le Mode Sans Échec est stable et le mode normal ne l’est pas, vous êtes face à un problème de pilote/pile, pas à « Windows est cassé ». Vous pouvez le réparer avec de la discipline.

Faits et contexte intéressants (pour comprendre le comportement)

1. TDR existe pour garder votre bureau vivant. Windows Timeout Detection and Recovery (TDR) réinitialise le pilote GPU quand le GPU semble gelé, au lieu de forcer un redémarrage. Pratique pour la disponibilité, perturbant pendant les pannes.
2. WDDM a tout changé. Depuis Windows Vista, le Windows Display Driver Model a déplacé la planification GPU et la gestion mémoire dans un modèle plus structuré. Cela a globalement amélioré la stabilité, mais rendu les résidus partiels de pilote plus « intéressants ».
3. Windows conserve un entrepôt de pilotes. DriverStore met en cache les packages de pilotes afin que Windows puisse les réappliquer. C’est excellent quand votre pilote de NIC disparaît — moins quand il ressuscite un package d’affichage défectueux.
4. DDU est devenu populaire parce que les désinstalleurs ne sont pas des chirurgiens. Les désinstalleurs des fournisseurs laissent souvent des clés de registre, des services, des packages de pilotes et des paramètres destinés aux « mises à niveau fluides ». Les mises à niveau fluides sont exactement ce que vous ne voulez pas dans une boucle de crash.
5. « Installation propre » dans l’installateur NVIDIA n’est pas DDU. Cela réinitialise certains paramètres et profils, mais ne désinfecte pas entièrement le DriverStore ni ne supprime tous les artéfacts.
6. Le multi-GPU hybride ajoute de la complexité. Les portables avec iGPU + dGPU (Optimus, Advanced Optimus, AMD Switchable Graphics) peuvent échouer de façons que les desktops ne connaissent pas — mauvais périphérique en chemin principal, mauvais état d’alimentation, mauvais mode de commutateur (mux).
7. Hardware-accelerated GPU scheduling (HAGS) est relativement récent. Il peut être bénéfique, mais ajoute un élément supplémentaire dans la chaîne. Quand tout est instable, avoir moins d’éléments en mouvement est une stratégie valide.
8. « Studio » vs « Game Ready » est surtout de l’emballage et du rythme de validation. Ce n’est pas magique. Mais changer de branche peut éviter une régression quand une piste distribue un bug en premier.

Points de décision : logiciel, configuration ou matériel ?

Vous ne voulez pas passer trois heures à faire un nettoyage DDU parfait si le GPU est en train de tomber en panne physiquement. Inversement, vous ne voulez pas RMA un GPU parce que Windows Update a réinstallé un pilote incompatible.

Signes plutôt logiciels/configuration

• Le Mode Sans Échec est stable ; le mode normal clignote et se réinitialise.
• Le problème a commencé immédiatement après une mise à jour de pilote ou une mise à jour Windows.
• L’Observateur d’événements montre des réinitialisations répétées du pilote d’affichage (TDR) sans redémarrages matériels.
• Passer au Microsoft Basic Display Adapter arrête la boucle.
• Différentes versions de pilote se comportent différemment (même si aucune n’est parfaite).

Signes plutôt matériel/alimentation

• Artefacts dans le BIOS/UEFI ou avant le chargement de Windows.
• Le système perd l’alimentation sous charge (extinction instantanée) sans journaux utiles.
• La boucle de crash du pilote persiste après une installation propre de l’OS.
• Températures GPU ou hotspots qui bondissent anormalement au repos, ou ventilateurs qui ne fonctionnent pas.
• Changer l’alimentation PSU/câbles/emplacement modifie davantage les symptômes que changer le pilote.

Il existe aussi une zone grise : undervolts/overclocks instables, RAM défaillante, ou PSU limite peuvent se manifester comme des « crashes de pilote » parce que le pilote est le composant forcé de gérer l’échec. Les pilotes se font accuser parce qu’ils sont sur la scène du crime.

Une idée paraphrasée à garder sur un post-it : paraphrased idea — Werner Vogels (mindset fiabilité : tout échoue, donc concevez et opérez en conséquence). C’est exactement la façon de traiter les pilotes GPU dans une station de travail de production : supposez qu’ils peuvent échouer et construisez un chemin de récupération.

Tâches pratiques avec commandes (12+), sorties et décisions

Ces tâches sont conçues pour Windows 10/11. Les commandes sont exécutables dans une Invite de commandes élevée ou PowerShell. J’utilise une invite de style Linux dans les blocs de code pour des contraintes de formatage ; les commandes elles-mêmes sont natives Windows.

Tâche 1 : Confirmer le GPU et la version actuelle du pilote (équivalent Gestionnaire de périphériques via PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,DriverDate | Format-List"

Name          : NVIDIA GeForce RTX 3080
DriverVersion : 31.0.15.5161
DriverDate    : 12/01/2023 00:00:00

Ce que cela signifie : Vous voyez le pilote actif que Windows croit chargé.

Décision : Si la version n’est pas celle que vous avez installée (ou change après redémarrage), Windows Update ou un autre package la remplace.

Tâche 2 : Trouver les réinitialisations du pilote d’affichage (Observateur d’événements via wevtutil)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=4101)]]" /c:5 /f:text

Event[0]:
  Log Name: System
  Source: Display
  Event ID: 4101
  Level: Warning
  Description:
  Display driver nvlddmkm stopped responding and has successfully recovered.

Ce que cela signifie : L’Event ID 4101 est le symptôme classique de récupération TDR pour les pilotes d’affichage.

Décision : Si 4101 se répète à intervalles serrés après le démarrage/la connexion, vous êtes face à une boucle de crash, pas à un plantage d’application ponctuel.

Tâche 3 : Vérifier les indices LiveKernelEvent / WHEA (données du Moniteur de fiabilité via WMI)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ReliabilityRecords | Where-Object { $_.SourceName -match 'Windows' -or $_.SourceName -match 'Hardware' } | Select-Object -First 5 TimeGenerated,SourceName,ProductName,Message | Format-List"

TimeGenerated : 2/4/2026 9:12:10 AM
SourceName    : Windows
ProductName   : Windows
Message       : The Desktop Window Manager process has exited.

Ce que cela signifie : DWM qui se ferme de manière répétée corrèle souvent avec une instabilité du pilote GPU.

Décision : Si vous voyez des erreurs WHEA corrigées en parallèle des réinitialisations GPU, considérez la stabilité PSU/RAM/PCIe comme contributrice.

Tâche 4 : Identifier les packages de pilote dans DriverStore (pnputil)

cr0x@server:~$ pnputil /enum-drivers | findstr /i "nvidia amd display"

Published Name : oem42.inf
Original Name  : nv_dispi.inf
Provider Name  : NVIDIA
Class Name     : Display adapters

Published Name : oem17.inf
Original Name  : u0397489.inf
Provider Name  : Advanced Micro Devices, Inc.
Class Name     : Display adapters

Ce que cela signifie : DriverStore contient un ou plusieurs packages de pilotes d’affichage — parfois plusieurs fournisseurs si vous avez changé de GPU.

Décision : Si des packages obsolètes existent pour le mauvais fournisseur, planifiez de les supprimer lors du nettoyage pour éviter la « résurrection » du pilote.

Tâche 5 : Supprimer un package de pilote spécifique (avec précaution)

cr0x@server:~$ pnputil /delete-driver oem42.inf /uninstall /force

Driver package deleted successfully.

Ce que cela signifie : Cela supprime le package du DriverStore et désinstalle les périphériques qui l’utilisent.

Décision : Si la suppression échoue à cause de « en cours d’utilisation », vous n’êtes pas proprement détaché — utilisez le Mode Sans Échec, ou désactivez d’abord le périphérique.

Tâche 6 : Confirmer que Windows n’installe pas automatiquement de pilotes (Paramètres d’installation de périphériques via le registre)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" /v SearchOrderConfig

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching
    SearchOrderConfig    REG_DWORD    0x1

Ce que cela signifie : 1 signifie typiquement que Windows est autorisé à rechercher des pilotes via Windows Update.

Décision : Pour une reconstruction contrôlée, définissez temporairement ceci à 0 et/ou déconnectez le réseau avant la réinstallation.

Tâche 7 : Désactiver les mises à jour automatiques de pilotes via le registre (contrôle temporaire)

cr0x@server:~$ reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" /v SearchOrderConfig /t REG_DWORD /d 0 /f

The operation completed successfully.

Ce que cela signifie : Windows devrait cesser de récupérer automatiquement des pilotes depuis Windows Update.

Décision : Faites cela avant le nettoyage/la réinstallation, puis remettez en place si votre environnement l’exige.

Tâche 8 : Vérifier la configuration de démarrage en Mode Sans Échec (bcdedit)

cr0x@server:~$ bcdedit /enum | findstr /i safeboot

safeboot                  Minimal

Ce que cela signifie : Le système est configuré pour démarrer en Mode Sans Échec (Minimal).

Décision : Utilisez ceci si vous ne pouvez pas accéder de manière fiable aux options de démarrage avancées.

Tâche 9 : Définir le Mode Sans Échec pour le prochain démarrage (puis redémarrer)

cr0x@server:~$ bcdedit /set {current} safeboot minimal

The operation completed successfully.

Ce que cela signifie : Le prochain démarrage ira en Mode Sans Échec.

Décision : Après le nettoyage, supprimez le drapeau safeboot sinon vous continuerez à démarrer en Mode Sans Échec et vous vous demanderez pourquoi le son manque.

Tâche 10 : Supprimer le flag Mode Sans Échec (retour au démarrage normal)

cr0x@server:~$ bcdedit /deletevalue {current} safeboot

The operation completed successfully.

Ce que cela signifie : Rétablit le comportement de démarrage normal.

Décision : Exécutez ceci après DDU et lorsque vous êtes prêt à installer le nouveau pilote.

Tâche 11 : Vérifier si Windows utilise Microsoft Basic Display Adapter (bon référentiel)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Display | Format-Table -AutoSize Status,Class,FriendlyName,InstanceId"

OK     Display  Microsoft Basic Display Adapter  PCI\VEN_10DE&DEV_2206&SUBSYS...

Ce que cela signifie : Vous êtes sur le pilote générique. Résolution moche, mais assez stable pour travailler.

Décision : Si Basic Display Adapter est stable, votre boucle de crash se situe presque certainement dans le pilote fournisseur ou la couche de paramètres.

Tâche 12 : Capturer les logiciels GPU installés pouvant hooker la pile

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object { $_.DisplayName -match 'NVIDIA|AMD|Radeon|GeForce|Afterburner|Rivatuner|Overlay' } | Select-Object DisplayName,DisplayVersion | Sort-Object DisplayName | Format-Table -AutoSize"

AMD Software                         24.1.1
MSI Afterburner                      4.6.5
RivaTuner Statistics Server          7.3.5

Ce que cela signifie : Vous avez des outils potentiels de hook/overlay installés.

Décision : N’installez pas tout aveuglément. Mais si une installation propre de pilote boucle encore, supprimez ensuite les overlays et outils de monitoring.

Tâche 13 : Vérifier l’intégrité des fichiers système (parce que les crashes corrompent des choses)

cr0x@server:~$ sfc /scannow

Beginning system scan. This process will take some time.
Windows Resource Protection found corrupt files and successfully repaired them.

Ce que cela signifie : Les fichiers système Windows étaient endommagés et ont été réparés.

Décision : Si SFC répare des fichiers, suivez avec une réparation DISM ; des pilotes instables peuvent laisser l’OS à moitié cassé.

Tâche 14 : Réparer le magasin de composants Windows (DISM)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth

Deployment Image Servicing and Management tool
Version: 10.0.22621.1
The restore operation completed successfully.

Ce que cela signifie : Le magasin de composants est à nouveau sain.

Décision : Si DISM échoue de manière répétée, vous pourriez faire face à une corruption OS plus profonde — réparez cela avant d’accuser le pilote GPU.

Tâche 15 : Vérifier si le GPU lance des erreurs WHEA PCIe (signal matériel)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger'] and (EventID=17 or EventID=18)]]" /c:5 /f:text

Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  Level: Warning
  Description:
  A corrected hardware error has occurred.

Ce que cela signifie : Les erreurs matérielles corrigées peuvent corréler avec une instabilité PCIe, un PSU marginal, des câbles riser, ou des overclocks agressifs.

Décision : Si les événements WHEA augmentent lors des réinitialisations de pilote, pensez à retirer les risers, reseater la carte, mettre à jour le BIOS/jeux de puces, et réduire overclocks/undervolts.

Listes de vérification / plan pas à pas (DDU + Mode Sans Échec)

Principes (règles qui évitent de refaire le travail)

• Contrôlez l’environnement : pas de surprise Windows Update en plein nettoyage.
• Supprimez les pilotes quand ils ne sont pas actifs : le Mode Sans Échec réduit les verrouillages de fichiers et les services en cours.
• Redémarrez aux bons moments : pas sans arrêt, mais pas jamais non plus.
• Changez une variable à la fois : ne « modifiez pas aussi la clé TdrDelay et l’undervolt » dans la même passe.

Checklist pré-vol (5 minutes, épargne des heures)

1. Téléchargez l’installateur de pilote correct pour votre GPU et votre OS à l’avance. Placez-le sur le bureau. Vous serez hors-ligne ensuite.
2. Téléchargez DDU (Display Driver Uninstaller) à l’avance et extrayez-le dans un dossier connu (par ex., C:\Tools\DDU).
3. Notez vos réglages actuels de tuning GPU (Afterburner/Adrenalin) et rétablissez les valeurs par défaut si possible. Si vous ne pouvez pas, ne paniquez pas — on peut toujours faire une installation propre.
4. Déconnectez le réseau (débranchez Ethernet, désactivez le Wi‑Fi) ou mettez la recherche de pilotes sur off (Tâche 7). Faites les deux si Windows a été particulièrement « serviable ».
5. Créez un point de restauration si le système est suffisamment stable. Pas parce que les points de restauration sont parfaits, mais parce que c’est une assurance peu coûteuse.

Pas à pas : le workflow d’installation propre qui fonctionne vraiment

1. Forcer le Mode Sans Échec pour le prochain démarrage (si vous ne pouvez pas accéder de manière fiable au menu de démarrage avancé).

   cr0x@server:~$ bcdedit /set {current} safeboot minimal
   
   The operation completed successfully.

   Décision : Si cela échoue avec accès refusé, votre shell n’est pas élevé. Corrigez cela d’abord.

2. Redémarrer en Mode Sans Échec.

   En Mode Sans Échec, le système devrait utiliser un pilote de base et être moins enclin aux crashes. Si le Mode Sans Échec lui-même plante, orientez votre suspicion vers le matériel ou une corruption sévère de l’OS.

3. Exécuter DDU en tant qu’administrateur et choisir le bon type de périphérique (GPU) et le bon fournisseur (NVIDIA ou AMD).

   Paramètres généralement souhaités : empêcher les téléchargements de pilotes depuis Windows Update (DDU peut définir des politiques). C’est l’un de ces moments où un outil autoritaire est une fonctionnalité.

   Action : « Clean and restart » est le choix normal. « Clean and shutdown » est utile si vous échangez physiquement des GPU.

4. Après le redémarrage demandé par DDU, supprimer le flag Mode Sans Échec afin de pouvoir démarrer normalement.

   cr0x@server:~$ bcdedit /deletevalue {current} safeboot
   
   The operation completed successfully.

   Décision : Si vous oubliez ceci, vous continuerez à démarrer en Mode Sans Échec et mal diagnostiquer « le pilote ne s’est pas installé ». Il s’est installé ; vous êtes simplement en Mode Sans Échec.

5. Rester hors ligne et démarrer en mode normal.

   À ce stade, Windows doit fonctionner sur Microsoft Basic Display Adapter. La résolution peut être incorrecte. C’est acceptable. La stabilité est l’objectif.

   Vérifiez :

   cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Display | Select-Object -ExpandProperty FriendlyName"
   
   Microsoft Basic Display Adapter

6. Installer le pilote que vous avez téléchargé, pas celui que Windows voudrait récupérer.
   • NVIDIA : envisagez « Driver only » si vous dépannez, et évitez GeForce Experience jusqu’à stabilisation.
   • AMD : choisissez l’option « Factory Reset » seulement si vous n’avez pas déjà utilisé DDU (DDU a déjà fait le gros du travail). Si vous avez utilisé DDU, vous n’avez généralement pas besoin des deux.

   Décision : Si la boucle de crash revient pendant l’installation, annulez et redémarrez ; puis essayez une version de pilote différente connue pour être stable (souvent la version précédente). C’est là où « le dernier » n’est pas une vertu.

7. Redémarrer une fois après l’installation.

   N’empilez pas d’autres changements pour l’instant. D’abord, confirmez la stabilité et la version correcte du pilote :

   cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion | Format-Table -AutoSize"
   
   Name                       DriverVersion
   ----                       -------------
   NVIDIA GeForce RTX 3080    31.0.15.5161

8. Rétablir le réseau et confirmer que Windows n’écrase pas le pilote.

   Attendez quelques minutes. Redémarrez encore une fois. Vérifiez la version du pilote. Si elle a changé, vous avez un problème de politique de mise à jour de pilote (voir Erreurs courantes).

9. Seulement après stabilité : réintroduire les couches logicielles.

   Overlays, monitoring, pilotes RGB, outils de capture — réintroduisez-les un par un. Oui, c’est fastidieux. C’est pourquoi ça marche.

Blague n°2 (courte, pertinente) : Le Mode Sans Échec est comme un exercice d’évacuation incendie pour votre PC — tout a l’air pire, mais vous pouvez enfin voir qui met le feu.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe média disposait de plusieurs stations de travail Windows haut de gamme pour l’étalonnage couleur et l’encodage accéléré par GPU. Une mise à jour de pilote a été déployée dans le cadre d’un « patch routinier ». Le lendemain matin, une machine a commencé à clignoter au noir toutes les quelques secondes. L’opérateur a fait ce que tout le monde fait : réinstaller le dernier pilote encore une fois, parce que « peut-être qu’il était corrompu ». Ça a empiré.

La mauvaise hypothèse : l’installeur est autoritaire. Ils ont supposé que si l’installeur s’était terminé, le système utilisait cette version. En réalité, Windows Update avait un pilote d’affichage dans sa file d’attente et courait en parallèle avec l’installeur fournisseur. Après chaque redémarrage, le système se retrouvait sur un build de pilote différent avec des composants différents. L’utilisateur vivait ça comme de l’aléatoire. Les opérations le vivaient comme un ticket support qui se reproduisait seulement quand personne ne regardait.

Nous avons extrait un jeu de journaux : rafales d’Event ID 4101 après la connexion, version du pilote changeant entre les redémarrages, et plusieurs INF OEM dans le DriverStore pour NVIDIA et une ancienne carte AMD utilisée six mois plus tôt. Personne ne se rappelait de cet ancien changement. La machine si.

La correction n’a rien d’héroïque : isoler la station du réseau, démarrer en Mode Sans Échec, exécuter DDU, supprimer les packages obsolètes, installer une branche de pilote connue stable, puis réintroduire la connectivité réseau seulement après avoir confirmé que la version du pilote restait la même. La boucle a disparu. L’étape la plus précieuse fut la moins glamour : empêcher Windows de « aider ».

La leçon post-mortem fut sans détour : vous n’avez pas une version de pilote tant que vous ne pouvez pas prouver qu’elle persiste après un redémarrage avec Windows Update activé. Tout le reste, ce sont des impressions.

Mini-récit 2 : L’optimisation qui a eu l’effet inverse

Un département financier utilisait des graphiques accélérés par GPU sur des postes de trading. Quelqu’un a lu que « désactiver TDR améliore les performances » pour de longues tâches compute GPU et a décidé de standardiser un changement de registre pour augmenter les délais TDR. Ce n’était pas malveillant. C’était le classique « faire disparaître l’erreur en la cachant ».

Ça a fonctionné pendant exactement une semaine. Puis un sous-ensemble de machines a commencé à geler sévèrement au lieu de récupérer. Avant le changement, un blocage GPU déclenchait une réinitialisation du pilote, l’application plantait, et l’utilisateur la relançait. Ennuyeux, mais vivable. Après le changement, l’OS attendait plus longtemps avant de décider que le GPU était bloqué. Cela signifiait que tout le bureau restait non réactif pendant des périodes plus longues. Les gens interprétaient cela comme « le PC est mort », et ils coupaient l’alimentation — souvent en plein écritures disque.

L’effet de second ordre fut pire : les coupures forcées entraînaient parfois des réparations du système de fichiers au démarrage, une corruption de profils, et une machine qui est restée bloquée dans une boucle de réparation automatique. La « modification de performance » avait transformé une panne récupérable au niveau application en un problème de fiabilité système.

Nous avons annulé l’astuce TDR, retourné aux délais par défaut, puis corrigé la cause réelle : une version de pilote spécifique + combinaison d’overlay qui déclenchait des hangs lors de changements rapides de modes multi-écrans. Les stations sont redevenues prévisibles : si un blocage survenait, il récupérait rapidement, était clairement journalisé, et n’encourageait pas les utilisateurs à couper l’alimentation.

Leçon : ne touchez pas aux mécanismes de détection de panne avant de comprendre ce qu’ils détectent. TDR n’est pas votre ennemi ; c’est votre parachute.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la mise

Une organisation d’ingénierie entretenait un laboratoire de machines Windows pour valider des builds accélérés par GPU. Rien de glamour. Juste des boîtes devant rester stables et reproductibles. L’équipe avait l’habitude d’une procédure qui semblait bureaucratique : chaque machine avait une « fiche de base de pilote » listant le modèle GPU, la branche de pilote, le nom exact du fichier d’installateur, et la date de certification pour le labo.

Un après-midi, plusieurs machines ont commencé à montrer des réinitialisations de pilote après une mise à jour cumulative Windows de routine. La panique a failli se produire. Mais la fiche de base a rendu le processus ennuyeux. Ils ont comparé les versions de pilotes, vu que deux machines avaient dérivé vers un build différent, et identifié rapidement que Windows Update avait poussé un nouveau pilote d’affichage uniquement sur ces deux-là.

La réponse fut simple et rapide : isoler le réseau, Mode Sans Échec, DDU, réinstaller le pilote de base, et appliquer une politique pour bloquer les mises à jour automatiques de pilotes pour cette classe de périphérique. La « réparation » a pris moins d’une heure parce que l’équipe ne débattait pas de ce qu’était un état « bon ». Ils avaient déjà un état connu-bon et les moyens d’y revenir.

C’est la vérité peu sexy de la fiabilité : une voie de rollback propre vaut plus que mille astuces intelligentes. La fiche de base n’a pas empêché l’incident, mais elle a évité le thrash. En production, c’est une victoire.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : le pilote se réinstalle après que vous l’ayez désinstallé

Cause racine : Windows Update et/ou DriverStore contient un package de pilote d’affichage qui s’applique automatiquement au démarrage.

Correction : Déconnectez le réseau ; mettez SearchOrderConfig à 0 ; utilisez DDU en Mode Sans Échec ; supprimez les packages obsolètes avec pnputil. Vérifiez que la version du pilote persiste après redémarrage avec le réseau réactivé.

2) Symptom : Mode Sans Échec stable, mode normal en boucle de crash

Cause racine : pile du pilote fournisseur, paramètres, ou logiciels hook (overlay/monitoring/RGB) déclenchant des réinitialisations.

Correction : DDU en Mode Sans Échec ; installation propre du pilote ; retarder l’installation des overlays ; tester la stabilité entre chaque changement.

3) Symptom : écran noir après l’installation, mais le système est « vivant » (RDP fonctionne)

Cause racine : problème de chemin/mode de sortie d’affichage (EDID multi-écran, fréquence, HDR, négociation câble/port) ou mauvaise résolution par défaut au redémarrage.

Correction : Démarrez en Mode Sans Échec et supprimez le pilote ; démarrez en mode normal avec Basic Display Adapter ; reconnectez un seul écran sur un port/câble connu bon ; installez le pilote ; puis rebranchez les autres écrans.

4) Symptom : réinitialisations « nvlddmkm » ou pilote AMD seulement au lancement de jeux

Cause racine : OC/UV instable, état de cache de shaders corrompu, conflit d’overlay, ou régression du pilote avec un chemin API spécifique.

Correction : rétablir le GPU en stock ; vider les caches de shaders via l’UI du pilote ; réinstaller le pilote ; désactiver les overlays ; si le problème persiste, revenir d’une branche de pilote.

5) Symptom : clignotement aléatoire + réinitialisations après une mise à jour Windows, surtout avec plusieurs écrans

Cause racine : la mise à jour a changé le comportement du sous-système graphique ; interactions HAGS/VRR/HDR ; bizarreries de firmware d’écran.

Correction : désactiver temporairement HAGS et VRR ; tester en mono-écran ; réinstaller un pilote stable ; mettre à jour le firmware des écrans si applicable.

6) Symptom : la boucle de crash persiste même après DDU et réinstallation

Cause racine : corruption OS profonde, pilotes noyau conflictuels, ou instabilité matérielle réelle (PCIe, PSU, GPU).

Correction : exécuter SFC/DISM ; vérifier les événements WHEA ; reseat le GPU ; retirer les risers ; tester une autre PSU/câbles ; exécuter un test mémoire ; envisager une réinstallation propre de l’OS ou un RMA matériel si des artefacts BIOS apparaissent.

7) Symptom : redémarrages matériels ou extinctions sous charge GPU

Cause racine : problème d’alimentation, gestion des transitoires PSU, problème de câble/connecteur, ou protection VRM/thermique.

Correction : séparer les câbles d’alimentation PCIe (pas de chaînage sur les cartes haut de gamme), vérifier les connecteurs, réduire la limite de puissance pour tester, vérifier la capacité/qualité du PSU, inspecter températures et hotspots.

8) Symptom : option « installation propre » utilisée, mais les problèmes persistent

Cause racine : l’« installation propre » du fournisseur n’est pas une suppression complète ; des restes subsistent dans DriverStore/services/paramètres.

Correction : Utilisez DDU en Mode Sans Échec et contrôlez Windows Update. Traitez l’option d’installation propre du fournisseur comme une commodité, pas comme un outil de remédiation.

Esprit opérationnel : pourquoi DDU + Mode Sans Échec est le choix par défaut adéquat

En termes SRE, une boucle de crash de pilote est une dépendance qui flappe. Le pilote d’affichage échoue de manière répétée, Windows récupère de manière répétée, et votre station est coincée dans un état de panne partielle. L’instinct est de « faire quelque chose » à répétition — réinstaller, redémarrer, réinstaller encore — jusqu’à ce que ça se stabilise magiquement.

Cette approche échoue parce que le système n’est pas déterministe pendant la boucle. Les fichiers sont verrouillés. Les services sont en cours de démarrage. Windows Update vous court après. Les paramètres sont à moitié appliqués. C’est comme essayer de remplacer un disque pendant que le contrôleur RAID remet sans arrêt le même mauvais membre depuis un placard.

Le Mode Sans Échec réduit le nombre de composants actifs. DDU réduit le nombre d’artéfacts restants. Combinés, ils créent une fenêtre de maintenance prévisible où vous pouvez réellement faire converger le système vers un état connu.

Détails du workflow DDU qui comptent (et les parties que les gens sautent)

Être hors ligne n’est pas optionnel (si vous avez vu la « résurrection » du pilote)

Si Windows peut atteindre Windows Update, il peut récupérer un pilote au moment parfaitement inopportun — entre votre désinstallation et votre réinstallation. Cela peut vous laisser avec des composants mismatches : panneau de configuration d’une version, noyau du pilote d’une autre, pilote audio d’une troisième. C’est comme ça que vous perdez l’audio HDMI, ou que le panneau de contrôle refuse de s’ouvrir, ou que le pilote se réinitialise quand vous ouvrez l’UI des paramètres.

Conseil pratique : débranchez l’Ethernet. Désactivez le Wi‑Fi. Ensuite faites le travail. Si vous êtes en environnement corporate où c’est difficile, utilisez un blocage par politique des mises à jour de pilotes, et validez-le.

Supprimez seulement ce que vous avez l’intention de supprimer

DDU est puissant. Tout comme pnputil /delete-driver. Le pouvoir n’est pas la sagesse.

• Si vous êtes sur NVIDIA, n’allez pas supprimer des pilotes de chipset parce que « ils disaient aussi NVIDIA ». NVIDIA publie parfois des packages chipset pour certaines plateformes ; supprimer la mauvaise chose peut casser le stockage ou le réseau.
• Si vous êtes sur AMD, rappelez-vous qu’AMD touche GPU et écosystème chipset. Soyez précis sur ce que vous supprimez.

La cible est les packages de pilote d’affichage et leurs services/paramètres — rien de plus. On désinfecte la pile graphique, pas on exorcise la machine.

Les redémarrages font partie de la convergence d’état

Les gens redémarrent après chaque clic ou évitent les redémarrages comme s’ils coûtaient cher. Le bon nombre est : redémarrez quand l’outil de nettoyage vous le demande, et redémarrez une fois après l’installation. Ajoutez un redémarrage supplémentaire si vous validez « le pilote persiste au démarrage avec le réseau activé ? ». C’est tout.

Gardez un pilote connu-bon à portée de main

« Le dernier » est excellent pour les fonctionnalités et les fixes de jeux. « Connu-bon » est excellent pour le travail. Si vous dépannez, privilégiez la stabilité. Utilisez une version de pilote que vous avez déjà testée sans problème, ou une version validée par votre organisation.

FAQ

1) Ai-je vraiment besoin de DDU ? Ne puis‑je pas juste désinstaller via Applications et fonctionnalités ?

Si vous êtes dans une boucle de crash, oui, vous avez souvent besoin de DDU. Les désinstalleurs d’applications ne suppriment pas de manière fiable les packages DriverStore, les services et les paramètres de façon à empêcher la réapplication. DDU en Mode Sans Échec vous donne une base propre.

2) La case « Clean installation » de NVIDIA suffit‑elle ?

Non. Elle réinitialise certains paramètres et profils, mais ce n’est pas équivalent à supprimer des packages de pilote et empêcher Windows d’en réinstaller un autre. Utilisez-la comme commodité après que vous êtes stable, pas comme outil principal de remédiation.

3) Dois‑je installer GeForce Experience / outils overlay AMD pendant le dépannage ?

Pas au début. Obtenez le pilote stable avec le minimum d’extras. Puis rajoutez les outils de gestion si nécessaire. Chaque overlay et enregistreur est un hook supplémentaire dans la pipeline graphique.

4) Que faire si le Mode Sans Échec boucle encore ?

C’est un signal rouge. Causes possibles : corruption sévère de l’OS, stockage défaillant, ou instabilité matérielle suffisamment grave pour que même les chemins d’affichage basiques déclenchent des problèmes. Exécutez SFC/DISM, vérifiez les journaux WHEA, et envisagez des vérifications matérielles (reseat GPU, PSU/câblage, test RAM).

5) Dois‑je modifier les clés TDR comme TdrDelay ?

Généralement non. Les ajustements TDR sont un dernier recours pour des charges spécifiques (par ex. longs kernels compute GPU) et peuvent transformer des hangs récupérables en gels prolongés. Traitez la cause racine d’abord : version du pilote, overlays, alimentation/thermique, ou intégrité de l’OS.

6) Pourquoi la boucle de crash se produit‑elle juste après la connexion ?

La connexion déclenche beaucoup d’activité accélérée par GPU : composition DWM, applications de démarrage, overlays, configuration multi-écrans, négociation HDR/VRR, et changements d’état d’alimentation. Si le pilote est fragile, ce pic est l’endroit où il se manifeste.

7) J’ai changé d’AMD à NVIDIA (ou inversement). Est‑ce spécial ?

Oui. Les changements inter‑fournisseurs laissent souvent des packages et services derrière eux. Windows peut aussi conserver d’anciens packages dans DriverStore. DDU plus nettoyage du DriverStore est la bonne méthode, et « clean and shutdown » dans DDU est utile si vous échangez physiquement les cartes.

8) Comment savoir si Windows Update écrase mon pilote ?

Vérifiez votre version de pilote (Tâche 1), redémarrez avec le réseau activé, et vérifiez encore. Si elle change sans que vous n’ayez rien installé, Windows Update ou la politique d’installation de périphérique le fait. Corrigez ça avant de continuer à tester des versions de pilote, sinon vous mesurerez le chaos.

9) Un câble HDMI/DisplayPort défectueux peut‑il causer ce qui ressemble à une boucle de crash de pilote ?

Un câble défectueux provoque généralement du flicker, des coupures ou pas de signal — pas des événements répétés de réinitialisation de pilote. Mais les problèmes de négociation multi-écrans peuvent ressembler à cela. Si les journaux montrent des réinitialisations TDR, c’est plus que le câble ; toutefois, simplifier en mono-écran sur un câble connu bon est une bonne étape d’isolation.

10) Dois‑je réinstaller complètement Windows ?

Sauvegardez cela après avoir effectué le workflow DDU contrôlé et vérifié que Windows n’introduit pas les pilotes. Si vous êtes toujours en boucle de crash sur un pilote propre sans overlays et que les vérifications d’intégrité de l’OS passent, une réinstallation propre peut séparer la pourriture logicielle de la réalité matérielle.

Conclusion : étapes suivantes qui tiennent vraiment

Si votre système est coincé dans une boucle de crash du pilote NVIDIA/AMD, arrêtez d’improviser. Le chemin fiable est :

1. Prouvez que c’est une boucle de réinitialisation du pilote (Event ID 4101, DWM qui se ferme, Moniteur de fiabilité).
2. Coupez la réinfection du pilote (hors ligne + désactiver temporairement la recherche automatique de pilotes).
3. Démarrez en Mode Sans Échec et exécutez DDU pour retirer proprement la pile fournisseur active.
4. Démarrez normalement sur Basic Display Adapter, installez un pilote connu-bon que vous avez déjà téléchargé, puis redémarrez une fois.
5. Réactivez le réseau et vérifiez que la version du pilote persiste après redémarrage.
6. Réintroduisez overlays/outils de tuning un par un. Si l’instabilité revient, vous venez de trouver le coupable.

Quand vous procédez ainsi, le système converge. Quand vous ne le faites pas, vous vous retrouvez à « tester » différentes versions de pilotes pendant que Windows Update les remplace sous vos pieds et qu’un overlay s’injecte dans chaque appel API graphique. Ce n’est pas du dépannage ; c’est de l’art performance.

Si, après une réinstallation propre disciplinée, la boucle persiste — et surtout si vous voyez des erreurs WHEA ou des artefacts BIOS — considérez-le comme un problème de stabilité matérielle. Reseat le GPU, vérifiez le câblage, testez le PSU, et réduisez tout OC/UV. Les pilotes peuvent être bogués. Le matériel peut être fatigué. Votre travail est de déterminer lequel vous ment aujourd’hui.