一线码农
·
记一次 .NET某工业设计软件 崩溃分析 - 一线码农
💡
原文中文，约6800字，阅读约需16分钟。
📝
内容提要
文章讨论了软件崩溃的问题，分析了崩溃原因与CLR中的ExecutionEngineException异常。通过使用windbg工具，定位到崩溃发生在接口Stub调用中，发现this指针为null，导致异常。文章还提到多AppDomain和托管C++混合编程可能导致的问题，并提出了几种解决方案。
🎯
关键要点
- 软件崩溃的原因可能与CLR中的ExecutionEngineException异常有关。
- 使用windbg工具分析崩溃时，发现崩溃发生在接口Stub调用中，this指针为null。
- 崩溃的根本原因是VirtualCallStubManager::FindStubManager方法返回的pMgr为null。
- 多AppDomain和托管C++混合编程可能导致复杂的问题，增加了调试的难度。
- 提出的解决方案包括预热接口方法、隔离托管C++与C#的混合编程，以及观察多Domain下的托管调用问题。
❓
延伸问答
软件崩溃的主要原因是什么？
软件崩溃的主要原因是CLR中的ExecutionEngineException异常，具体是由于接口Stub调用时this指针为null导致的。
如何使用windbg工具分析软件崩溃？
使用windbg工具分析崩溃时，可以通过命令如!t和!analyze -v来观察线程状态和异常信息。
什么是VirtualCallStubManager，它在崩溃中起什么作用？
VirtualCallStubManager是用于管理虚调用的组件，崩溃中它的FindStubManager方法返回null，导致this指针为null。
多AppDomain和托管C++混合编程会带来哪些问题？
多AppDomain和托管C++混合编程会增加调试的复杂性，可能导致难以定位的崩溃问题。
针对软件崩溃，有哪些解决方案？
解决方案包括预热接口方法、隔离托管C++与C#的混合编程，以及观察多Domain下的托管调用问题。
如何定位崩溃发生的具体位置？
可以通过windbg分析调用栈和汇编代码，观察this指针和相关方法的执行情况来定位崩溃位置。
➡️
