Lorsqu’une erreur fatale se produit sur votre système, Windows affiche le célèbre écran bleu de la mort (ou BSoD pour Blue Screen of Death). Vous pouvez en rencontrer une lors de l’installation d’une mise à jour, d’un programme, d’un matériel, ou bien soudainement, sans qu’aucune action précise ne semble l’avoir déclenché. Parfois exceptionnel, l’écran bleu de la mort qui fait suite à une erreur fatale peut malheureusement s’afficher de façon répétée sur votre machine. Si c’est le cas pour vous actuellement, il vous faudra trouver le pilote responsable de l’erreur fatale et y apporter une solution. Un périphérique, son pilote ou un programme lié à celui-ci peuvent être la cause d’un écran bleu. Dans ce tutoriel, je vais vous montrer comment analyser un écran bleu afin de trouver le pilote responsable de l’erreur fatale et ainsi pouvoir régler définitivement le problème !
Qu’est-ce que le détourage bleu et pourquoi apparaît-il
Quand le système crashe, Windows affiche donc un écran bleu, lequel est accompagné d’un code d’arrêt. Cependant, ce code d’arrêt peut se révéler assez avare en informations. Dans la capture ci-dessus, le code d’arrêt MEMORY_MANAGEMENT indique qu’une erreur grave de gestion de la mémoire est survenue… sans qu’on en sache beaucoup plus. Le détourage bleu est utilisé ici comme métaphore pour isoler le pilote ou le composant problématique et en comprendre l’origine.
Observations et éléments utiles pour l’analyse
Jusqu’à Windows 7, l’écran bleu affichait quatre paramètres liés au code d’arrêt, qui étaient associés au code d’arrêt (il est possible de retrouver ces quatre paramètres dans l’Observateur d’événements). Dans l’exemple ci-dessous, le premier paramètre du code d’arrêt UNMOUNTABLE_BOOT_VOLUME indique le périphérique qui n’a pas réussi à être monté par le système. Lorsqu’il est disponible, le nom du pilote qui a planté est également affiché, comme RTKVHD64.sys dans l’exemple ci-dessous. Après le plantage du système, Windows procède à un vidage de la mémoire physique (RAM) de l’ordinateur, en déchargeant son contenu dans un fichier du disque dur : le fichier d’image mémoire (ou Memory Dump File).
Ce fichier d’image mémoire contient une copie de toutes les données présentes dans la mémoire de l’ordinateur avant le plantage et peut se révéler précieux pour établir un diagnostic complet sur le crash. Sur un PC Windows, le processeur a deux modes différents : un mode utilisateur et un mode noyau. Le processeur bascule entre les deux modes en fonction du type de code qu’il exécute : les applications s’exécutent en mode utilisateur, les composants du système d’exploitation en mode noyau. Pour régler les problèmes d’écran bleu, il faut analyser les fichiers d’image mémoire du mode noyau.
Types de fichiers mémoire et leur rôle
Image mémoire complète: contient toute la mémoire physique utilisée par Windows au moment du crash et nécessite un fichier d’échange important. Image mémoire du noyau: contient uniquement la mémoire du noyau et est plus petite. Image mémoire partielle (256 Ko): fichier mémoire minimal pour systèmes à espace disque limité. Vidage mémoire automatique: contient les mêmes informations que le fichier mémoire du noyau. Le PageFile.sys est l’espace d’échange utilisé lorsque la RAM est saturée.
Dans le panneau supérieur, BlueScreenView affiche tous les fichiers mémoire trouvés dans %SystemRoot%\Minidump et Memory.dmp; dans le panneau inférieur, il montre les pilotes chargés au moment du crash. Si le fichier indique ntoskrnl.exe comme « Caused By Driver », il faut analyser le fichier d’image mémoire complète (ou du noyau) pour trouver le pilote réellement responsable.
Outils et démarche pratique pour identifier le pilote fautif
Lancez le SDK de Windows et installez uniquement les outils de débogage. Après l’installation, WinDbg offre un débogage pour le noyau Windows, les pilotes en mode noyau, les services système, ainsi que les applications et pilotes en mode utilisateur. Pour faciliter la lecture des fichiers mémoire (.dmg), associez-les à WinDbg et précisez le chemin des symboles de débogage via File > Symbol File Path. Sauvegardez l’espace de travail via File > Save Workspace. Attendez que WinDbg charge les symboles nécessaires au débogage du fichier d’image mémoire. Faites remonter la ligne IMAGE_NAME pour repérer les composants en cause.
Si vous ne savez pas à quoi se réfère un élément, lancez une recherche sur le web pour obtenir plus d’informations sur ledit pilote. Si le pilote est un pilote de programme (par exemple un logiciel tiers), désinstallez temporairement ce programme. Si le pilote est un pilote de périphérique, procédez à une désinstallation temporaire ou à une réinstallation propre après redémarrage. Le succès passe par l’identification du pilote exact et la remise en état du système.
Procédures concrètes après le crash
Les étapes suivantes permettent de retrouver une empreinte stable du système après un BSOD et d’éviter les répétitions: prenez une photo du code d’arrêt et des informations affichées, utilisez les fichiers minidump et Memory.dmp pour l’analyse, et visez une restauration ou une mise à jour des pilotes problématiques.
- Mettre à jour les pilotes et le système Windows, puis tester le comportement du PC.
- Ouvrir le Gestionnaire de périphériques et vérifier les périphériques avec un point d’exclamation; examiner le journal des événements pour plus de détails.
- Exécuter l’outil Diagnostic de mémoire Windows pour tester la RAM et consulter les résultats dans l’Observateur d’événements.
- Installer un antivirus et lancer une analyse complète pour exclure une contamination qui peut corrompre des fichiers système.
- Vérifier l’espace libre sur le lecteur système nécessaire pour les fichiers d’échange et le bon fonctionnement du système.
Si la cause persiste, il faut envisager des mesures plus avancées: entrer en Safe Mode, restaurer le système via un point de restauration, ou même effectuer une réinstallation de Windows en dernier recours. Dans les cas où d’autres mesures échouent, la réinstallation peut s’avérer nécessaire pour restaurer un fonctionnement stable.
Windows 10/11 bloqué sur la boucle de diagnostic de votre PC
Rôles spécifiques des éléments à vérifier
Les codes d’arrêt courants peuvent indiquer des problèmes précis: CRITICAL_PROCESS_DIED, IRQL_NOT_LESS_OR_EQUAL, VIDEO_TDR_TIMEOUT_DETECTED, PAGE_FAULT_IN_NONPAGED_AREA, DPC_WATCHDOG_VIOLATION, NTFS_FILE_SYSTEM, DATA_BUS_ERROR, et d’autres. Ces codes guident vers des pilotes obsolètes, des problèmes matériels ou des fichiers système corrompus. L’approche consiste à diagnostiquer, restaurer ou remplacer les composants défaillants, puis tester étape par étape.
Vérifications rapides recommandées
- Vérifier le BIOS/UEFI et activer le mode de gestion VMD ou le désactiver si nécessaire, selon le modèle.
- Mettre à jour BIOS, Windows et pilotes; en cas de persistance, revenir à une version antérieure si possible.
- Tester les périphériques externes et retirer ceux non indispensables temporairement pour évaluer l’impact.
- Utiliser WinDbg et les outils de débogage pour isoler le pilote fautif et le remplacer ou le mettre à jour.
Les conseils ci-dessus permettent de diagnostiquer et de résoudre la plupart des BSOD en identifiant le pilote ou le composant fautif et en appliquant les correctifs adéquats. Si aucun problème matériel n’est détecté après le diagnostic, la réinstallation de Windows peut être envisagée, mais elle doit être effectuée en dernier recours.