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. Informazioni maggiori su come creare questi dump sono disponibili su questo link e quest'altro.
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_1089\HelloWorld', 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:\Programmi\Debugging Tools for Windows\windbg.exe" -y App;App\plug-in -i App;App\plug-in -srcpath . -z App\EW_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;App\plug-in" e come argomenti del comando "MODPATH=App;App\plug-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.
Ultimi commenti