0

I've been searching for a while and finding many old articles but also found one with a Regedit to enable the dumping of .dmp files, which isn't doing it.

Instructions I used are from Microsoft, Collecting User-Mode Dumps (MSDN)

According to Symantec no re-boot is required.

I created it for both: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\Windows Error Reporting\LocalDumps and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.

All I get is a report.wer file. No dump. The event log is writing exceptions about every minute and about every 30 minutes the app pool dies, so I'm trying to get the details on where the problem is coming from.

Anyone know why those keys aren't working? Does the report.wer provide anything useful for me? One StackOverflow post said SOS extension and when I search for it Microsoft points me to download WinDbg which I already installed. A lot of instructions I find from 2008 and older seem out-dated.

Edit: I managed to get dump files by running the debugging tool on the server. But there's so much wrong information out there on how to get the actual code info that none of it is working.

I've tried adding the symbols path to my pdb files and I've tried

  • .loadby sos clr
  • .loadby sos
  • !CLRStack
  • !analyze -v

and all I get is wrong symbols.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
GregInWI2
  • 904
  • 1
  • 17
  • 26

1 Answers1

0

WER won't catch crash dumps if there is no crash at all. You know that a process can exit normally, when you think it crashes.

If you do want to learn why a process exits (normally or abnormally), the most reliable way I can think of is to utilize Debug Diag (which is built specifically for IIS),

http://msdn.microsoft.com/en-us/library/ff420662.aspx

Note that you probably should use Debug Diag 2.0 at this moment, and must add Kernel32!ExitProcess and Kernel32!TerminateProcess as breakpoints.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • That's the tool that I'm using to get dumps. But when I run the analyze all I get is a list of DLLs and an error message: the assembly instruction at KERNELBASE!RaiseException+58 in C:\Windows\SysWOW64\KERNELBASE.dll from Microsoft Corporation has caused a CLR Exception on thread 50 with the following error information: Type: NOT_FOUND Message: NOT_FOUND. – GregInWI2 Mar 26 '14 at 12:20
  • I mean Windows function calls, not DLLs. I'm certain it's something in my code and I remember having to do this 2 1/2 years ago and somehow I was able to see the line of code causing the problem. So far I haven't been able to, I just get useless info from it, which isn't helping. – GregInWI2 Mar 26 '14 at 12:43
  • For managed dumps symbols are less important. `.loadby sos clr` is for .NET 4 dumps, so are you using .NET 4? After loading sos all you need to do is to run `!pe`. Don't read too many articles which only puzzle you more. – Lex Li Mar 26 '14 at 14:53
  • Yeah, it's a .NET 4 site. I tried !pe an two dump files and the first could be the cause. The second I think is a result of the first. I think I need more dump files to know for sure. The first was "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full" and the second was a thread being aborted. I'm gonna get more dump files and see what they say. – GregInWI2 Mar 26 '14 at 16:14
  • I didn't have 2.0 but do now. When I add Kernel32!ExitProcess and Kernel32!TerminateProcess the rule won't run. Error is "Error due to unresolved breakpoint". So I've been checking all dumps, hence the thread aborts. I wonder if I should have installed the 32bit version of the Debug tool. – GregInWI2 Mar 26 '14 at 17:53
  • I think I've resolved my problem. Using Debug Diagnostics Tool 2.0 I was able to generate a report on one of the crash dumps that showed me methods in my code. I've fixed the issue and crashing seems to have stopped. Your posts definitely helped. – GregInWI2 Mar 26 '14 at 19:27