CODEWITHSUNDEEP
.netdebuggingstack-trace
Charles H.
Charles H.

Reputation: 273

How to use a stack trace dump to debug an exception?

I received a trace dump of a stack overflow exception we were seeing in our application. We eventually found the problem without using the trace dump, but I am curious:

How can I use the trace dump of a thread in the future to more quickly diagnose an issue?

I understand that the hexadecimal numbers after a function name is some kind of offset in the compiled code. I do not know what four of the bottom five lines mean (the ones that start with 0x). I've assumed that that is referring to a location in our application's code; if it is, is there a way to determine where that line comes from in an application?

ntdll!ZwTerminateProcess  
KERNELBASE!TerminateProcess+2c  
clr!EEPolicy::HandleFatalStackOverflow+1c9  
clr!EEPolicy::HandleStackOverflow+1ac  
clr!COMPlusFrameHandler+9b  
ntdll!ExecuteHandler+26  
ntdll!ExecuteHandler+24  
ntdll!RtlDispatchException+127  
ntdll!KiUserExceptionDispatcher+f  
//Cut 40 lines here...  
clr!MethodDesc::DoPrestub+59d  
clr!ReflectionInvocation::CompileMethod+54  
mscorlib_ni+393a09  
mscorlib_ni+34e3bc  
System_Core_ni+1bf152  
System_Core_ni+1bb05e  
System_Core_ni+3d0f57  
0x2413854b  
0x23df1ad3  
clr!ArrayNative::ArrayCopy+3ce  
0x20e680b9  
0x20e61c65

Note: I'm not asking for help in debugging this specific issue, but how I can use something like this to debug future problems when all I have is the source code and a trace dump.

Upvotes: 2

Views: 1268

Answers (1)

Dan Gartner
Dan Gartner

Reputation: 922

With just that stacktrace alone, you're probably not going to get very far. Those first 5 lines are stackframes, but there is no context likely due to lack of symbols.

If by trace dump, you mean memory dump, then you have a few options for debugging.

1) You can open the dump in Visual Studio - probably the easiest -- see here: http://msdn.microsoft.com/en-us/library/d5zhxt22.aspx

2) You can open the dump using WinDBG There's a bit of a learning curve, but it is a neat skill to have. I always point folks to Tess's blog to ramp on this. The posts are old, but still relevant: http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx

If I were handed this stacktrace, I wouldn't waste a ton of time trying to determine what it means. I'd repro the issue and capture a crash dump and use one of the techniques above to determine root cause.

Upvotes: 4

Related Questions