我收到了我们在应用程序中看到的堆栈溢出异常的跟踪转储。我们最终在不使用跟踪转储的情况下发现了问题,但我很好奇:
将来如何使用线程的跟踪转储来更快地诊断问题?
我知道函数名称后面的十六进制数字是编译代码中的某种偏移量。我不知道底部五行中的四行是什么意思(以 0x 开头的那些)。我假设这是指我们应用程序代码中的一个位置;如果是,有没有办法确定该行在应用程序中的位置?
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
注意:我不是在寻求调试此特定问题的帮助,而是在我所拥有的只是源代码和跟踪转储的情况下如何使用这样的东西来调试未来的问题。
仅凭堆栈跟踪,您可能不会走得太远。前 5 行是堆栈帧,但由于缺少符号,可能没有上下文。
如果跟踪转储是指内存转储,则有几个调试选项。
1)你可以在Visual Studio中打开转储 - 可能是最简单的 - 看这里:http://msdn.microsoft.com/en-us/library/d5zhxt22.aspx
2) 您可以使用 WinDBG 打开转储有一点学习曲线,但这是一项巧妙的技能。我总是向人们指出苔丝的博客来增加这一点。这些帖子很旧,但仍然相关:http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx
如果我收到这个堆栈跟踪,我就不会浪费大量时间试图确定它的含义。我会重现该问题并捕获故障转储,并使用上述技术之一来确定根本原因。