如何使用WinDbg分析崩溃转储

我刚刚在Windows 7中的IIS 7.5中关闭了应用程序池，因为我认为5分钟的时间内有5个stackoverflow。如何使用WinDbg分析崩溃转储

下面是对关闭的说明：由于服务该应用程序池的进程中存在一系列故障，因此应用程序池“我的软件AppPool”正被自动禁用。

使用WinDbg，我运行了命令'！analyze -v'，并提出了下面的异常分析。它似乎与System.Net.Mail.SmtpClient.Send有关，但这似乎没有道理。

任何想法都会很棒！谢谢。

FAULTING_IP: 
clr!StrongNameErrorInfo+4f94d 
000007fe`f9d265ed 4889842498000000 mov  qword ptr [rsp+98h],rax 

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) 
ExceptionAddress: 000007fef9c20e8f (clr!CoUninitializeEE+0x000000000000d14f) 
    ExceptionCode: c00000fd (Stack overflow) 
    ExceptionFlags: 00000001 
NumberParameters: 2 
    Parameter[0]: 0000000000000001 
    Parameter[1]: 0000000004c65f88 

PROCESS_NAME: w3wp.exe 

FAULTING_MODULE: 0000000077230000 ntdll 

DEBUG_FLR_IMAGE_TIMESTAMP: 5073c71b 

ERROR_CODE: (NTSTATUS) 0xc00000fd - A new guard page for the stack cannot be created. 

EXCEPTION_CODE: (NTSTATUS) 0xc00000fd - A new guard page for the stack cannot be created. 

EXCEPTION_PARAMETER1: 0000000000000001 

EXCEPTION_PARAMETER2: 0000000004c65f88 

RECURRING_STACK: From frames 0xd to 0x4b 

MOD_LIST: <ANALYSIS/> 

MANAGED_STACK: 
    SP    IP    Function 
    0000000004C71DF0 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004C7A560 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004C82CD0 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004C8B440 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004C93BB0 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004C9C320 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CA4A90 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CAD200 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CB5970 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CBE0E0 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CC6850 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CCEFC0 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 
    0000000004CD7730 000007FEF87B5C77 System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7 

MANAGED_STACK_COMMAND: !do 0000000000000000 


LAST_CONTROL_TRANSFER: from 000007fef9cc9dda to 000007fef9c20e8f 

ADDITIONAL_DEBUG_TEXT: 
Use '!findthebuild' command to search for the target build information. 
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols. ; Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD] 

FAULTING_THREAD: ffffffffffffffff 

BUGCHECK_STR: APPLICATION_FAULT_STACK_OVERFLOW_WRONG_SYMBOLS_CALL 

PRIMARY_PROBLEM_CLASS: STACK_OVERFLOW_CALL 

DEFAULT_BUCKET_ID: STACK_OVERFLOW_CALL 

STACK_TEXT: 
00000000`04c71df0 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04c7a560 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04c82cd0 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04c8b440 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04c93bb0 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04c9c320 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04ca4a90 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04cad200 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04cb5970 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04cbe0e0 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04cc6850 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04ccefc0 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 
00000000`04cd7730 00000000`ffffffff system_ni!System.Net.Mail.SmtpClient.Send+0x216fe7 


SYMBOL_NAME: system_ni!System.Net.Mail.SmtpClient.Send 

FOLLOWUP_NAME: MachineOwner 

MODULE_NAME: system_ni 

IMAGE_NAME: System.ni.dll 

STACK_COMMAND: !do 0000000000000000 
; ** Pseudo Context ** ; kb 

BUCKET_ID: WRONG_SYMBOLS 

FAILURE_BUCKET_ID: STACK_OVERFLOW_CALL_c00000fd_System.ni.dll!System.Net.Mail.SmtpClient.Send 

WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/w3wp_exe/7_5_7600_16385/4a5bd0eb/clr_dll/4_0_30319_296/50483916/c00000fd/00010e8f.htm?Retriage=1 

Followup: MachineOwner 
---------

来源

2014-02-05 localman

+ 0x216fe7的偏移量太大。您的符号不正确，因此方法名称也不可靠。你使用'.symfix c：\ symbols'并且你有互联网接入吗？ –

错误代码说明了有关防护页的一些内容。您是否为W3WP.exe启用GFlags？ –

感谢您的反馈。我没有启用警戒页面。 – localman

您从！analyze -v得到的堆栈看起来不可靠。堆栈中的所有功能都相同：“System_ni System.Net.Mail.SmtpClient.Send（System.Net.Mail.MailMessage）+ 0x216fe7！”

除非你打一个无限递归，该函数内！？

我的2美分 a。请加载符号对于堆流溢出异常，故障堆栈通常指向罪魁祸首。但如果没有符号，这将是非常困难的。 b。看看所有线程的堆栈。你可能会得到更多的指示。

来源

2014-02-07 07:28:29 Player

谢谢Amitkun。它实际上是一个无限递归 - 从认证问题流入。 – localman

我在事件查看器中发现了另外一个条目，它揭示了这一点。在这一点上，我怀疑它与smtp不是来自经过验证的地址有关 - 这实际上与它试图打电话的问题有关。

不是一个具体的答案，关于解释上述日志，但应该是解决我的问题。

谢谢托马斯。

来源

2014-02-06 00:41:02 localman

如何使用WinDbg分析崩溃转储

回答

相关问题