如何在不链接源代码的情况下调试System.StackOverflowException? [英] How to debug System.StackOverflowException without link to source code?

问题描述

最近，我经常遇到

类型为'System.StackOverflowException'的未处理异常发生在未知模块中.".

"An unhandled exception of type 'System.StackOverflowException' occurred in Unknown Module.".

这种情况发生在我开发的具有相当大的代码库(C#/XNA)的游戏中.但通常只有在玩了几分钟后才会出现错误(并非每次运行都发生).

This happens in a game (that I developed) with a quite large code base (C# / XNA). But typically the error occurs only after several minutes of gameplay (and not in every run).

问题是，不幸的是，Visual Studio调试器似乎无法进一步定位该问题，只是让我检查了汇编代码而不参考源代码行.一个人如何调试这样的错误?我想像Valgrind这样的工具在C#中不可用.也许有更好的调试器可以向我显示问题在源代码中的位置吗?

The problem is that unfortunately, the Visual Studio debugger seems to not be able to further localize the problem and just lets me inspect the assembler code without reference to my source lines. How could one debug such an error? I guess tools like Valgrind are not available in C#. Is there maybe a better debugger that can show me where the problem is localized in the source code?

应用下面建议的答案中的步骤时可用的调用堆栈.它是:

The call stack available when applying the steps in the suggested answer below. It is:

ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes 
ntdll.dll!_NtWaitForSingleObject@12()  + 0x15 bytes 
KernelBase.dll!_WaitForSingleObjectEx@12()  + 0xcb bytes    
kernel32.dll!_WaitForSingleObjectExImplementation@12()  + 0x43 bytes    
clr.dll!CLREvent::CreateManualEvent()  - 0x15f3bb bytes 
clr.dll!CLREvent::CreateManualEvent()  - 0x15f37a bytes 
clr.dll!CLREvent::WaitEx()  + 0x47 bytes    
clr.dll!CLREvent::Wait()  + 0x19 bytes  
clr.dll!Thread::WaitSuspendEventsHelper()  + 0xa8 bytes 
clr.dll!Thread::WaitSuspendEvents()  + 0x17 bytes   
clr.dll!Thread::RareEnablePreemptiveGC()  + 0x181977 bytes  
clr.dll!Thread::RareDisablePreemptiveGC()  + 0x38e3 bytes   
clr.dll!Debugger::SendException()  + 0x12b bytes    
clr.dll!Debugger::LastChanceManagedException()  + 0x19f bytes   
clr.dll!NotifyDebuggerLastChance()  + 0x79 bytes    
clr.dll!WatsonLastChance()  + 0x166 bytes   
clr.dll!EEPolicy::HandleFatalStackOverflow()  + 0x189 bytes 
clr.dll!EEPolicy::HandleStackOverflow()  + 0xd8 bytes   
clr.dll!_COMPlusFrameHandler()  + 0xff302 bytes 
ntdll.dll!ExecuteHandler2@20()  + 0x26 bytes    
ntdll.dll!ExecuteHandler@20()  + 0x24 bytes 
ntdll.dll!_RtlDispatchException@8()  + 0xd3 bytes   
ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xf bytes   
clr.dll!SystemNative::ArrayCopy()  + 0x19 bytes 
mscorlib.ni.dll!6ed326a2()  
Frames below may be incorrect and/or missing, no symbols loaded for mscorlib.ni.dll 

推荐答案

如果ntdll.dll发生崩溃，则需要使用符号，但我认为更可能的原因是您传递了一些奇怪的信息里面的垃圾会导致它崩溃.您是否正在进行可能导致其崩溃的Windows API调用?

If the crash is happening with ntdll.dll, you'd need the symbols for it, but I think the more likely possibility is that you are passing some weird junk in that is causing it to crash. Are you making an Windows API calls that might be crashing it?

另一种可能性，另一个用户在这里提到的是，您可能正在耗尽堆栈的某个地方进行递归调用.如果要对非托管代码段进行调用，这将尤其成问题:

Another possibility, which was mentioned by another user here is that you could be making a recursive call somewhere that is running out the stack. This would be especially problematic if the calls are being made to unmanaged pieces of code:

• 是否存在任何可能导致无限循环的逻辑条件?
• 是否有进行无意递归调用的构造函数?
• 您的代码中是否有任何可能卡住的递归方法?

此外，在尝试寻找另一种调试方法之前，您可能还需要尝试以下几件事:

Also, a couple of things you may want to try before you go down the road for looking for an alternative way to debug:

1. 确保项目是在调试中构建的
2. 检查Visual Studio设置以确保它在所有异常情况下均停止运行
3. 如果项目设置中提供了仅我的代码"设置，则将其关闭(这甚至会显示在C#项目中吗?)
4. 打开混合模式调试/非托管调试
5. 确保正在生成符号并将其存储在正确的位置(* .pdb)
6. 如果所有操作失败，则可以在系统事件查看器中四处浏览并查找任何奇怪的错误

这篇关于如何在不链接源代码的情况下调试System.StackOverflowException?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！