Impossibile passare al thread gestito in WinDbg

Question

Sto esplorando un minidump di un processo ASP.NET con WinDbg, utilizzando SOS. Se vi elenco i thread gestiti vedo una normale lista alla ricerca di fili:

0:000> !threads 
ThreadCount: 8 
UnstartedThread: 0 
BackgroundThread: 8 
PendingThread: 0 
DeadThread: 0 
Hosted Runtime: no 
               PreEmptive            Lock 
     ID OSID  ThreadOBJ  State GC  GC Alloc Context     Domain   Count APT Exception 
XXXX 1 12bc 00000000001441f0 1808220 Disabled 0000000140b10fc8:0000000140b12f20 000000000017f6e0  0 Ukn (Threadpool Worker) 
XXXX 2 1334 0000000000152f90  b220 Enabled 0000000000000000:0000000000000000 0000000000121b90  0 Ukn (Finalizer) 
XXXX 3 138c 000000000017b100 80a220 Enabled 0000000000000000:0000000000000000 0000000000121b90  0 Ukn (Threadpool Completion Port) 
XXXX 4 81c 000000000017eb40  1220 Enabled 0000000000000000:0000000000000000 0000000000121b90  0 Ukn 
XXXX 5 5e4 00000000001bccd0 880a220 Enabled 0000000000000000:0000000000000000 0000000000121b90  0 Ukn (Threadpool Completion Port) 
XXXX 6 11e4 0000000004bee280 180b220 Disabled 0000000000000000:0000000000000000 0000000000121b90  0 Ukn (Threadpool Worker) 
XXXX 7 73c 0000000004c267e0 180b220 Disabled 0000000140b0f158:0000000140b10f20 000000000017f6e0  3 Ukn (Threadpool Worker) System.StackOverflowException (000000007fff0138) (nested exceptions) 
XXXX 8 21c 00000000001ad1c0 180b220 Enabled 0000000000000000:0000000000000000 0000000000121b90  0 Ukn (Threadpool Worker) 

Tuttavia, se si tenta di passare a infilare 7 (quella con l'eccezione), ottengo questo:

0:000> ~7s 
     ^Illegal thread error in '~7s' 

Ciò accade quando si tenta di passare a qualsiasi thread gestito. Non sono sicuro da dove procedere da qui. Quello che devo veramente fare è vedere la traccia dello stack da quel thread gestito.

Answer 1

L'output da !threads mostra tre ID diversi per i thread (ID di WinDbg, ID gestito e ID nativo). Quello che devi usare è il più a sinistra. Come puoi vedere, tutti i thread nel dump sono stati contrassegnati come XXXX, il che significa che non sono più disponibili. Questo è normale, ma trovo strano che tutti i thread siano contrassegnati in questo modo. La discarica è stata eseguita durante l'arresto del processo?

UPDATE sulla base di commento

Si dovrebbe essere in grado di ottenere un dump utile con adplus -crash, ma è chiaro che tutto ciò è un po 'incasinato qui dal momento che anche il filo finalizzatore viene terminata. Ho notato che uno dei thread ha uno StackoverflowException, che è probabilmente quello che stai cercando. Per ottenere questo è possibile creare dump sulle eccezioni di prima scelta e vedere se si ottiene qualcosa di più utile in questo modo. Adplus ha una bandiera FullOnFirst per quello.

UPDATE Ulteriori

Okay, questo è strano. Un paio di altre cose da provare.

• Allegare al processo prima dell'incidente e lasciarlo solo g. Questo dovrebbe entrare nel debugger sulle eccezioni. Se lo desideri, puoi impostare un evento per stampare solo eventuali eccezioni alla console. Utilizzare sxe -c "!pe; !clrstack; gn" clr.

• L'adplus era uno script VBS, ma è stato riscritto come eseguibile qualche tempo fa. Ho visto alcuni problemi minori con la nuova versione, ma niente del genere. Potresti provare il vecchio script che è ancora disponibile come adplus_old.vbs.

• Provare procdump da sysinternals. Supporta lo stesso tipo di opzioni di dumping di Adplus (più alcune altre).