Introduction à la collecte des dumps de crash Windows - WER/ProcDump/WinDbg

Quand une application Windows se met à planter « seulement de temps en temps », il y a pas mal de situations où les journaux seuls ne suffisent pas à remonter à la cause.

Les cas particulièrement pénibles ressemblent à ceci.

• Cela ne se produit que dans l’environnement du client
• On dispose du message d’exception, mais pas assez de contexte sur l’appelant
• Cela implique non seulement la partie managée de C# / .NET, mais aussi COM, P/Invoke, des DLL natives et des SDK tiers
• Cela ne plante qu’après un fonctionnement de longue durée

C’est dans ce genre de situation que le dump de crash est efficace. En enregistrant dans un fichier l’état du processus au moment du crash, on peut ensuite relire le code d’exception, la pile du thread qui a planté, les modules chargés, ainsi qu’une partie ou la totalité de la mémoire.

Sous Windows, il est plus simple de raisonner dans cet ordre : commencer par les LocalDumps de WER, ajouter Sysinternals ProcDump si nécessaire, puis recourir à MiniDumpWriteDump seulement lorsqu’on veut encore plus de contrôle. Cet article passe en revue les premiers pas de la collecte de dumps de crash, en se plaçant du point de vue des applications de bureau Windows, des applications résidentes, des services Windows et des outils d’intégration avec des équipements.

1. Les conclusions d’abord

Voici d’abord les points essentiels à retenir.

• Le choix le plus sûr est de configurer WER LocalDumps par application. Sans outil supplémentaire, on obtient un dump conservé en local après un crash.
• Pour les investigations sur le terrain à faible taux de reproduction, ou pour observer aussi les first chance exceptions / hangs, on utilise ProcDump.
• La collecte maison est à envisager en dernier recours — c’est à peu près le bon dosage. Il suffit d’étudier MiniDumpWriteDump une fois qu’on en a réellement besoin.
• Conserver les PDB et les binaires distribués est tout aussi important que les dumps eux-mêmes. Un dump seul, sans symboles, réduit considérablement ce que l’on peut lire.
• Le dump complet est puissant, mais sa taille et le risque d’y voir apparaître des informations confidentielles le sont tout autant. Décidez à l’avance l’emplacement de stockage, le nombre conservé, les droits d’accès et la procédure de partage.

Au stade initial, la configuration recommandée se résume à peu près à ceci.

En résumé : WER d’abord, ProcDump ensuite, la collecte maison en dernier. Commencer dans l’ordre inverse alourdit presque toujours la conception.

2. Ce qu’un dump de crash révèle

Un dump de crash est un « instantané de ce moment précis ». Ce n’est pas tant une caméra de surveillance qu’une photo figée de la scène de l’accident.

Ce type d’information est donc assez facile à obtenir.

• Le code d’exception à l’origine du crash
• Le thread qui a planté
• La pile d’appels à cet instant
• Les modules chargés
• Selon la quantité de mémoire incluse, l’état du tas et le contenu des objets

En revanche, certaines choses manquent souvent quand on n’a que le dump.

• La chronologie qui mène jusqu’au crash
• Une tendance qui se développe depuis plusieurs heures
• L’état externe des communications ou des équipements
• Les saisies récentes et le contexte métier

C’est pourquoi, en pratique, la règle de base est de ne pas chercher à tout résoudre avec le seul dump, mais de le combiner avec des journaux et des heartbeats.

3. Panorama des méthodes de collecte

Pour la collecte de dumps d’applications Windows, voici les quatre méthodes à connaître au stade initial.

Pour un débutant, l’essentiel est de décider « dans quelles conditions », « vers où » et « à quelle taille » collecter, avant même de décider « avec quel outil ».

4. WER LocalDumps, la première recommandation

4.1 Les valeurs du registre à examiner en premier

Windows Error Reporting (WER) dispose de LocalDumps, qui enregistre en local les dumps en mode utilisateur après un crash. Comme il n’y a aucun outil supplémentaire à distribuer, c’est une première étape particulièrement facile à mettre en œuvre.

Voici la clé de base.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

On peut y placer une configuration globale, mais en pratique il est plus facile à gérer de privilégier des sous-clés par application.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

Il y a trois valeurs à examiner en premier.

4.2 Exemple de configuration par application

Par exemple, pour conserver jusqu’à 10 dumps complets de MyApp.exe dans C:\CrashDumps\MyApp, on peut commencer par la configuration suivante.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

Cet exemple comporte quatre points clés.

• Il est limité à MyApp.exe, et non global
• La destination est isolée dans un dossier dédié
• Il démarre avec un dump complet
• Le nombre conservé est plafonné à 10

4.3 Vérifier que la capture fonctionne

Une fois la configuration en place, il est plus sûr de la valider au moins une fois en environnement de test plutôt que d’attendre qu’un crash survienne naturellement en production.

Voici les quatre points à vérifier.

1. Un fichier .dmp apparaît-il dans le dossier prévu ?
2. La taille correspond-elle aux attentes opérationnelles ?
3. Peut-on l’ouvrir avec WinDbg ?
4. Le crash est-il visible dans le journal Application de l’Observateur d’événements ?

5. Quand utiliser ProcDump

WER suffit souvent, mais il existe des situations où ProcDump est utile.

• On veut éviter une configuration permanente dans le registre
• On veut surveiller uniquement un processus déjà démarré
• On veut ne surveiller qu’à partir du prochain démarrage
• On veut observer les first chance exceptions
• On veut capturer un hang
• On veut capturer selon des compteurs de performance ou d’autres conditions

5.1 Options fréquemment utilisées

En se limitant à ce qu’on utilise réellement au stade initial, retenir les options suivantes de ProcDump permet déjà de couvrir beaucoup de cas.

5.2 Exemples de commandes représentatives

Dump complet d’un processus déjà démarré, sur exception non gérée

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

Attendre le prochain démarrage, puis dump complet sur exception non gérée

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

Démarrer soi-même le processus et le surveiller directement

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

Capturer aussi les first chance exceptions

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

Capturer un hang

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3 Pourquoi -i ne doit pas être le premier réflexe

ProcDump permet aussi de s’enregistrer comme débogueur post-mortem avec -i. C’est puissant, mais cela modifie le comportement de la machine entière au moment d’un crash, ce qui en fait un choix un peu lourd comme tout premier pas au stade initial.

Il est donc plus facile de commencer par la configuration WER par application, ou par ProcDump avec -w / -x / un PID ciblé.

6. Comment aborder la collecte maison avec MiniDumpWriteDump

La collecte maison est adaptée, par exemple, dans les situations suivantes.

• On veut proposer un bouton « Enregistrer les informations de diagnostic » dans l’interface
• On veut regrouper journaux, paramètres et identifiants de trace avec le dump
• On veut inclure aussi les processus enfants ou auxiliaires liés
• On veut appliquer son propre masquage ou sa propre compression avant l’envoi

L’API centrale ici est MiniDumpWriteDump.

Cela dit, elle a quelques particularités. Au stade initial, les deux points à ne surtout pas manquer sont les suivants.

1. Si possible, l’appeler depuis un processus distinct de celui qu’on dumpe
2. Traiter les API de la famille DbgHelp comme single-threaded

7. Choisir entre minidump, dump complet et taille intermédiaire

Beaucoup de gens hésitent sur ce point. Voici, sous forme de tableau, comment faire ce choix en pratique.

La recommandation pour les débutants est assez simple.

• Dump complet sur les machines de développement / test
• En environnement client, choisir mini ou complet selon les conditions d’exploitation
• En cas de doute sur une corruption mémoire, une DLL native, COM, P/Invoke ou une anomalie d’état après un fonctionnement de longue durée, privilégier le complet

8. Ce qu’il faut décider à l’avance côté exploitation

La collecte de dumps échoue bien plus souvent à cause de l’exploitation que de l’implémentation. Voici ce qu’il vaut mieux décider à l’avance.

8.1 Comment conserver les PDB et les binaires

C’est le point le plus important de tous.

• La version exacte de l’EXE / DLL distribué
• Les PDB correspondant à cette version
• Le commit et le pipeline de build qui l’ont produite
• Les informations de version de l’installeur et des artefacts distribués

8.2 Où écrire les dumps, et combien en conserver

Les dumps complets deviennent assez volumineux. Il est plus sûr de définir dès le départ la destination et la politique de conservation.

• Ne pas les laisser directement à la racine du disque système
• Les isoler dans un dossier dédié
• Plafonner le nombre avec DumpCount ou -n
• Séparer le stockage à long terme du stockage initial

8.3 Qui est autorisé à les consulter

Un dump complet peut contenir des informations confidentielles ou personnelles.

• Des configurations en clair
• Des chaînes de connexion
• Des jetons et des identifiants
• Des données métier traitées juste avant le crash
• Des chemins de fichiers et des noms d’utilisateur

Il faut donc, en même temps que l’on conçoit « comment collecter », décider aussi « qui a le droit d’y accéder ».

9. Le chemin le plus court vers l’analyse une fois le dump obtenu

Une fois le dump capturé, les premières étapes sont étonnamment simples.

9.1 Installer WinDbg

La version actuelle de WinDbg s’installe facilement depuis le Microsoft Store ou via winget.

winget install Microsoft.WinDbg

9.2 Ouvrir le dump

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

9.3 Configurer les symboles

Commencez par rendre disponibles les symboles publics de Microsoft, puis ajoutez l’emplacement de vos propres PDB.

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

9.4 Commencer par l’analyse automatique

!analyze -v

Ensuite, examinez dans l’ordre :

• Le code d’exception en cause
• Quel est le module fautif (faulting module)
• Jusqu’où son propre code est visible dans la pile
• S’il existe des attentes ou blocages suspects sur d’autres threads que celui de l’exception

10. Pièges fréquents

10.1 Le dump est là, mais pas les PDB

C’est extrêmement fréquent. La collecte du dump a beau avoir réussi, il manque la matière pour le lire. Mieux vaut mettre en place la conservation des PDB en même temps que la configuration de la collecte.

10.2 Ne pas vérifier les ACL de DumpFolder

Avec les services ou les processus à privilèges séparés, c’est un piège facile à rencontrer. Vérifiez d’abord que le processus peut réellement écrire à cet endroit.

10.3 Continuer à écrire des dumps complets sur le disque système d’une machine de production

C’est le grand classique de l’incident d’espace disque. Mettez en place dès le départ la limitation du nombre conservé et l’isolation de la destination.

10.4 Vouloir tout couvrir, y compris les hangs, avec WER seul

WER LocalDumps est avant tout efficace pour les crashs. Pour les hangs et les first chance exceptions, il y a des cas où ProcDump est mieux adapté.

10.5 Laisser -e 1 activé en permanence et se retrouver noyé sous les exceptions

Les first chance exceptions sont utiles, mais elles sont simplement très nombreuses. De façon réaliste : fixez une limite de nombre, activez-les seulement sur de courtes périodes, et limitez la cible.

11. Conclusion

Le dump de crash est un point d’observation particulièrement puissant face aux défaillances à faible taux de reproduction. C’est d’autant plus vrai lorsqu’une application Windows implique COM, P/Invoke, des DLL natives ou un fonctionnement de longue durée : il vaut la peine de décider dès le départ « ce qui restera en cas de crash ».

L’ordre recommandé est simple.

1. Mettre d’abord en place WER LocalDumps par application
2. Ajouter ProcDump si nécessaire
3. Si l’on veut encore plus de contrôle, utiliser MiniDumpWriteDump depuis un processus séparé

En procédant dans cet ordre, il est difficile de se tromper lourdement.

12. Références

• [Collecting User-Mode Dumps - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps)

• [ProcDump v11.1 - Sysinternals

  Microsoft Learn](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump)

• [MiniDumpWriteDump function (minidumpapiset.h) - Win32

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/nf-minidumpapiset-minidumpwritedump)

• [User-mode dump files - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/user-mode-dump-files)

• [Analyzing a User-Mode Dump File - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/analyzing-a-user-mode-dump-file)

• [Install the Windows debugger - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/)

• [Symbol path for Windows debuggers - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path)

• [!analyze (WinDbg) - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-analyze)

• [Troubleshoot processes by using Task Manager - Windows Server

  Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-server/support-tools/support-tools-task-manager)

• [Enabling Postmortem Debugging - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-postmortem-debugging)

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce qu'un dump de crash, et que peut-on y voir ?

C'est l'état du processus au moment du crash, enregistré dans un fichier : une sorte de photo figée de la scène de l'accident. On peut y retrouver a posteriori le code d'exception, le thread qui a planté et sa pile d'appels, les modules chargés, et, selon la quantité de mémoire incluse, jusqu'au contenu des objets sur le tas. En revanche, la chronologie qui mène jusqu'au crash ou l'état externe des communications et des équipements manque souvent, c'est pourquoi, en pratique, on combine systématiquement le dump avec des journaux et des heartbeats.

Où configure-t-on les LocalDumps de WER ?

Cela se configure dans le registre, sous HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. En pratique, il est plus facile à gérer de privilégier une sous-clé par application, comme MyApp.exe, plutôt qu'une configuration globale. Les trois valeurs à examiner en premier sont DumpFolder pour la destination, DumpCount pour le nombre de dumps conservés, et DumpType pour le type : cela permet de laisser un dump après un crash, en local, sans distribuer d'outil supplémentaire.

Faut-il choisir un minidump ou un dump complet ?

En règle générale, on utilise un dump complet (DumpType=2) sur les machines de développement et de test, et on choisit un minidump (DumpType=1) ou un dump complet en environnement client selon l'espace disque et les exigences de confidentialité. Si l'on suspecte une corruption mémoire, une DLL native, COM, P/Invoke ou une anomalie d'état après un fonctionnement de longue durée, mieux vaut privilégier le dump complet. Cependant, un dump complet est volumineux et peut contenir des informations sensibles comme des chaînes de connexion ou des jetons, il faut donc décider à l'avance de l'emplacement de stockage, du nombre de dumps conservés et des droits d'accès.

Dans quels cas utilise-t-on ProcDump ?

Comme WER LocalDumps est fondamentalement orienté crash, ProcDump est adapté lorsqu'on veut aussi observer les hangs ou les first chance exceptions, éviter une configuration permanente dans le registre, ou surveiller uniquement un processus déjà démarré. Les options les plus courantes sont -ma pour un dump complet, -e pour la capture sur exception non gérée, -h pour la détection de hang, ou encore -w pour attendre le démarrage. Comme -e 1, qui cible les first chance exceptions, tend à générer un grand nombre de dumps, il est plus réaliste de fixer une limite avec -n et de l'utiliser sur une durée courte et ciblée.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.