Introduzione alla raccolta di crash dump Windows - WER/ProcDump/WinDbg

Una volta che un’applicazione Windows inizia a crashare “solo occasionalmente”, ci sono molte situazioni in cui i soli log non bastano per risalire al problema.

I casi davvero dolorosi sono questi.

• Succede solo nell’ambiente del cliente
• Hai il messaggio d’eccezione, ma non abbastanza contesto sul chiamante
• Coinvolge non solo il lato managed di C# / .NET, ma anche COM, P/Invoke, DLL native e SDK di vendor
• Crasha solo dopo lunghe ore di operatività continua

È qui che i crash dump brillano. Se catturi lo stato del processo nel momento del crash in un file, in seguito puoi leggere il codice d’eccezione, lo stack del thread che ha crashato, i moduli caricati e parte o tutta la memoria.

Su Windows, il modo più semplice di pensarci è in questo ordine: inizia con WER LocalDumps, aggiungi Sysinternals ProcDump quando necessario, e ricorri a MiniDumpWriteDump solo quando vuoi un controllo ancora maggiore. In questo articolo illustreremo i primi passi della raccolta di crash dump, assumendo applicazioni Windows desktop, applicazioni residenti, servizi Windows, strumenti di integrazione dispositivi e simili.

1. Le conclusioni prima di tutto

Iniziamo con i punti che vuoi fissare subito.

• La prima mossa sicura è configurare WER LocalDumps per applicazione. Senza strumenti aggiuntivi, ottieni un dump salvato localmente dopo un crash.
• Usa ProcDump per le indagini sul campo con bassa riproducibilità, o quando ti servono anche first chance exception / hang.
• Tratta la raccolta personalizzata come ultima spiaggia — è circa la priorità giusta. Considera MiniDumpWriteDump solo quando effettivamente ne hai bisogno.
• Altrettanto importante dei dump stessi è conservare i PDB e gli eseguibili distribuiti. Un dump da solo, senza simboli, riduce drasticamente ciò che puoi leggere.
• I dump completi sono potenti, ma le dimensioni e il rischio di includere dati riservati sono altrettanto potenti. Decidi in anticipo posizione di archiviazione, conteggio di conservazione, diritti di accesso e procedura di condivisione.

Alla fase introduttiva, la configurazione consigliata di solito si colloca qui.

In breve: prima WER, poi ProcDump, infine raccolta personalizzata. Iniziare nell’ordine inverso e la tua progettazione finirà quasi sempre più pesante del necessario.

2. Cosa ti dice un crash dump

Un crash dump è una “fotografia di quel momento”. È meno come una telecamera di sicurezza e più come una foto ferma della scena di un incidente.

Questo tipo di informazione è abbastanza facile da ottenere.

• Con quale codice di eccezione è avvenuto il crash
• Quale thread ha crashato
• Lo stack di chiamata in quel punto
• I moduli caricati
• A seconda di quanta memoria è inclusa, lo stato dell’heap e il contenuto degli oggetti

D’altra parte, alcune cose tendono a mancare in un dump da solo.

• La cronologia che ha portato al crash
• Un andamento di crescita dalle ore precedenti
• Lo stato esterno che coinvolge comunicazione o dispositivi
• L’input più recente e il contesto aziendale

Quindi in pratica, l’approccio di base è: non cercare di chiudere il caso solo con il dump — combinalo con log e heartbeat.

3. La visione d’insieme dei metodi di raccolta

Per la raccolta di dump su applicazioni Windows, ci sono quattro metodi che vuoi conoscere alla fase introduttiva.

Per i principianti, la cosa più importante è questa: prima di decidere “con quale strumento catturare”, decidere “in quali condizioni”, “dove” e “di che dimensione”.

4. Il primo passo consigliato è WER LocalDumps

4.1 I valori di registro da guardare per primi

Windows Error Reporting (WER) ha LocalDumps, che salva dump in modalità utente localmente dopo un crash. Poiché non devi distribuire strumenti aggiuntivi, è una mossa iniziale molto accessibile.

La chiave base è qui.

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

Puoi mettere una configurazione globale qui, ma in pratica è più facile da gestire con sottochiavi per applicazione.

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

Ci sono tre valori da guardare per primi.

4.2 Esempio di configurazione per applicazione

Ad esempio, se vuoi conservare fino a 10 dump completi per MyApp.exe in C:\CrashDumps\MyApp, puoi partire con quanto segue.

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

Questo esempio ha quattro punti chiave.

• È limitato a MyApp.exe, non globale
• L’output è separato in una cartella dedicata
• Inizia con dump completi
• Il conteggio di conservazione è limitato a 10

4.3 Verificare che un dump sia stato catturato

Una volta messa in piedi la configurazione, è più sicuro effettuare una cattura completa almeno una volta in un ambiente di test piuttosto che aspettare che il crash avvenga naturalmente in produzione.

Ci sono quattro cose da controllare.

1. Appare un file .dmp nella cartella prevista?
2. La dimensione è in linea con le aspettative operative?
3. Si può aprire in WinDbg?
4. Il crash è visibile nel log Applicazione in Event Viewer?

5. Quando usare ProcDump

WER spesso basta, ma ci sono situazioni in cui ProcDump torna utile.

• Vuoi evitare un’impostazione di registro permanente
• Vuoi monitorare solo un processo già in esecuzione
• Vuoi monitorare a partire dal prossimo avvio
• Vuoi vedere le first chance exception
• Vuoi catturare un hang
• Vuoi catturare in base a contatori delle prestazioni o ad altre condizioni

5.1 Opzioni frequentemente usate

Riducendo a ciò che effettivamente usi alla fase introduttiva, conoscere queste opzioni di ProcDump ti fa già andare lontano.

5.2 Esempi di comando rappresentativi

Dump completo di un processo già in esecuzione su eccezione non gestita

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

Attendi il prossimo avvio, poi dump completo su eccezione non gestita

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

Lancia il processo tu stesso e monitoralo direttamente

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

Cattura anche le first chance exception

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

Cattura un hang

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

5.3 Perché -i non dovrebbe essere la prima mossa

ProcDump può anche essere registrato come debugger post-mortem con -i. Questo è potente, ma cambia il comportamento del crash a livello macchina, il che lo rende un po’ pesante come prima mossa alla fase introduttiva.

Quindi è più facile iniziare con configurazione WER per applicazione o con il targeting per processo di ProcDump -w / -x / PID.

6. Come pensare alla raccolta personalizzata con MiniDumpWriteDump

La raccolta personalizzata si adatta bene a situazioni come queste.

• Vuoi un pulsante “Salva informazioni diagnostiche” nell’UI
• Vuoi raggruppare log, impostazioni e trace ID insieme al dump
• Vuoi includere anche processi figlio o helper correlati
• Vuoi applicare la tua mascheratura o compressione prima dell’upload

L’API centrale qui è MiniDumpWriteDump.

Detto questo, ha alcune peculiarità. Alla fase introduttiva, i due punti che soprattutto non vuoi sbagliare sono questi.

1. Se possibile, chiamala da un processo diverso da quello di cui si fa il dump
2. Tratta la famiglia di API DbgHelp come single-threaded

7. Scegliere tra minidump, dump completi e dimensioni intermedie

Molti restano bloccati qui. Ecco come scegliamo noi in pratica, in forma tabellare.

La raccomandazione per i principianti è piuttosto semplice.

• Dump completi su macchine di sviluppo / test
• In ambienti cliente, scegliere mini o completo in base ai vincoli operativi
• Se sospetti corruzione di memoria, DLL native, COM, P/Invoke o anomalie di stato dopo lunga operatività, spostati verso completo

8. Cosa decidere in anticipo operativamente

La raccolta di dump inciampa molto più spesso sulle operazioni che sull’implementazione. Ecco cosa vuoi decidere in anticipo.

8.1 Come conservare i PDB e gli eseguibili

Questa è la cosa più importante.

• La versione esatta dell’EXE / DLL distribuito
• I PDB corrispondenti a quella versione
• Quale commit / quale pipeline di build li ha prodotti
• Informazioni di versione per l’installer e gli artefatti distribuiti

8.2 Dove scrivere i dump, e quanti conservarne

I dump completi diventano piuttosto grandi. È più sicuro decidere in anticipo posizione di output e policy di conservazione.

• Non lasciare dump direttamente sul disco di sistema
• Separarli in una cartella dedicata
• Limita il conteggio con DumpCount o -n
• Separa l’archiviazione a lungo termine dall’intake iniziale

8.3 Chi è autorizzato a guardarci

I dump completi possono contenere informazioni riservate o personali.

• Configurazione in chiaro
• Connection string
• Token e credenziali
• Dati aziendali gestiti poco prima del crash
• Percorsi di file e nomi utente

Quindi insieme al progettare “come catturare”, devi anche decidere “chi è autorizzato a toccare i dump”.

9. Il percorso più breve per l’analisi una volta ottenuto un dump

Dopo aver catturato un dump, i primi passi sono sorprendentemente semplici.

9.1 Installare WinDbg

Il WinDbg di oggi è facile da installare dal Microsoft Store o tramite winget.

winget install Microsoft.WinDbg

9.2 Aprire il dump

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

9.3 Configurare i simboli

Prima fai funzionare i simboli pubblici di Microsoft, poi aggiungi la posizione dei tuoi PDB.

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

9.4 Iniziare con l’analisi automatica

!analyze -v

Da lì, controlla in ordine:

• Quale codice di eccezione è
• Qual è il modulo in fault
• Quanto il tuo codice è visibile sullo stack
• Se ci sono attese o blocchi sospetti su thread diversi da quello dell’eccezione

10. Insidie comuni

10.1 Hai ottenuto il dump, ma non ci sono i PDB

Questo è estremamente comune. La raccolta del dump stesso è riuscita, ma ti manca materiale per leggerlo. Metti in piedi il design di conservazione dei PDB contemporaneamente alla configurazione della raccolta.

10.2 Non controllare l’ACL su DumpFolder

Con servizi o processi con privilegi separati, questo è un punto facile da mancare. Verifica prima che il processo possa effettivamente scriverci.

10.3 Scrivere continuamente dump completi sul disco di sistema di una macchina di produzione

Questo è il classico incidente da spazio su disco. Imposta limiti di conservazione e separazione della cartella di output fin dall’inizio.

10.4 Cercare di coprire gli hang interamente solo con WER

WER LocalDumps è forte soprattutto per i crash. Per hang e first chance exception, ProcDump è spesso la scelta migliore.

10.5 Lasciare -e 1 permanentemente attivo e annegare nelle eccezioni

Le first chance exception sono utili, ma sono semplicemente numerose. Realisticamente: limita il conteggio, abilitalo solo per brevi periodi e limita il target.

11. Riassunto

I crash dump sono un punto di osservazione straordinariamente forte per i fallimenti con bassa riproducibilità. Specialmente quando un’applicazione Windows coinvolge COM, P/Invoke, DLL native o operatività prolungata, vale la pena decidere fin dall’inizio “cosa resterà quando crasha”.

L’ordine consigliato è semplice.

1. Per prima cosa, configura WER LocalDumps per applicazione
2. Aggiungi ProcDump se necessario
3. Se vuoi un controllo ancora maggiore, usa MiniDumpWriteDump da un processo separato

Procedi in questo ordine e difficilmente sbaglierai di molto.

12. Riferimenti

• [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)

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Qual è il modo più semplice per iniziare a raccogliere crash dump su Windows?

Configurare WER LocalDumps per applicazione tramite il registro. Sotto la chiave LocalDumps si crea una sottochiave con il nome dell'eseguibile e si impostano tre valori: DumpFolder per la cartella di output, DumpCount per il limite di conservazione (5-10 è un buon inizio) e DumpType (2 per dump completi, 1 per minidump se lo spazio disco è limitato). Non servono strumenti aggiuntivi da distribuire, e Windows salva un dump localmente ogni volta che l'app crasha. Verifica la configurazione forzando un crash in un ambiente di test e controllando che appaia un file .dmp.

Quando dovrei usare ProcDump invece di WER LocalDumps?

ProcDump è la scelta migliore quando si vuole evitare un'impostazione di registro permanente, monitorare un processo già in esecuzione, catturare first chance exception con -e 1, o catturare hang con -h, che WER gestisce male. Offre molte condizioni di trigger ed è facile da distribuire sul campo. Evita di registrarlo come debugger post-mortem con -i come prima mossa, perché cambia il comportamento del crash a livello macchina; il targeting per processo con -w, -x o un PID è più leggero.

Dovrei catturare minidump o dump completi?

Usa dump completi su macchine di sviluppo e test, e scegli mini o completi in ambienti cliente in base allo spazio su disco e ai vincoli di riservatezza. Spostati verso dump completi se sospetti corruzione di memoria, DLL native, COM, P/Invoke o anomalie di stato dopo lunga operatività, poiché catturano più informazioni. Tieni presente che i dump completi sono grandi e possono contenere configurazioni in chiaro, connection string, token e dati aziendali, quindi decidi in anticipo posizione di archiviazione, conteggio di conservazione e chi può accedervi.

Perché non riesco a leggere nulla di utile dal mio crash dump in WinDbg?

La causa più comune è la mancanza di simboli: un dump senza i PDB corrispondenti agli eseguibili distribuiti riduce drasticamente ciò che si può leggere. Conserva i PDB per ogni versione rilasciata insieme agli eseguibili, e registra quale commit e build li ha prodotti. In WinDbg, configura i simboli pubblici di Microsoft con .symfix, aggiungi la posizione dei tuoi PDB con .sympath+, ricarica e inizia con il comando automatico !analyze -v per vedere il codice di eccezione, il modulo in fault e lo stack di chiamata.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.