Fichier dmp : lire le rapport d’un écran bleu sans être développeur

Un vidage mémoire complet réclame un fichier d’échange au moins égal à la mémoire vive installée, plus 1 Mo. Sur une machine à 32 Go de RAM, cela donne un fichier unique de plusieurs dizaines de gigaoctets posé dans C:\Windows.

Le fichier dmp du même plantage, version miniature, tient dans quelques centaines de kilo-octets et raconte presque la même histoire. Tout se joue dans cet écart : savoir lequel ouvrir, lequel garder, lequel effacer.

Ce qu’il faut avoir sous la main avant de commencer

Trois choses suffisent, et aucune ne coûte un centime.

• Un compte administrateur sur la machine. Sans ça, le dossier des dumps reste fermé.
• Le code d’arrêt, s’il a été noté au moment du plantage. Depuis l’été 2025, l’écran d’erreur de Windows 11 n’est plus bleu mais noir, sans QR code ni frimousse, et il affiche directement le code d’arrêt ainsi que le pilote incriminé quand Windows a réussi à l’identifier. Le dump sert alors à confirmer, pas à découvrir.
• Un lecteur de dumps : WhoCrashed en édition Home, gratuite, ou BlueScreenView, portable. Le Windows Debugger et ses symboles de débogage ne servent à rien ici.

Comptez dix minutes en tout, redémarrage compris. Et un avertissement utile avant de télécharger : BlueScreenView est un outil NirSoft, et les outils NirSoft sont régulièrement classés « PUA » ou « RiskTool » par les antivirus. C’est un faux positif connu, pas une infection, mais il fait abandonner beaucoup de monde à la première alerte.

Étape 1 : retrouver les fichiers dmp là où Windows les range

Deux endroits, deux logiques différentes.

Le dossier C:\Windows\Minidump contient un fichier par plantage, nommé selon la date et un numéro de séquence, du type 120919-47718-01.dmp. Windows en conserve l’historique : chaque nouvel écran bleu ajoute un fichier sans effacer les précédents. C’est là que se lit une série.

Le fichier C:\Windows\MEMORY.DMP est unique et se fait écraser à chaque plantage. Il ne garde donc que le dernier. Raccourci pour y aller : touche Windows + R, puis %SystemRoot%\Minidump.

Une précision qui change la lecture du poids affiché. Le réglage par défaut de Windows n’est pas le vidage complet mais le vidage mémoire automatique, qui écrit en réalité un vidage du noyau.

Le MEMORY.DMP posé sur un disque ordinaire pèse donc souvent quelques centaines de mégaoctets à deux gigaoctets, pas la totalité de la RAM. Les dizaines de gigaoctets n’arrivent que si le réglage a été basculé exprès sur vidage complet.

Le dossier Minidump est vide, et pourtant ça a bien planté

Le cas est fréquent, et il a quatre explications qui se testent dans cet ordre.

1. L’écriture des dumps est désactivée. Le réglage vit dans Panneau de configuration, Système et sécurité, Système, Paramètres système avancés, onglet Avancé, zone « Démarrage et récupération ». Si la liste « Écriture des informations de débogage » affiche « (aucun) », aucun fichier ne sera jamais créé. Le détail des types de vidage et de leurs contraintes figure dans la documentation Microsoft sur les options d’échec et de récupération.
2. Le fichier d’échange est trop petit ou mal placé. Un petit vidage réclame au minimum 2 Mo de fichier de pagination, un vidage du noyau demande la taille de la RAM plus 128 Mo sur un système 64 bits. Surtout, ce fichier doit se trouver sur le volume de démarrage : déplacé sur un autre disque pour gagner de la place, il rend l’écriture du dump impossible.
3. Quelque chose efface les fichiers. Les utilitaires de nettoyage tiers vident ce dossier sans le dire, et Windows lui-même supprime les vidages quand l’espace disque devient critique.
4. Le plantage a été trop brutal. Un écran d’erreur qui annonce la préparation du fichier de vidage puis se fige à 0 % ne produit rien du tout. Ce symptôme oriente vers la mémoire ou l’alimentation, pas vers un pilote.

Pour vérifier la configuration sans naviguer dans les menus, une ligne dans un PowerShell administrateur : Get-CimInstance Win32_OSRecoveryConfiguration. Les guides qui proposent encore wmic recoveros sont périmés, car WMIC est désactivé par défaut depuis Windows 11 23H2 et ne fait plus partie de l’installation standard en 24H2.

Étape 2 : sortir le nom du pilote en une minute

WhoCrashed s’installe, se lance, et un bouton d’analyse produit un rapport en clair : date et heure du plantage, chemin du fichier dmp lu, module suspecté, éditeur du module, code d’arrêt et sa traduction en français courant. Aucune compétence de débogage n’est demandée. La version actuelle est la 7.10, et l’outil est toujours entretenu par son éditeur.

BlueScreenView fonctionne autrement : pas d’installation, on décompresse et on lance. Il ouvre tout seul le dossier de minidumps déclaré dans le registre et affiche un tableau, une ligne par plantage, avec une colonne qui désigne le pilote responsable. En dessous, les pilotes chargés au moment du crash, ceux qui figuraient dans la pile étant surlignés.

Deux réserves à connaître avant de choisir. La première : BlueScreenView n’a plus été mis à jour depuis 2015 et sa liste de compatibilité officielle s’arrête à Windows 10. Il fonctionne toujours, mais l’éditeur signale lui-même que certains minidumps modernes sortent vides et ne s’affichent pas. Une fenêtre vide ne prouve donc rien.

La seconde tient à la formulation des rapports. Quand WhoCrashed conclut par « aucun pilote tiers fautif n’a été trouvé », ce n’est pas un échec de l’outil. C’est une information, et souvent la plus importante de tout le rapport.

Étape 3 : ce pilote est-il le coupable ou juste le témoin ?

Voilà où la plupart des dépannages déraillent. Le module nommé dans un dump est celui qui exécutait du code à l’instant de l’arrêt, ce qui n’est pas du tout la même chose que celui qui a provoqué la panne.

Trois cas de figure se présentent, et ils ne se traitent pas pareil.

• Le module désigné est ntoskrnl.exe ou ntkrnlmp.exe. C’est le noyau de Windows. Il n’est jamais la cause : il est simplement ce qui tournait quand tout s’est arrêté. Un rapport qui pointe le noyau avec un code 0x1A MEMORY_MANAGEMENT désigne en pratique une corruption mémoire, dont l’origine peut être une barrette défaillante, une surchauffe ou un pilote mal écrit.
• Le module désigné est un pilote tiers, un pilote graphique par exemple. Piste sérieuse, à une condition : que le même nom revienne sur plusieurs dumps successifs. Un pilote graphique planté par une mémoire vive défaillante apparaît accusé à tort, et le réinstaller ne change rien.
• Le module change à chaque plantage. Trois écrans bleus, trois modules différents : ce n’est pas un problème de pilote. C’est du matériel, ou de l’alimentation.

Le code d’arrêt pèse souvent plus lourd que le nom du fichier. WHEA_UNCORRECTABLE_ERROR en 0x124 remonte une erreur signalée par le processeur ou le chipset lui-même, et rien dans la liste des pilotes ne la réglera. À l’inverse, SYSTEM_THREAD_EXCEPTION_NOT_HANDLED suivi d’un nom de fichier .sys inhabituel désigne une vraie piste logicielle.

L’habitude à prendre tient en une phrase : lire au moins trois dumps avant de conclure. Un seul plantage ne dit rien, une série parle.

Étape 4 : garder les minidumps, supprimer MEMORY.DMP

Les deux fichiers n’ont pas du tout la même valeur, et c’est une bonne nouvelle pour le disque.

Les minidumps se gardent. Quelques centaines de kilo-octets chacun, dix plantages représentent donc moins de dix mégaoctets, et c’est précisément la matière qui permet de comparer plusieurs crashs. Les effacer au premier écran bleu revient à jeter le seul indice disponible.

Le MEMORY.DMP se supprime sans risque. Aucun composant de Windows n’en dépend, il n’est utile qu’à un débogueur, et il ne concerne de toute façon que le dernier plantage.

La bonne porte se trouve dans Paramètres, Système, Stockage, Fichiers temporaires : cocher « Fichiers de vidage mémoire des erreurs système », décocher le reste si besoin, valider. Même principe que pour les fichiers temporaires et ce qu’on peut supprimer sans rien casser.

Un détail à ne pas découvrir après coup : ce nettoyage ne passe pas par la corbeille, la suppression est définitive. Une suppression manuelle, elle, reste rattrapable, et la méthode pour récupérer un fichier supprimé sous Windows s’applique normalement.

Dernier réflexe avant de nettoyer : copier le dossier Minidump ailleurs si une demande d’aide sur un forum est prévue. Un dump effacé ne se reconstitue pas, contrairement à un fichier de sauvegarde .bak et sa récupération qui existe justement pour ça.

Questions fréquentes

Peut-on ouvrir un fichier dmp avec le Bloc-notes ?

Techniquement oui, utilement non. Le format est binaire : le Bloc-notes affiche une bouillie de caractères dans laquelle surnagent quelques noms de modules lisibles. Ces bribes ne donnent ni le code d’arrêt ni la pile d’appels. Un lecteur dédié fait le travail en une minute, sans risque d’abîmer le fichier.

Combien de temps faut-il garder les minidumps ?

Le temps du diagnostic, pas davantage. Une règle simple fonctionne bien : conserver le dossier tant que la machine n’a pas tenu trois semaines sans plantage, puis vider. Les fichiers étant horodatés dans leur nom, il est facile de ne garder que la période qui pose problème et de supprimer le reste.

Un fichier dmp peut-il contenir des données personnelles ?

Oui, et c’est à prendre au sérieux avant de le poster sur un forum. Un vidage complet copie tout le contenu de la mémoire vive au moment du crash, ce qui peut inclure des documents ouverts, des identifiants ou des jetons de session.

Le minidump est bien plus discret : il se limite à la pile, au processus en cours et à la liste des pilotes chargés. Pour demander de l’aide en ligne, partager un minidump, jamais le MEMORY.DMP.

Quand le dump ne suffit plus et qu’il faut regarder le matériel

Trois signaux disent que le fichier a livré tout ce qu’il avait, et qu’il faut ouvrir la machine plutôt que réinstaller un pilote de plus : un module différent à chaque plantage, un code 0x124, ou aucun dump écrit malgré des écrans bleus répétés.

L’ordre qui fait gagner du temps commence par la mémoire vive, et pas avec un simple test logiciel. Un MemTest86 qui affiche 48 tests passés sur 48 après quatre heures ne blanchit pas la RAM : les défauts intermittents lui échappent régulièrement.

La méthode qui tranche vraiment consiste à retirer les barrettes et à faire tourner la machine avec une seule à la fois, plusieurs jours chacune, en notant les plantages.

Vient ensuite la température, relevée en charge et non au repos, puis l’alimentation, premier suspect quand la machine se fige avant même d’avoir écrit son fichier. Le stockage ferme la marche, avec un contrôle SMART du disque système.

Chaque étape demande de la patience, et c’est justement pour ça que les minidumps valent d’être conservés : à la fin de la semaine, la série de fichiers dira si le remplacement a servi à quelque chose ou si le vrai coupable est encore dans le boîtier.