Come posso imparare WinDbg? (ri: processo appeso apparentemente semplice)

Question

Sto cercando di determinare il motivo per cui un processo è sospeso e sto imparando a conoscere vari strumenti come Process Explorer, Process Monitor e WinDbg.

Comunque, sto cercando di utilizzare WinDbg e dopo averlo applicato al mio processo, il debugger dice questo:

(1e9c.1128): Break instruction exception - code 80000003 (first chance) 
eax=7ffda000 ebx=00000000 ecx=00000000 edx=77c5c964 esi=00000000 edi=00000000 
eip=77c18b2e esp=0543ff5c ebp=0543ff88 iopl=0   nv up ei pl zr na pe nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00000246 
ntdll!DbgBreakPoint: 
77c18b2e cc    int  3 

Se corro !analyze -v, visualizza questo:

FAULTING_IP: 
ntdll!DbgBreakPoint+0 
77c18b2e cc    int  3 

I' m uno sviluppatore di software (VB.NET/C#) senza esperienza in questo livello di debug, quindi non sono sicuro di quello che sto facendo, ma sembra che WinDbg si colleghi al mio processo e poi si rompa immediatamente. Quindi, quando faccio un'analisi, pensa che il punto di interruzione (che ha appena impostato) è il problema con l'applicazione?

Come posso utilizzare WinDbg per collegarlo semplicemente a un processo e analizzarlo?

(Inoltre, ci sono dei buoni libri/tutorial per iniziare con questo livello di debug e WinDbg?) Blog

Answer 1

WinDbg è un debugger in modalità utente e kernel, ma da solo non comprende realmente il codice gestito e pertanto il comando !analyze è di uso limitato. Se si desidera eseguire il debug di applicazioni gestite utilizzando WinDbg, è necessario un modo per far comprendere a WinDbg le strutture interne del codice gestito. Esistono un numero di DLL di estensione che consente questo. Il framework .NET viene fornito con sos.dll e ci sono download come psscor2.dll e sosex.dll.

SOS e PSSCOR2 forniscono più o meno le stesse funzioni mentre SOSEX aggiunge nuove funzionalità per il debug gestito. I file di aiuto per ognuno di questi sono disponibili con WinDbg. Per esempio. per ottenere l'aiuto per SOS è possibile utilizzare il comando !sos.help.

È necessario caricare SOS o PSSCOR2 e possibilmente SOSEX per eseguire il debug di un'applicazione gestita con WinDbg. Per esempio.se si desidera caricare SOS si utilizza il comando di carico come questo

.loadby sos clr

Questo caricherà SOS dalla posizione del runtime .NET. Si noti che il runtime è denominato mscorwks in .NET 2 e coreclr in Silverlight, quindi se si utilizza uno di questi, è necessario modificare il comando .loadby di conseguenza.

WinDbg necessita di simboli per visualizzare informazioni aggiuntive. Questo è particolarmente importante per il codice non gestito. È possibile utilizzare il comando .symfix per consentire a WinDbg di recuperare i simboli necessari dal server dei simboli Microsoft.

Poiché la vostra applicazione è bloccata, ci sono buone probabilità che avrete uno o più thread bloccati. È possibile visualizzare i thread gestiti utilizzando il comando !threads (o solo !t). In .NET i blocchi semplici sono implementati internamente usando una struttura chiamata SyncBlocks. È possibile visualizzarli utilizzando il comando !syncblk. Se è stato caricato SOSEX, il comando !dlk può rilevare automaticamente i deadlock.

Se desideri maggiori informazioni, ci sono un paio di libri e alcuni blog da leggere.

Libri:

• Advanced .NET Debugging da Mario Hewardt. C'è anche un libro su native debugging dello stesso autore.
• Debugging Microsoft .NET 2.0 Applications di John Robbins
• CLR via C# di Jeffrey Richter è un'eccellente introduzione agli interni del CLR.

Blog:

• Tess' blog è grande. Ha numerosi tutorial e laboratori che puoi usare per esercitarti.
• Tom's blog è anche molto utile.

Video:

• ho fatto una presentazione sul debug gestito presso il centro di sviluppo di Microsoft in Danimarca. I video sono disponibili su Canale p. Part 1 e part 2.

Answer 2

Tess Ferrandez' è una risorsa fantastica per il materiale NET WinDbg:

If broken it is, fix it you should

Anche se molti dei suoi articoli bersaglio processo di lavoro IIS/ASP.NET di crash, si blocca e perdite, la maggior parte delle tecniche può essere applicato a tutti i tipi di scenari.

Answer 3

Advanced Windows Debugging sarebbe un buon inizio.

Quando Windbg si collega a un processo, inserisce una discussione che chiama DbgBreakPoint. Questo è ciò che stai vedendo. Puoi usare ~ per vedere i thread in esecuzione e poi ~ n per passare a un thread diverso. k ti darà una traccia dello stack del thread corrente, che dovrebbe darti un'idea del blocco.

Answer 4

L'istruzione int 3 (cc in binario) è uno dei modi in cui i debugger impostano i punti di interruzione in un'applicazione. Questa istruzione genera un interrupt che mette in pausa l'esecuzione del programma e dà al debugger l'opportunità di reagire a questo interrupt. Hai solo bisogno di scegliere di continuare l'esecuzione fino a raggiungere il punto in cui il programma è sospeso.