In Windows è possibile permettere alle applicazioni C/C++ distribuite ai clienti di creare dei dump che il cliente può inviarci - ad esempio per email - per aiutarci a trovare e risolvere problemi attraverso i classici strumenti di debug.

Per debuggare applicazioni a partire da un crash dump, prima di tutto:

- Copiare in una cartella tutto il ramo di sviluppo della versione relativa al dump. Es: creare c:dev_1089 e copiarci le cartelle contenenti insieme sorgenti, eseguibili e file di browsing (.pdb) di applicazioni e librerie (i file eseguibili e le dll devono essere al livello dei sorgenti).

- Copiare il file di dump (.dmp) nella cartella specifica dell'applicazione.

(sotto App è la sotto-cartella per l'applicazione specifica all'interno di dev_1089; ad esempio per 'c:dev_1089HelloWorld', App sarà HelloWorld)

Consideriamo la possibilità di eseguire il debug con due applicazioni Microsoft, una gratuita (WinDbg) e l'altra commerciale (Visual Studio/C++ standard o professional, non ho idea se la cosa funziona anche sulla versione express gratuita ma penso di sì).

-- WinDbg --
- Scaricare ed installare i Debugging Tools di Microsoft.

- Creare un collegamento per ogni applicazione con la seguente destinazione (a meno di personalizzazioni):
"C:ProgrammiDebugging Tools for Windowswindbg.exe" -y App;Appplug-in -i App;Appplug-in -srcpath . -z AppEW_CRASH.DMP -c ".ecxr" -Q -failinc
La voce "Da:" del collegamento deve puntare a c:dev_1089, ovvero la root dei sorgenti. Questo comando esegue il debugger impostando le cartelle dei simboli (-y), dei binari (-i) e dei sorgenti (-srcpath), specificando il file di dump (-z), evitando alcuni warning (-Q -failinc) ed eseguendo subito l'istruzione per leggere il dump e spostarsi sull'istruzione che ha causato l'eccezione (-c ".ecxr"). Dal debugger e' possibile vedere tra le altre cose, attraverso i comandi della toolbar, i sorgenti, il codice assembler, il contenuto dei registri e il call stack.

-- Visual Studio --
- Aprire Visual Studio e scegliere "Apri soluzione...". Nel dialogo impostare come filtro di file "File dump" e selezionare il file .dmp del crash.

- Andare nelle proprietà del progetto che ha il nome del file di dump. Impostare come directory di lavoro la root dei sorgenti/eseguibili: c:dev_1089. Impostare come percorso simboli "App;Appplug-in" e come argomenti del comando "MODPATH=App;Appplug-in" (che imposta dove cercare eseguibili e dll dell'applicazione).

- Andare nelle proprietà della soluzione ed aggiungere alla voce "Esegui debug dei file di origine" la cartella root dei sorgenti: c:dev_1089.

- Avviare il debug con F5/play. Sarà richiesto un nome file per salvare la soluzione.

È possibile debuggare un eseguibile senza avere a disposizione un crash dump nel caso in cui si sappia l'indirizzo dell'istruzione che ha causato il problema (ad esempio quello dato dalla classica finestra "L'applicazione ha generato un'eccezione..."). Per WinDbg è sufficente non utilizzare -z e -c nella riga di comando e, una volta aperto il debugger, utilizzare il comando "Go to Address..." (a volte può essere necessario tentare il comando più volte). Per Visual Studio è sufficiente aprire come soluzione il file eseguibile dell'applicazione ed impostare nelle proprietà del progetto il path dei simboli e in quelle della soluzione il path dei sorgenti; fare quindi un singolo step per avviare il debug e usare il "Go to..." per inserire l'indirizzo (va specificato 0x all'inizio dell'indirizzo per indicare che il numero è esadecimale).

WinDbg è meno intuitivo e ha un'interfaccia più scarna di Visual Studio, ma è più semplice da configurare e si presta per creare velocemente collegamenti diversi per tutte le applicazioni da debuggare, anche al variare delle versioni. Al contrario con Visual Studio è necessario fare più modifiche ai progetti per adattarli a versioni o applicazioni diverse e tutto sommato si fa prima a ricostruire direttamente le soluzioni da capo.