Après un écran bleu, Windows écrit un petit fichier de vidage mémoire dans C:\Windows\Minidump. Ce fichier de quelques centaines de kilo-octets contient le code d’arrêt et, le plus souvent, le nom du pilote qui a fait tomber le système.
L’ouvrir demande un outil, pas un devin. Le débogueur officiel de Microsoft se télécharge gratuitement, et une seule commande suffit pour obtenir un verdict lisible.
Points clés
- Les minidumps sont stockés dans %SystemRoot%\Minidump, un fichier par plantage, nommé par date.
- Le petit vidage mémoire est le format par défaut sur Windows 11 pour les postes clients ; il pèse quelques centaines de kilo-octets.
- L’analyse repose sur WinDbg et sur la commande
!analyze -v. - Sans serveur de symboles configuré, l’analyse rend des noms de fonctions inexploitables.
- Le champ à lire en priorité est MODULE_NAME ou IMAGE_NAME : c’est le composant mis en cause.
Ce qu’est réellement un minidump
Quand le noyau rencontre une erreur fatale, il arrête le système et écrit un instantané de son état avant de rendre la main. Microsoft distingue plusieurs formats de vidage : petit vidage mémoire (le minidump), vidage mémoire du noyau, vidage mémoire complet, vidage automatique et vidage actif.
Le minidump ne contient pas la mémoire des applications. Il embarque le code d’arrêt et ses paramètres, la liste des pilotes chargés, le contexte du processeur et la pile d’appels du thread fautif. C’est peu, et c’est suffisant dans la majorité des cas : le nom du pilote responsable s’y trouve.
Un point pratique : les minidumps s’accumulent, un fichier par incident, ce qui permet de comparer plusieurs plantages. Si trois vidages différents désignent le même module, le doute n’est plus permis.
Vérifier que Windows écrit bien les vidages
Si le dossier Minidump est vide après un écran bleu, la configuration est en cause. Ouvrez sysdm.cpl, onglet Paramètres système avancés, section Démarrage et récupération, puis Paramètres.
- Le menu « Écriture des informations de débogage » doit être sur Petit vidage mémoire ou sur Vidage mémoire automatique.
- Le chemin doit rester
%SystemRoot%\Minidump. - Le fichier d’échange doit être géré par le système sur le disque contenant Windows : c’est lui qui sert de tampon d’écriture au moment du plantage.
Deux causes fréquentes de dossier vide : un fichier d’échange désactivé par un utilitaire d’optimisation, et un utilitaire de nettoyage qui supprime les vidages à chaque passage.
Installer le débogueur Microsoft
WinDbg fait partie des outils de débogage pour Windows, distribués par Microsoft dans le SDK Windows. L’installateur du SDK permet de ne cocher que le composant Debugging Tools for Windows, sans installer l’ensemble de l’environnement de développement.
La version moderne se trouve aussi dans le Microsoft Store sous le nom WinDbg. Les deux ouvrent les mêmes fichiers et acceptent les mêmes commandes ; la version Store gère seule ses mises à jour.
Configurer les symboles, l’étape que personne ne doit sauter
Sans symboles, le débogueur affiche des adresses mémoire brutes au lieu des noms de fonctions, et !analyze rend un résultat inutilisable. Microsoft publie un serveur de symboles public pour cela.
Dans WinDbg, menu File puis Settings, renseignez le chemin de symboles :
srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
La première analyse télécharge alors plusieurs dizaines de mégaoctets et prend quelques minutes. Les suivantes réutilisent le cache local et démarrent immédiatement. Une connexion est nécessaire lors du premier passage.
Analyser le fichier en trois commandes
Ouvrez le fichier .dmp par File puis Open dump file, puis attendez la fin du chargement des symboles. Trois commandes couvrent l’essentiel :
!analyze -vlance l’analyse détaillée et produit le rapport principal.lm t nliste les modules chargés avec leur date, utile pour repérer un pilote ancien.!threadaffiche le contexte du thread fautif quand le rapport reste ambigu.
Dans la sortie de !analyze -v, quatre champs comptent vraiment :
- BUGCHECK_CODE : le code d’arrêt, celui affiché sur l’écran bleu.
- MODULE_NAME et IMAGE_NAME : le composant désigné comme responsable.
- PROCESS_NAME : le processus actif au moment du plantage, souvent
Systemsur une erreur de pilote. - FAILURE_BUCKET_ID : une signature de l’incident, utile pour comparer plusieurs vidages entre eux.
Interpréter le nom du module sans se tromper
Le piège classique est de prendre le module désigné pour le coupable dans tous les cas. Deux noms reviennent sans rien vouloir dire de précis :
ntoskrnl.exeest le noyau lui-même. Il apparaît quand le noyau a détecté l’erreur sans pouvoir remonter au responsable. Le vrai suspect est alors ailleurs, généralement dans la pile d’appels affichée plus bas.hal.dll, la couche d’abstraction matérielle, pointe presque toujours vers un problème matériel ou de pilote de bas niveau, rarement vers un fichier à remplacer.
Les noms exploitables sont ceux d’un pilote tiers identifiable : nvlddmkm.sys pour NVIDIA, amdkmdag.sys pour AMD, rt640x64.sys pour une carte réseau Realtek, ou un fichier portant le nom d’un éditeur d’antivirus ou d’un utilitaire.
Le code d’arrêt oriente la lecture. La référence complète des codes est publiée par Microsoft, et les codes les plus courants sont traités un par un dans le guide des écrans bleus Windows. Trois exemples de lecture croisée :
- SYSTEM_PTE_MISUSE : le vidage désigne souvent un pilote qui manipule mal les entrées de table de pages.
- FAULTY_HARDWARE_CORRUPTED_PAGE : le rapport pointe le noyau alors que la mémoire physique est en cause.
- APC_INDEX_MISMATCH : un déséquilibre entre appels, typiquement lié à un pilote graphique ou à un filtre système.
Quand le vidage ne suffit pas
Le minidump a une limite : il ne conserve pas la mémoire des processus utilisateur. Trois situations demandent d’aller plus loin.
- Le rapport désigne systématiquement le noyau. Basculez sur un vidage mémoire du noyau ou complet dans les mêmes réglages, puis attendez le plantage suivant. Le fichier fait alors plusieurs gigaoctets.
- Le module change à chaque plantage. C’est la signature d’une mémoire vive défectueuse. Passez le diagnostic de mémoire Windows, puis un test approfondi sur plusieurs passes.
- Aucun pilote tiers n’est identifiable. Le vérificateur de pilotes de Microsoft force les pilotes suspects à révéler leurs erreurs, au prix de plantages provoqués. Il s’active sur une machine de test, jamais sur un poste de production, et se désactive avec
verifier /reset.
Si le plantage survient avant même le chargement du bureau, l’analyse du vidage n’est pas la première étape : voir écran bleu au démarrage de Windows, où l’accès au fichier lui-même demande d’abord de récupérer le disque.
Questions fréquentes
Où sont exactement les fichiers minidump ?
Dans C:\Windows\Minidump, sauf chemin modifié. Chaque fichier porte une date dans son nom, ce qui permet de retrouver celui du dernier écran bleu. L’accès au dossier demande des droits administrateur.
Peut-on analyser un minidump sans installer WinDbg ?
Des utilitaires tiers lisent l’en-tête du fichier et affichent le code d’arrêt et le module. Ils suffisent pour un premier tri, mais ils n’exécutent pas !analyze -v et ne remontent pas la pile d’appels. Pour un diagnostic sérieux, l’outil Microsoft reste nécessaire.
Combien de temps garder les vidages ?
Gardez au moins les trois derniers. Comparer plusieurs vidages est la meilleure façon de distinguer un incident isolé d’un pilote réellement défectueux. Une fois la cause corrigée et le système stable pendant une à deux semaines, le dossier peut être vidé.
Le fichier fait 0 kilo-octet, que faire ?
Un vidage tronqué signale une écriture interrompue : disque plein, fichier d’échange trop petit, ou coupure d’alimentation pendant l’écriture. Libérez de l’espace sur le disque système, laissez la gestion du fichier d’échange à Windows, et attendez l’incident suivant.
Faut-il envoyer le vidage au support du constructeur ?
Oui quand le module désigné appartient à un pilote fourni par le fabricant de la machine ou d’un composant. Le fichier est petit, il s’envoie facilement, et il contient exactement ce dont un support technique a besoin pour trancher entre pilote et matériel.
Photo d’en-tête : barrettes de mémoire vive installées sur une carte mère, domaine public, via Wikimedia Commons. La photo illustre le matériel le plus souvent mis en cause par les vidages, pas l’outil d’analyse lui-même.
Sources : Microsoft Learn, options de fichier de vidage mémoire · Microsoft Learn, Minidump Files · Microsoft Learn, télécharger les outils de débogage · Microsoft Learn, commande !analyze · Microsoft Learn, chemin de symboles · Microsoft Learn, référence des codes d’arrêt · Microsoft Learn, vérificateur de pilotes · Microsoft Learn, générer un vidage noyau ou complet.
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
