Aide à attraper StackOverflowException avec WinDbg et ADPlus
-
06-07-2019 - |
Question
Version courte
Je veux un script ADPlus qui effectue un vidage complet de la mémoire lors de la première chance StackOverflowException, avant que tout ne soit nettoyé, et ignore tous les autres types d'exception.
Version du journal
Après la publication du nouveau code ASP.NET, nous avons commencé à obtenir des StackOverflowExceptions par intermittence. Nous avons recherché des récursions infinies et tous les suspects habituels dans les révisions ajoutées depuis la dernière bonne installation connue et nous ne trouvons rien. Le site Web fonctionnera pendant une heure au maximum, puis tombera en panne.
Nous avons utilisé WinDbg et SOS et tenté d'obtenir les journaux des incidents en utilisant ADPlus, à l'aide de la commande suivante:
adplus -crash -o D:\Crash -NoDumpOnFirst -iis
La raison de -NoDumpOnFirst est que nous ne pouvons reproduire cette erreur qu'en production sur des serveurs occupés. Afin de faire un mini-vidage à chaque exception de la première chance (hé, ça se produit), le débogueur doit suspendre le processus de travail IIS suffisamment longtemps pour écrire un fichier de 16 meg. Les demandes sont donc mises en file d'attente et l'application devient instable. Parce que l’erreur peut prendre jusqu’à une heure, c’est problématique.
Donc, avec -NoDumpOnFirst, je reçois un fichier de vidage pour lequel WinDbg génère ces threads:
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
Essayer d'imprimer l'exception montre qu'il n'y a pas de trace de pile, et d'autres méthodes se plaignent d'être du code non managé. À mon avis, comme le dump est créé à la mort du processus, tous les threads ont été collectés et il ne reste aucune information à obtenir.
Je voudrais vraiment que le débogueur effectue un vidage complet à la première occasion de l'exception StackOverflowException et ignore tous les autres types d'exceptions. Je sais qu'ADPlus peut utiliser un fichier de configuration - http://msdn.microsoft.com /en-us/library/cc409304.aspx - mais le format m'est tout grec. Quelqu'un peut-il me montrer comment créer un script ADPlus qui le fera?
... bien sûr, si vous regardez la liste de fils ci-dessus et que vous savez exactement ce qui ne va pas, ou si vous pouvez le savoir si je vous donne plus d'informations, vous pouvez simplement me le dire aussi.
Tentative de résolution 1
Merci beaucoup pour la réponse ci-dessous, ce n’était pas tout à fait bien mais cela m’a poussé dans la bonne direction. Le code d'exception pour Stack Overflow était incorrect (c'est sbo not sov) (ou alors, je pensais à l'époque, voir les éditions de deemok ci-dessous), j'ai donc essayé de déboguer avec la configuration suivante:
<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>
Et en utilisant la commande suivante:
adplus -crash -o D:\Crash -NoDumpOnFirst -c D:\Crash\stackoverflow.cfg -iis
J'ai vérifié que les fichiers journaux sortis indiquaient la bonne configuration. L'astuce est que les paramètres de ligne de commande d'adplus sont exécutés dans l'ordre. Par conséquent, si vous commencez par une configuration qui intercepte les exceptions de la première chance, puis appliquez -NoDumpOnFirst, les paramètres de configuration seront écrasés. Si vous appliquez la configuration avec -c en dernier, ses paramètres l'emporteront.
Au final, toutefois, le débordement de pile s’est avéré impossible à rattraper. Le dépassement de capacité de la pile s’est produit, aucun vidage de mémoire n’a pu être reçu, puis un vidage s’est produit lors de l’événement de fin du processus de la deuxième chance. Une fois encore, tout avait été mis au rebut et je n’avais aucune information utile.
J'ai tenté de court-circuiter l'exception de fin de processus, au cas où cela impliquerait et surchargerait le débordement de pile, mais l'exception s'est produite et je n'ai reçu aucun vidage de mémoire.
Heureusement, je suis tombé sur la réponse en examinant le code. C’était bien sûr un cas d’appel à la méthode circulaire.
Résolution réelle
Le problème avait été résolu il y a longtemps, mais j'ai rapidement créé une page ASP.NET susceptible de provoquer un débordement de pile. (Ce n'est pas difficile à faire après tout) et j'ai essayé la réponse d'Axl ci-dessous.
Le code XML était légèrement en retrait - Axl a simplement oublié de fermer la balise </ADPlus>
(ou probablement perdu dans un copier-coller), mais cela a été assez facile à corriger et adplus a eu la gentillesse de me dire exactement ce qui n'allait pas. .
Je mets cette scriPointer contre mon lanceur de débordement de pile de test, chargé le résultat dans windbg, et quand j'ai appelé! clrstack, j'ai eu une liste très claire (et longue) des méthodes qui s'appelaient circulairement. Cela aurait trouvé le problème en un instant! Je garderai cette page dans mes favoris pour la prochaine fois qu'un débordement de pile viendra frapper à ma porte.
La solution
Au cas où cela pourrait aider quelqu'un d'autre, voici le ADPlus Le fichier de configuration que j'ai créé. En le regardant maintenant, je ne suis pas sûr que ça se produise! Attachée lorsqu'une application ASP.NET qui lève une exception StackOverflowException est en cours d'exécution, cela générera & "1ère chance StackOverflow plein &"; et " 1ère chance Processus Coupure complète " Fichiers .dmp dans le OutputDir spécifié. Ouvrez le premier fichier avec Windbg et exécutez & Quot. loadby sos mscorwks " suivi de "! clrstack " pour voir ce qui pourrait causer le débordement de la pile.
<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>
Autres conseils
<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>
Enregistrez cela dans stackoverflow.cfg
Ensuite, vous pouvez aller:
adplus -c stackoverflow.cfg
Modifier: sov et sbo sont des exceptions de débordement de pile. Je suppose qu’il faut expérimenter les deux car il n’est pas tout à fait clair pour moi de différencier les deux. ( sbo peut-il indiquer un appel alloca () non valide?)