Interpretazione degli stack nei minidump di Windows

StackOverflow https://stackoverflow.com/questions/77887

Domanda

Essendo qualcuno che sta appena iniziando a imparare le complessità del debug del computer, per quanto mi riguarda, non riesco a capire come leggere lo Stack Text di un dump in Windbg.Non ho idea di dove cominciare su come interpretarli o come procedere.Qualcuno può offrire indicazioni a questa povera anima?

cioè (l'unica discarica che ho a portata di mano in realtà)

>b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94

b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255

b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0

b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

So che il problema ha a che fare con il driver video Nvidia, ma quello che voglio sapere è come leggere effettivamente lo stack (ad esempio, cos'è b69dd8f4?) :-[

È stato utile?

Soluzione

Innanzitutto, è necessario configurare i simboli corretti.I simboli ti permetteranno di abbinare gli indirizzi di memoria ai nomi delle funzioni.Per fare ciò devi creare una cartella locale nel tuo computer in cui memorizzerai una cache locale di simboli (ad esempio:C:\simboli).Quindi è necessario specificare il percorso del server dei simboli.Per farlo basta andare su:File > Percorso file simbolo e digitare:

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Puoi trovare maggiori informazioni su come configurare correttamente i simboli Qui.

Una volta configurato correttamente il server dei Simboli è possibile aprire il minidump da:File > Apri dump arresto anomalo del sistema.

Una volta aperto il minidump, sul lato sinistro della riga di comando verrà visualizzato il thread in esecuzione al momento della generazione del dump.Se vuoi vedere cosa stava eseguendo questo thread digita:

kpn 200

Questa operazione potrebbe richiedere del tempo la prima volta che lo esegui poiché deve scaricare i simboli pubblici relativi a Microsoft necessari per la prima volta.Una volta scaricati tutti i simboli otterrai qualcosa del tipo:

01 MODULE!CLASS.FUNCTIONNAME1(...)
02 MODULE!CLASS.FUNCTIONNAME2(...)
03 MODULE!CLASS.FUNCTIONNAME3(...)
04 MODULE!CLASS.FUNCTIONNAME4(...)

Dove:

  • IL PRIMO NUMERO:Indica il numero del fotogramma
  • MODULO:La DLL che contiene il codice
  • CLASSE:(Solo su codice C++) ti mostrerà la classe che contiene il codice
  • FUNZIONE:Il metodo che è stato chiamato.Se hai i simboli corretti vedrai anche i parametri.

Potresti anche vedere qualcosa di simile

01 MODULE!+989823

Ciò indica che non disponi del simbolo corretto per questa DLL e pertanto puoi solo vedere l'offset del metodo.

Allora, cos'è uno stack di chiamate?

Immagina di avere questo codice:

void main()
{
  method1();
}

void method1()
{
  method2();
}

int method2()
{
  return 20/0;
}

In questo codice il metodo 2 sostanzialmente lancerà un'eccezione poiché stiamo provando a dividere per 0 e questo causerà l'arresto anomalo del processo.Se ottenessimo un minidump quando ciò si verifica, vedremmo il seguente stack di chiamate:

01 MYDLL!method2()
02 MYDLL!method1()
03 MYDLL!main()

Puoi seguire da questo stack di chiamate che "main" ha chiamato "method1" che poi ha chiamato "method2" e ha fallito.

Nel tuo caso hai questo CallStack (che immagino sia il risultato dell'esecuzione del comando "kb")

b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94
b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255
b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0
b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

La prima colonna indica il Child Frame Pointer, la seconda colonna indica l'indirizzo di ritorno del metodo che è in esecuzione, le tre colonne successive mostrano i primi 3 parametri che sono stati passati al metodo e l'ultima parte è il nome della DLL (nv4_disp) e l'offset del metodo che viene eseguito (+0x48b94).Poiché non hai i simboli, non puoi vedere il nome del metodo.Dubito che NVIDIA offra accesso pubblico ai propri simboli, quindi immagino che non sia possibile ottenere molte informazioni da qui.

Ti consiglio di eseguire "kpn 200".Questo ti mostrerà lo stack di chiamate completo e potresti essere in grado di vedere l'origine del metodo che ha causato questo arresto anomalo (se fosse una DLL Microsoft dovresti avere i simboli corretti nei passaggi che ti ho fornito).

Almeno sai che è legato a un bug NVIDIA ;-) Prova ad aggiornare le DLL di questo driver all'ultima versione.

Nel caso in cui desideri saperne di più sul debug di WinDBG ti consiglio i seguenti link:

Altri suggerimenti

Un ottimo tutorial sull'interpretazione di una traccia dello stack è disponibile qui:

http://www.codeproject.com/KB/debug/cdbntsd2.aspx

Tuttavia, anche con un tutorial del genere può essere molto difficile (o quasi impossibile) interpretare uno stack dump senza i simboli corretti disponibili/caricati.

Potrebbe essere utile includere un esempio dello stack che stai tentando di leggere.Un buon consiglio è quello di assicurarsi di avere i simboli di debug corretti per tutti i moduli mostrati nello stack.Ciò include i simboli per i moduli nel sistema operativo, Microsoft ha reso pubblicamente disponibile il proprio server dei simboli.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top