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.
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.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments