Analisi di crash dump in windbg

Question

Sto utilizzando un'API closed source di terze parti che genera un'eccezione che indica che "tutte le pipe denominate sono occupate".

Vorrei eseguire il debug di questo ulteriore (piuttosto che semplicemente passare attraverso) in modo da poter effettivamente imparare cosa sta succedendo sotto le copertine.

Ho preso un dump di questo processo utilizzando WinDbg. Quali comandi dovrei usare ora per analizzare questo dump?

Grazie

Answer 1

Questo in genere accade quando un client chiama CreateFile per un tubo esistente e tutte le istanze dei tubi esistenti sono occupati. A questo punto, CreateFile restituisce un errore e il codice di errore è ERROR_PIPE_BUSY. La cosa giusta a questo punto è chiamare WaitNamedPipe con un valore di timeout per aspettare che un'istanza di pipe sia disponibile.

Il problema si verifica in genere quando più client tentano di connettersi alla pipe denominata nello stesso momento.

Answer 2

Si considera che il terzo partito dll è nativo (In caso contrario, basta usare Reflector)

Prima di utilizzare WinDbg per analizzare il dump, provare a utilizzare Process Monitor (SysInternals, freeware) per monitorare l'attività del processo. se fallisce a causa di un problema relativo al file system, puoi vedere esattamente cosa ha causato il problema e cosa ha cercato di fare esattamente prima di fallire.

Se Process-Monitor non è stato sufficiente, è possibile provare e eseguire il debug del processo. ma per vedere alcune informazioni significative sulla dll di terze parti ti serviranno pdb's.

Dopo aver impostato i simboli di debug corretti, è possibile visualizzare lo stack di chiamate utilizzando il comando k o una delle sue varianti (di nuovo, presumo che si stia parlando di codice nativo). se il tuo processo si blocca effettivamente a causa di questa dll, esamina i parametri che passi alla sua funzione per assicurarti che il problema non sia dalla tua parte. Immagino che più avanti nello stack delle chiamate arrivi a qualche API Win32 - esamina i parametri che la funzione della DLL sta passando, cercando di vedere se qualcosa "odora". Se si dispone del simbolo privato della DLL, è possibile esaminare anche le variabili locali della funzione (dv) che possono fornire ulteriori informazioni.

Spero di averti dato un buon punto di partenza.

Answer 3

Questa è una risorsa eccellente per l'utilizzo di WinDbg per analizzare incidenti che possono essere di qualche utilità: http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

L'articolo è per Windows 10, ma contiene collegamenti a informazioni simili per le versioni precedenti di Windows.

Answer 4

In debug postmortem con Windbg, può essere utile eseguire alcuni comandi di diagnostica generale prima di decidere dove scavare più a fondo. Questi dovrebbero essere i tuoi primi passi:

.logopen <filename> (See also .logappend) 
.lastevent    See why the process halted and on what thread 
u      List disassembly near $eip on offending thread 
~      Status of all threads 
Kb      List callstack, including parameters 
.logclose 

Questi comandi in genere ti forniscono una panoramica di ciò che è accaduto in modo da poter approfondire. Nel caso di gestione di librerie in cui non si dispone di origine, l'invio del file di registro risultante al fornitore insieme al numero di build della libreria binaria dovrebbe essere sufficiente per consentirne la tracciabilità a un problema noto, se disponibile.

Answer 5

Si potrebbe iniziare a fare come segue per avere una panoramica di eccezione:

!analyze -v 

Ora è possibile caricare il record di contesto eccezione:

.ecxr 

E adesso ... basta dare un'occhiata allo stack, registri, discussioni, ...

kb  ;will show you the stack trace of the crash. 
dv  ;local variables 

A seconda degli indizi ottenuti, è necessario seguire un dif direzione feroce. Se si desidera un riferimento rapido a WinDbg, ti consigliamo di utilizzare lo this link.

Spero che tu abbia trovato alcuni di questi comandi e informazioni utili.