Se la nostra applicazione va in errore fuori dal nostro ambiente di sviluppo e non riusciamo a riprodurre il problema (seguendo eventualmente la procedura indicata dal nostro cliente) iniziano inevitabilmente i… dolori!
Spesso l’unica arma di cui disponiamo con applicazioni scritte in codice gestito è lo StackTrace ovvero la sequenza di funzioni che sono state chiamate prima della manifestazione del fatidico errore ma nella maggior parte dei casi non basta a capire dove si è verificato realmente il problema, serve una completa istantanea dello stato dell’applicazione (o memoria del processo) che comprenda sia la cronologia delle funzioni chiamate sia i valori delle variabili interne.
Nel mondo Windows l’istantanea si traduce in Mini Dumps e Full Dumps, in poche parole istantanee di parte della memoria del processo e istantanee della memoria del processo assieme alla memoria degli altri moduli (anche di sistema) caricati.
Il vantaggio nell’uso di Mini Dumps si traduce in dimensioni minori, solamente alcune sezioni della memoria del processo sono salvate, moduli come user32.dll non sono salvati poiché è possibile recuperare una copia dei file dal CD di Windows della corrispondente versione.
Fino ad oggi WinDbg (Windows Debugger) con SOS.dll (Son of Strike, un’estensione per il debugging di applicazioni gestite) erano la lunga e dura strada da intraprendere che richiedeva parecchio studio e dedizione per riuscire a scoprire la causa dell’errore partendo dal Dump del crash.
Visual Studio 2010 apre nuove strade al debug Post-Mortem ovvero al debug di applicazioni dopo l’errore, permette infatti di aprire i file dump del crash di applicazioni gestite e visualizzarne lo stato(stack, variabili locali, etc..) senza utilizzare SOS e rendere quindi più rapido e confortevole il debug.
Per poter eseguire il debug dobbiamo disporre oltre che al file dump (.dmp) del crash anche dei sorgenti e del file dei simboli (.pdb) corrispondente ai binari dell’applicazione.
NB: E’ buona norma conservare sempre i file .pdb e i sorgenti delle release distribuite a terzi della nostra applicazione.
Passiamo adesso alla pratica e vediamo un caso pratico di debug “Post-Mortem”:
Apriamo Visual Studio 2010 e creiamo una nuova applicazione Windows Forms 4.0 inserendo del semplice codice a scopo dimostrativo che generi un’errore di divisione per zero:
Eseguiamo in modalità Release la nostra applicazione e alla segnalazione dell’eccezione da parte di Visual Studio salviamo il Dump andando su Debug/Save Dump As.., in scenari reali dovremo modificare la nostra applicazione per creare automaticamente un Dump in caso di crash e spedircelo se il cliente acconsente o più semplicemente potremmo registrarci a WinEqual per poter ricevere i dump della segnalazione standard di errori di Windows.
Il dump del crash può raggiungere centinaia di megabyte
Utilizzando Windows Vista o Windows 7 possiamo anche creare tramite Task Manager (Gestione Attività) il MiniDump del processo scegliendo Create Dump file (Crea file di dettagli) dalla scheda Processi.
NB: Il dump così creato non è però utilizzabile dalla versione Visual Studio 2010 Beta 1. La strada suggerita è utilizzare AdPlus per catturare il dump della propria applicazione in "produzione".
Creiamo ora una nuova soluzione vuota in Visual Studio per analizzare il nostro file di dump
Aggiungiamo alla soluzione un nuovo elemento esistente facendo click destro sulla soluzione nel Solution Explorer e scegliendo Add Existing Item.
Indichiamo il file di crash del dump salvato in precedenza.
Verrà automaticamente mostrata una schermata con alcune informazioni sul file Dump, indichiamo però prima di iniziare il Debug la cartella contenente il file .pdb della nostra applicazione cliccando su Set symbol paths (se non visibile subito sarà necessario scorrere la finestra verso destra).
Nella finestra di dialogo Symbols che apparirà clicchiamo sull’icona della cartella per indicare la posizione del nostro file .pdb.
Clicchiamo infine start debugging (la grossa freccia verde) per iniziare ad analizzare l’applicazione proprio dallo stato in cui avevamo salvato il file dump
L’esperienza di debug sarà simile ad un normale debug in fase di sviluppo (con alcune limitazioni), andando col mouse sopra alle variabili appariranno i valori contenuti. Se richiesto indichiamo la posizione dei file sorgenti necessari per visualizzare il codice (dovranno ovviamente essere la stessa versione dell’eseguibile crashato)
Cliccando sull’icona alla destra del valore possiamo inserire dei commenti per migliorare la collaborazione con gli altri sviluppatori se al progetto hanno partecipato più persone.
Le nuove funzionalità di debug di Visual Studio 2010 rappresentano un grande passo in avanti per colmare il gap con il debug post-mortem di applicazioni native e sicuramente si renderanno molto utili in scenari client/server dove costituiranno un insostituibile aiuto allo sviluppatore.