views:

46

answers:

2

I've run into a particularly nasty bug where an ASP.NET website attempts to make a call to a WCF service method that sends IIS into a death spiral...that ultimately brings down the associated app pool. It never gets to our log4net code that outputs unhandled exceptions.

I was watching w3wp.exe processes spin up and die, so I figured I'd take a dump file on termination using ProcDump from SysInternals using the following command:

procdump -e -t -ma <PID> aspnet.dmp

This gets me a minidump file, which I can open up in VS2010, and it shows me that the heap information is present. Which is exciting:

Minidump Summary

So at this point I attempt to set the symbol path, which is the bin folder for that particular website. I've copied it down from the appropriate server. However, I still only get the option to Debug with Native Only, and when I do that it can't find any of the appropriate symbols.

Here's my PDB location setup:

PDB Options

I'm not sure if that's because the call stack seems to stop somewhere in a Windows DLL...? Here's a screen of the call stack window.

Call Stack

Anyway, my ultimate question is whether or not I'm following the appropriate path for finding the source of this exception, and, if so, what am I missing? It appears to be in unmanaged code but I'd still love to see the last managed call before everything explodes.

Also, in case it's helpful, the web server is Win2003 x86, my PC is Win7 x64.

Thanks!

+1  A: 

I always prefer winDbg for analyzing dumps. Also, I would suggest that you look into Debug Diags from MSFT. This is a windows service that will monitor your app and create the dump right before the crash. This will make sure that your dump has the information that you need. Once you have the dump, Load it into WinDbg and use the tools in the SOS extension DLL to find your problem.

Mike
I agree all the literature I came across was very SOS-heavy and apparently that's a very accepted way to go. I'm interested though in how to get VS2010 to make this a less painful process.
Brandon Linton
+1  A: 

I came across this too. VS2010 won't do the nice, friendly debugging of a dumpfile of a managed app unless it was a .NET 4.0 executable assembly that crashed.

stimpy77