6

On the main production server, the IIS worker process crashes sometimes. From the event viewer I get the following information.

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8 Faulting module name: KERNELBASE.dll, version: 6.1.7601.17651, time stamp: 0x4e211319 Exception code: 0xe053534f Fault offset: 0x0000b9bc Faulting process id: 0x%9 Faulting application start time: 0x%10 Faulting application path: %11 Faulting module path: %12 Report Id: %13

This happens randomly on the prod server and I have not been able to recreate this crash anywhere else. This was happening on IIS 6, and we recently moved to Windows Server 2008 and IIS 7.5 and the crash happens there as well.

How to go about finding the root cause of this?

shashi
  • 163
  • 1
  • 1
  • 5

3 Answers3

7

A step-by-step guide is included here from Tess Ferrandez's blog:

https://blogs.msdn.com/b/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx

Essentially, you will setup DebugDiag 1.2 x64 to trigger on that exception code, and create a full userdump. After the dump is created, you can use DebugDiag to analyze the dump for you. Although with that particular exception, you probably need to use WinDbg+SOS.

Some of the more relevant information:

"For stack overflows as most of you probably know, the most common reason is that we are in some type of recursive loop, so what we really would like to know here is what is on this stack… The reason why it is showing up with just addresses and not method names, is because debug diag doesn’t understand .net so we’ll have to bring the dump to windbg to analyze it and check out the .net stack.

"In windbg we can then load up sos (.loadby sos mscorwks) and run !clrstack on the active stack to get the callstack."

(If you are running .NET 4, the command to load sos is: .loadby sos clr)

Ultimately, what you are looking for is the offending code in your application that is causing the recursion. The method names that appear in WinDbg when SOS is loaded will probably get you pointed in the right direction.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
3

Get ProcDump and configure it to generate dumps when w3wp.exe processes crash. Once you have a dump inspect it with Visual Studio or Windbg.

friism
  • 498
  • 2
  • 14
0

I had the same problem. In my code I had the following line of vb.net code

Dim mPath as string = Environment.GetFolderPath(Environment.SpecialFolder.Desktop)

My whole ASP.NET crashed, because it can't access this folder at runtime. Errorhandling doesn't work. Clr simply crashes.

Replacing this line by an existing directory solved my problem.

Sven
  • 97,248
  • 13
  • 177
  • 225
mark stulens
  • 11