c# - 如何在没有源代码链接的情况下调试 System.StackOverflowException？

Question

最近经常遇到类型错误

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

这发生在(我开发的)具有相当大的代码库 (C#/XNA) 的游戏中。但通常错误只会在玩游戏几分钟后发生(而不是每次运行时)。

问题是，不幸的是，Visual Studio 调试器似乎无法进一步定位问题，只是让我在不引用源代码行的情况下检查汇编代码。如何调试这样的错误？我猜像 Valgrind 这样的工具在 C# 中不可用。是否有更好的调试器可以告诉我问题在源代码中的位置？

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

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 

Answer 1

如果崩溃发生在 ntdll.dll 上，您需要它的符号，但我认为更有可能的是您传递了一些导致它崩溃的奇怪垃圾。您是否在进行可能导致其崩溃的 Windows API 调用？

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

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

此外，在寻找替代调试方法之前，您可能还想尝试一些事情:

1. 确保项目是在调试中构建的
2. 检查 Visual Studio 设置以确保它在所有异常时停止
3. 如果“仅我的代码”设置在您的项目设置中可用，请将其关闭(这甚至会出现在 C# 项目中吗？)
4. 开启混合模式调试/非托管调试
5. 确保生成符号并将其存储在正确的位置 (*.pdb)
6. 如果所有这些都失败了，您可以在系统事件查看器中四处寻找并查找任何奇怪的错误