Ho un cliente che sta ottenendo un crash riproducibile al 100% che non riesco a replicare nel mio programma compilato in Visual Studio 2005. Ho inviato loro una build di debug del mio programma e mantenuto a portata di mano tutti i file PDB e DLL. Mi hanno inviato il file minidump, ma quando lo apro ricevo:Debug di un minidump in Visual Studio in cui lo stack di chiamate è nullo
"Eccezione non gestita a 0x00000000 in MiniDump.dmp: 0xC0000005: posizione di lettura violazione violazione 0x00000000."
Quindi lo stack di chiamate mostra solo "0x00000000()" e lo smontaggio mostra un dump della memoria a 0x0. Ho impostato il server dei simboli, caricato i miei simboli PDB, ecc. Ma non riesco a vedere alcun modo per sapere quale delle molte DLL abbia effettivamente causato il salto nullo. Si tratta di un progetto di grandi dimensioni con molte dipendenze e alcuni di essi sono binari per i quali non dispongo dell'origine o dei PDB, poiché sto utilizzando un'API di terze parti.
Quindi, come mai questo minidump è utile? Come posso vedere quale DLL ha causato l'arresto anomalo? Non ho mai usato minidump per il debugging, ma tutte le esercitazioni che ho letto sembrano mostrare almeno un nome di funzione o qualcos'altro che ti dà un indizio nello stack di chiamate. Ho appena ottenuto la riga che punta a null.
Ho anche provato a utilizzare "Depends" per verificare se esistesse una dipendenza DLL non risolta; tuttavia sulle mie tre macchine di prova con vari sistemi operativi Windows, mi sembra di ottenere tre diversi set di dipendenze DLL OS (e tuttavia non è possibile replicare l'arresto anomalo); quindi questo non sembra un metodo particolarmente affidabile per diagnosticare il problema.
Quali altri metodi sono disponibili per determinare la causa di questo problema? C'è un modo per fare un passo indietro di un'istruzione per vedere quale DLL è saltata su null?
ld ModuleName carica i simboli per un modulo. ! analyze -v ti darà una traccia dello stack. Tra questi due, dovresti avere abbastanza informazioni per iniziare. http://windbg.info/doc/1-common-cmds.html ha una lista di comandi WinDbg comuni. –
Hai ragione Vanessa: stavo usando il debugger integrato in Visual Studio, ma quando uso WinDbg ottengo il nome del modulo. La lezione è qui: non utilizzare il debugger di Visual Studio per analizzare l'analisi post-mortem dello stack? – Piers
Ogni volta che ho visto questo è stato causato chiamando un puntatore a funzione nulla. – paulm