Aiuto cattura StackOverflowException con WinDbg e ADPlus

Question

Versione breve

voglio uno script ADPlus che farà un dump di memoria completa sul StackOverflowException first-chance, prima di tutto viene ripulito, e ignorare tutti gli altri tipi di eccezione.

Log Versione

Dopo un rilascio di nuovo codice ASP.NET, abbiamo iniziato a ricevere StackOverflowExceptions intermittenti. Abbiamo cercato infinite ricorsioni e tutti i soliti sospetti nelle revisioni aggiunte dall'ultima installazione nota e non abbiamo trovato nulla. Il sito Web funzionerà fino a un'ora e poi si arresterà in modo anomalo.

Abbiamo utilizzato WinDbg e SOS e cercato di ottenere resoconti di blocco utilizzando ADPlus, con questo comando:

adplus -crash -o D:\Crash -NoDumpOnFirst -iis 

La ragione di -NoDumpOnFirst è che possiamo solo riprodurre questo errore nella produzione su server occupato. Per eseguire un minidump su ciascuna eccezione di prima scelta (hey, succede), il debugger deve sospendere il processo di lavoro IIS abbastanza a lungo da scrivere un file da 16 megabyte, quindi le richieste vengono accodate e l'applicazione diventa instabile. Perché l'errore può richiedere fino a un'ora per allevare la sua brutta testa, questo è problematico.

Quindi, con -NoDumpOnFirst, ho un file di dump che WinDbg uscite queste discussioni per:

PDB symbol for mscorwks.dll not loaded 
ThreadCount: 69 
UnstartedThread: 0 
BackgroundThread: 69 
PendingThread: 0 
DeadThread: 0 
Hosted Runtime: no 
             PreEmptive GC Alloc   Lock 
     ID OSID ThreadOBJ State  GC  Context  Domain Count APT Exception 
XXXX 1 c6c 000fa758 11808221 Disabled 3b49ee4c:3b49efe8 00120888  1 Ukn (Threadpool Worker) 
XXXX 2 1294 000fd258  b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Finalizer) 
XXXX 3 1eb0 0011cdd0 80a220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Completion Port) 
XXXX 4 1b3c 00120198  1220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 5 1280 00138118 880a220 Enabled 2633de9c:2633ee08 000df4e0  0 Ukn (Threadpool Completion Port) 
XXXX 6 1db8 00158a48 1180a221 Disabled 4b5a7e2c:4b5a82e8 00120888  1 Ukn (Threadpool Worker) 
XXXX 9 141c 00162008 180a220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 7 1574 00174008 180a220 Enabled 4d46b6a8:4d46c158 00120888  2 Ukn (Threadpool Worker) 
XXXX c 16c8 0016b7a8 180a220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 8 1384 00162878 180a220 Enabled 284e26a4:284e45d8 000df4e0  0 Ukn (Threadpool Worker) 
XXXX b 1c10 0016b3d8 180a220 Enabled 3ed2dae0:3ed2dfe8 00120888  2 Ukn (Threadpool Worker) 
XXXX a 1814 0016b008 180a220 Disabled 28816384:28816638 00120888  1 Ukn (Threadpool Worker) 
XXXX d 1fc 1b4d1ff0  220 Enabled 319f89a4:319fa41c 000df4e0  0 Ukn 
XXXX e 1864 1b4e3d20 180b220 Enabled 4b2c5be0:4b2c6150 000df4e0  0 Ukn (Threadpool Worker) 
XXXX f 13bc 1b57caf8 200b220 Enabled 4cc71584:4cc73414 00120888  1 Ukn 
XXXX 10 72c 1f5124a8 180b220 Enabled 3b4b3414:3b4b4fe8 00120888  2 Ukn (Threadpool Worker) 
XXXX 11 1fd0 1f526398 180b220 Disabled 4d46f41c:4d470158 00120888  1 Ukn (Threadpool Worker) 
XXXX 12 1f10 1f52f1c8 180b220 Enabled 28812c14:28814638 00120888  2 Ukn (Threadpool Worker) 
XXXX 13 1b84 1f53a420  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 14 18a4 1f570978 180b220 Enabled 263e18b4:263e2e28 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 15 1a98 1f57f0a0 180b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 16 1b4 1f583628 180b220 Enabled 495781ec:4957914c 00120888  2 Ukn (Threadpool Worker) 
XXXX 17 b90 1f585dc8 180b220 Enabled 265cbe48:265ccba4 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 18 1590 1f613c60  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 19 1850 1f5fad90  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 1a c78 1f60d3f0  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 1c 1bd8 2121f1b0  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 1d 494 1b4a8c10  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 1e 898 2120f120  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 1f 1820 21355ff8  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 20 15b0 3570e120  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 21 18b0 359ca008  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 22 75c 35a58948  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 25 1a18 213ac8f8 880b220 Disabled 3219a830:3219b450 00120888  1 Ukn (Threadpool Completion Port) System.StackOverflowException (0e3200a4) 
XXXX 29 1b74 3598e620 180b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 2a 9b8 3598dbe0 180b220 Enabled 2880ef2c:28810638 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 2b 1eac 1f6f6288 180b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 2d 2f4 211759e8 180b220 Disabled 2634eacc:2634ee08 00120888  1 Ukn (Threadpool Worker) 
XXXX 2e 1e3c 35c2eb60 880b220 Enabled 4b5a5758:4b5a62e8 000df4e0  0 Ukn (Threadpool Completion Port) 
XXXX 30 394 35c394f8 180b220 Enabled 4cef7930:4cef90d4 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 31 1e64 35c39128 180b220 Disabled 288110b0:28812638 00120888  1 Ukn (Threadpool Worker) 
XXXX 32 1af8 35a58578 180b220 Enabled 3b48e7cc:3b48efe8 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 34 1d44 1f6a6c88 180b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 35 197c 212088e0 180b220 Enabled 49389ba8:4938af40 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 36 1e2c 35c1d980  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 38 1ddc 212d03d8  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 39 288 212d0008  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 3a 1694 212bf958  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 3b be4 212ccc40  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 37 ccc 35c4d6d0  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 3c 14ec 35c55af0  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 41 1d94 35c38c08 180b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 24 130 35746a50 180b220 Enabled 2670ae48:2670cc00 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 2f 1404 35c1d350 180b220 Enabled 00000000:00000000 000df4e0  0 Ukn (Threadpool Worker) 
XXXX 43 1ae8 35c25cb8 180b220 Disabled 3b4c28e0:3b4c2fe8 00120888  1 Ukn (Threadpool Worker) 
XXXX 44 18ac 212cc870 180b220 Disabled 4957e728:4957f14c 00120888  1 Ukn (Threadpool Worker) 
XXXX 45 18b4 212bf588 180b220 Disabled 3b4c05dc:3b4c0fe8 00120888  1 Ukn (Threadpool Worker) 
XXXX 46 1c0c 21239858  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 47 4fc 21188b68  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 48 1198 35caa2a8  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 49 1f9c 21147af8  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 4a 1adc 35cc6908  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 4b ce8 35c60e30  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 4d 6f0 35d05aa0  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 4e 1ee8 35c1b6b0  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 42 1d7c 35d9a230  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 3d 7d8 212e1b28  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 23 c0c 503ea010  220 Enabled 00000000:00000000 000df4e0  0 Ukn 
XXXX 27 1f44 503cdf08  220 Enabled 00000000:00000000 000df4e0  0 Ukn 

Cercando di stampare l'eccezione dimostra che non v'è alcuna traccia dello stack, e altri metodi si lamentano che si tratta di codice non gestito. La mia ipotesi è che mentre il dump viene creato alla morte del processo, tutti i thread sono stati raccolti e non ci sono informazioni da ottenere.

Mi piacerebbe davvero che il debugger eseguisse un dump completo sulla prima possibilità di StackOverflowException e ignorasse tutti gli altri tipi di eccezioni. So che ADPlus può usare un file di configurazione - http://msdn.microsoft.com/en-us/library/cc409304.aspx - ma il formato è tutto greco per me. Qualcuno può mostrarmi come creare uno script ADPlus che lo farà?

... ovviamente se si guarda l'elenco di thread sopra e si sa esattamente cosa c'è che non va, o si potrebbe capire se ti ho dato ulteriori informazioni, potresti dirmi anche questo.

Risoluzione Tentativo 1

Grazie deemok per la risposta qui sotto, non era giusto, ma che mi ha spinto nella direzione giusta. Il codice di eccezione per Stack Overflow non era corretta (è SBO non SOV), (o così ho pensato al momento, vedere le modifiche del deemok sotto) così ho provato il debug con la seguente configurazione:

<ADPlus> 
    <!-- Add log entry, log faulting thread stack and dump full on first chance StackOverflow --> 
<Exceptions> 
    <Config> 
     <!-- This is for the StackOverflow exception --> 
     <Code> sbo </Code> 
     <Actions1> Log;Stack;FullDump </Actions1> 
     <!-- Depending on what you intend - either stop the debugger (Q or QQ) or continue unhandled (GN) --> 
     <ReturnAction1> GN </ReturnAction1> 
    </Config> 
    </Exceptions> 
</ADPlus> 

E usando il seguente comando :

adplus -crash -o D:\Crash -NoDumpOnFirst -c D:\Crash\stackoverflow.cfg -iis 

Ho verificato che i file di registro emessi indicassero la configurazione corretta. Il trucco è che i parametri della riga di comando di adplus vengono eseguiti in ordine, quindi se si inizia con una configurazione che intercetta le eccezioni first-chance e poi si applica -NoDumpOnFirst, le impostazioni di configurazione verranno sovrascritte. Se applichi la configurazione con -c last, le sue impostazioni si vinceranno.

Alla fine, tuttavia, l'overflow dello stack si è rivelato ingestibile. L'overflow dello stack è avvenuto, non è stato possibile ricevere alcun dump della memoria, quindi è stato eseguito un dump nel caso dell'evento di seconda uscita del processo, e di nuovo tutto è stato raccolto e non sono riuscito a ottenere alcuna informazione utile.

Ho tentato di cortocircuitare l'eccezione di fine processo, nel caso che fosse coinvolgente e sovrascriva l'overflow dello stack, ma poi si è verificata l'eccezione e non ho ottenuto alcun dump della memoria.

Fortunatamente, sono incappato nella risposta esaminando il codice. Era un caso di chiamata al metodo circolare, ovviamente.

risoluzione effettiva

Il problema era stato risolto molto tempo fa, ma ho subito fatto una pagina ASP.NET che potrebbe causare un overflow dello stack. (Non è difficile da fare dopotutto) e ho provato la risposta di Axl qui sotto.

L'XML è stato un po 'fuori - Axl ha dimenticato di chiudere il tag </ADPlus> (o probaby perso in un copia-incolla), ma che era abbastanza facile da risolvere e adplus era così gentile da dirmi esattamente che cosa era sbagliato.

Ho impostato questo script contro il mio overflow di test stack, caricato il risultato in windbg e quando ho chiamato! Clrstack ho ottenuto un elenco molto chiaro (e lungo) dei metodi che si chiamavano a vicenda in modo circolare. Questo avrebbe trovato il problema in un istante! Terrò questa pagina segnalibro per la prossima volta che un overflow di stack viene a bussare alla mia porta.

Answer 1

Nel caso in cui questo potrebbe aiutare qualcun altro, di seguito è riportato il file di configurazione ADPlus. Guardandolo ora, non ne sono sicuro! Scappare ha qualche effetto. Collegato quando un'applicazione ASP.NET che genera una StackOverflowException è in esecuzione, questo genererà i file .dmp "1st chance StackOverflow full" e "1st chance Process Shut Down full" nella OutputDir specificata. Apri il primo file con Windbg ed esegui ".loadby sos mscorwks" seguito da "! Clrstack" per vedere cosa potrebbe causare lo stack overflow.

<ADPlus> 
<Settings> 
    <RunMode>CRASH</RunMode> 
    <OutputDir>C:\Dumps</OutputDir> 
    <ProcessName>w3wp.exe</ProcessName> 
</Settings> 
<Exceptions> 
    <Option>FullDumpOnFirstChance</Option> 
    <Option>MiniDumpOnSecondChance</Option> 
    <Option>NoDumpOnFirstChance</Option> 
    <Option>NoDumpOnSecondChance</Option> 
    <Config> 
     <Code>AllExceptions</Code> 
     <Actions1>Void</Actions1> 
     <Actions2>Void</Actions2> 
     <ReturnAction1>GN</ReturnAction1> 
     <ReturnAction2>GN</ReturnAction2> 
    </Config>  
    <Config> 
     <!-- 
     av = AccessViolation 
     ch = InvalidHandle 
     ii = IllegalInstruction 
     dz = IntegerDivide 
     c000008e = FloatingDivide 
     iov = IntegerOverflow 
     lsq = InvalidLockSequence 
     sov = StackOverflowException 
     eh = CPlusPlusEH 
     * = UnknownException 
     clr = NET_CLR 
     bpe = CONTRL_C_OR_Debug_Break 
     ld = DLL_Load 
     ud = DLL_UnLoad 
     epr = Process_Shut_Down 
     sbo = Stack_buffer_overflow 
     --> 
     <Code>sov;sbo</Code> 
     <Actions1>Log;Time;Stack;FullDump;EventLog</Actions1> 
     <CustomActions1>!runaway</CustomActions1> 
     <Actions2>Log;Time;Stack;FullDump;EventLog</Actions2> 
     <CustomActions2>!runaway</CustomActions2> 
     <!-- 
     G = go 
     GN = go unhandled exception 
     GH = go handled exception 
     Q = quit 
     QD = quit and detach 
     --> 
     <ReturnAction1>GN</ReturnAction1> 
     <ReturnAction2>GN</ReturnAction2> 
    </Config> 
    <Config> 
     <Code>clr</Code> 
     <Actions1>Void</Actions1> 
     <Actions2>Log;Time;Stack;FullDump;EventLog</Actions2> 
     <ReturnAction1>GN</ReturnAction1> 
     <ReturnAction2>GN</ReturnAction2> 
    </Config> 
    <Config> 
     <Code>epr</Code> 
     <Actions1>Log;Time;Stack;FullDump;EventLog</Actions1> 
     <Actions2>Void</Actions2> 
     <ReturnAction1>GN</ReturnAction1> 
     <ReturnAction2>GN</ReturnAction2> 
    </Config> 
</Exceptions> 
</ADPlus> 

Answer 2

 
<ADPlus> 
    <!-- Add log entry, log faulting thread stack and dump full on first chance StackOverflow --> 
<Exceptions> 
    <Config> 
     <!-- This is for the stack buffer overflow exception --> 
     <!-- Use sov for stack overflow exception --> 
     <Code> sbo </Code> 
     <Actions1> Log;Stack;FullDump </Actions1> 
     <!-- Depending on what you intend - either stop the debugger (Q or QQ) or continue unhandled (GN) --> 
     <ReturnAction1> GN </ReturnAction1> 
    < Config> 
    </Exceptions> 
</ADPlus> 

Salva che nel stackoverflow.cfg
allora si può andare:

adplus -c stackoverflow.cfg

Edit: entrambi SOV e SBO sono impilare eccezioni di overflow. Immagino che sia necessario sperimentare entrambi, poiché non è del tutto chiaro quale sia la differenza tra i due. (potrebbe sbo denotare una chiamata non valida alloca()?