How to debug: w3wp.exe process was terminated due to a stack overflow (works on one machine but not another)

Question

The problem
I have an ASP.NET 4.0 application that crashes with a stack overflow on one computer, but not another. It runs fine on my development enviro

Answer 1

A default stack limit for w3wp.exe is a joke. I always raise it with editbin /stack:9000000 w3wp.exe, it should be sufficient. Get rid of your stack overflow first, and then debug whatever you want.

Answer 2

One possibility for your application behaving differently in production vs development could be preprocessor directives like #if DEBUG in the code. When you deploy to production the release build would have different code segments than your debug build.

Another option would be that your application is throwing an unrelated exception in production. And the error handling code somehow ends up in an infinite function calling loop. You may want to look for an infinite loop that has a function call to itself or another function that calls this function back. This ends up in an infinite function callig loop because of the infinite for or while loop. I apologize for going overboard with the word 'infinite'.

It's also happened to me before when I accidentally created a property and returned the property inside my property. Like:

public string SomeProperty { get { return SomeProperty; } }

Also, if possible you could do special stuff with the exception in the Application_error function of your global.asax. Use server.getlasterror() to get the exception and log/display the stack trace. You may want to do the same for any innerexceptions or innerexceptions of innerexceptions and so on.

You may already be doing the above mentioned things but I wanted to mention them just in case.

Also, from your trace it looks like the error is happening in GetSortKey. Is that a function in your code? If so, then your infinite self calling may start there.

Hope this helps.

Answer 3

This question is a bit old, but I just found a nice way of getting the stack trace of my application just before overflowing and I would like share it with other googlers out there:

1. When your ASP.NET app crashes, a set of debugging files are dumped in a "crash folder" inside this main folder:

   C:\ProgramData\Microsoft\Windows\WER\ReportQueue

2. These files can be analysed using WinDbg, which you can download from one of the links below:

   • Windows WinDbg x86 installer
   • Windows WinDbg x64 installer

3. After installing it in the same machine where your app crashed, click File > Open Crash Dump and select the largest .tmp file in your "crash folder" (mine had 180 MB). Something like:

   AppCrash_w3wp.exe_3d6ded0d29abf2144c567e08f6b23316ff3a7_cab_849897b9\WER688D.tmp

4. Then, run the following commands in the command window that just opened:

   .loadby sos clr
   !clrstack
   

5. Finally, the generated output will contain your app stack trace just before overflowing, and you can easily track down what caused the overflow. In my case it was a buggy logging method:

   000000dea63aed30 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
   000000dea63aedd0 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
   000000dea63aee70 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
   000000dea63aef10 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
   000000dea63aefb0 000007fd88de9d00 Library.Logging.RepositoryLogger.Error(System.Object, System.Exception)
   000000dea63af040 000007fd88de9ba0 Library.WebServices.ErrorLogger.ProvideFault(System.Exception, System.ServiceModel.Channels.MessageVersion, System.ServiceModel.Channels.Message ByRef)
   

Thanks to Paul White and his blog post: Debugging Faulting Application w3wp.exe Crashes

Answer 4

Two things I would try before analysing any memory dumps.

1. Install the remote debugging tool on the web server and try debugging that way. You can find this tool on the Visual Studio install DVD.
2. Install Elmah. Elmah can be added to a running ASP.NET application for logging and debugging. I would probably go with this option first and it's the least painful approach. http://code.google.com/p/elmah/

Answer 5

Get a crash dump, run it against Microsoft's Debug Diagnostic Tool and show us the result.

Also take a look at http://support.microsoft.com/kb/919789/en-us, which explains all the necessary steps in detail.