How to analyze Crash Dump using WinDbg

Question

I've just had the app pool shut down in IIS 7.5 in Windows 7, because of what I think are 5 stackoverflows over the space of 5 minutes.

Here's the explanation for the shut down: Application pool 'My Softwares AppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.

Using WinDbg, I ran the command '!analyze -v', and came up with the exception analysis below. It appears to have something to do with System.Net.Mail.SmtpClient.Send, but that doesn't seem to make sense.

Any ideas would be awesome! thx.

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
---------

Answer 1

The stack that you get from !analyze -v does not look reliable. All the functions in the stack are same : 'System_ni!System.Net.Mail.SmtpClient.Send(System.Net.Mail.MailMessage)+0x216fe7'

Unless you are hitting an infinite recursion, within that function! ?

My 2 cents a. Please load symbols For stack over flow exceptions the faulting stack it self generally points to the culprit. But without symbols it will be very difficult to make out. b. Take a look at the stack of all threads. You may get some further pointers.

Answer 2

I found another entry in the event viewer that shed some light on this. At this point, I suspect it has something to do with smtp not being from an authenticated address - which is actually related to an issue of it try to make the call too often.

Not a specific answer, about interpreting the above log, but should be the resolution to my issue.

Thanks Thomas.