调试诊断工具未在崩溃时生成转储 [英] Debug Diagnostic Tool not generating dumps on Crash

问题描述

服务器:Windows 2012r2调试诊断工具 v2.1 更新 1

Server: Windows 2012r2 Debug Diagnostic Tool v2.1 update 1

调试器附加到应用程序池.我已经确认它是该站点的正确池.池崩溃，但从未生成转储文件.

Debugger is attached to application pool. I've confirmed it's the correct pool for the site. Pool crashes, however a dump file is never generated.

应用程序池''由于一系列原因被自动禁用为该应用程序池提供服务的进程失败的次数."

"Application pool '' is being automatically disabled due to a series of failures in the process(es) serving that application pool."

规则只是简单地设置为查看应用程序池，而不是捕获第一次机会异常.我尝试删除并重新添加它几次，但它从未生成转储.

The rule is just simply set to look at the application pool, not capturing first chance exceptions. I've tried deleting and re-adding it a few times and it never generates the dump.

我检查了它生成的调试日志，这是在池崩溃之前生成的最后一个异常:

I checked the debug logs it generated and this is the last exception generated right before the pool crashes:

警告:帧 IP 不在任何已知模块中.以下帧可能是错误的.0x00x00x0

WARNING: Frame IP not in any known module. Following frames may be wrong. 0x0 0x0 0x0

想补充一点，转储确实为第一次机会异常生成.似乎只有在试图抓住第二次机会或实际导致崩溃的机会时才会出现问题.

Wanted to add that the dumps do generate for first chance exceptions. It seems to only be a problem when trying to capture the second chance, or the one that is actually causing the crash.

编辑 2:来自每个请求的调试日志之一的最后几行:

Edit 2: Last few lines from one of the debug logs per request:

[9/16/2015 7:21:31 PM]
  Exception 0XC00000FD on thread 154788.  DetailID = 48
  Thread created. New thread system id - System ID: 85156
  Thread exited. Exiting thread system id - System ID: 85156. Exit code - 0x00000000
  Thread exited. Exiting thread system id - System ID: 326816. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 41368. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 213340. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 300224. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 51008. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 45288. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 75176. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 143512. Exit code - 0x800703e9
  Thread exited. Exiting thread system id - System ID: 68504. Exit code - 0x800703e9
....... (goes on like this for awhile)
Process exited. Exit code - 0x800703e9

异常与此相关

DetailID = 48
    Count:    1
    Exception #:  0XC00000FD
    Stack:        

        WARNING: Frame IP not in any known module. Following frames may be wrong.
        0x0
        0x0
        0x0
        0x0
        0x0

推荐答案

默认情况下，debugdiag 崩溃规则仅对所有未处理的第二次机会异常进行转储(如果您创建崩溃规则并将所有设置保留为默认值)，因此如果不会生成转储，则进程不会因第二次机会异常而崩溃.

By default the debugdiag crash rule takes dumps for all the unhandled second chance exceptions only (if you create a crash rule and leave all settings to default) so if the dumps are not getting generated then the process is not crashing with a 2nd chance exception.

CLR 有时会在遇到致命异常(堆栈溢出就是其中之一)时调用 TerminateProcess 函数.因此，如果您的进程因这些异常而崩溃，那么您将不会使用默认规则进行转储，您应该更改规则以包含默认断点列表中存在的 ntdll terminateprocess 断点.启用此断点的不良影响是，现在即使是安全退出(如工作进程空闲关闭、回收等)，您也会获得转储，因此您需要检查记录的事件的时间戳并将转储文件与...

At times CLR calls TerminateProcess function when it encounters fatal exceptions (stack overflow being one of them). So if your process is crashing with these kind of exceptions then you won't get dumps using the default rule and you should change the rule to include the ntdll terminateprocess breakpoint which is present in the default breakpoint list. The bad effect of enabling this breakpoint is that now you get dumps even for SAFE EXITS (like worker process idle shutdowns , recycles etc.) so you need to check the time stamp of the event logged and match the dump file with that...

如果您在 debugdiag 为 w3wp.txt 生成的文本文件中粘贴您看到的最后 5-10 行，将会有所帮助.

It would help if you paste the last 5-10 lines of what you see in the text files generated by debugdiag for w3wp.txt.

添加我在调试器中看到的调用堆栈...

0:065> kL 50
# ChildEBP RetAddr  
00 1a8f291c 74b80947 ntdll!NtTerminateProcess
01 1a8f292c 73e0843d KERNELBASE!TerminateProcess+0x23
02 1a8f29b8 73e07d03 clr!EEPolicy::HandleFatalStackOverflow+0x1ba
03 1a8f29e8 73dca49f clr!EEPolicy::HandleStackOverflow+0x1ac
04 1a8f2a0c 76f500b1 clr!COMPlusFrameHandler+0x9b
05 1a8f2a30 76f50083 ntdll!ExecuteHandler2+0x26
06 1a8f2afc 76f507ff ntdll!ExecuteHandler+0x24
07 1a8f2afc 17732c83 ntdll!KiUserExceptionDispatcher+0xf
08 1a8f309c 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x1b
09 1a8f3184 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
0a 1a8f326c 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
0b 1a8f3354 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
0c 1a8f343c 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
0d 1a8f3524 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
0e 1a8f360c 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
0f 1a8f36f4 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c
10 1a8f37dc 17733104 App_Web_lotdetail_aspx_cdcab7d2_hoxucj_s!Unknown+0x49c

这篇关于调试诊断工具未在崩溃时生成转储的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！