记一次 .NET某工业设计软件 崩溃分析
原文中文，约7700字，阅读约需19分钟。
📝
内容提要
本文讲述了作者在调试软件崩溃问题时的经历，通过使用WinDbg分析崩溃日志，发现崩溃是由于执行自身代码时抛出了灾难性异常导致的。进一步分析发现，异常是由于一个接口Stub调用的崩溃引起的。作者提出了三个解决办法：预热接口方法、隔离托管C++和C#、重点观察多Domain下的托管调用。最后总结说，多Domain和托管C++混合编程的问题很难解决。
🎯
关键要点
-
作者通过WinDbg分析软件崩溃问题，发现崩溃源于CLR执行自身代码时抛出灾难性异常。
-
崩溃的根本原因是接口Stub调用导致的，具体是由于this指针为null。
-
分析CLR源代码后发现，问题出在VirtualCallStubManager的FindStubManager方法返回null。
-
在托管层面，使用反射实现功能增强，导致接口调用出现问题。
-
程序使用多AppDomain和托管C++混合编程，增加了调试的复杂性。
-
作者提出三种解决办法：预热接口方法、隔离托管C++和C#、观察多Domain下的托管调用。
-
总结认为，多Domain和托管C++混合编程的问题难以解决。
❓
延伸问答
如何使用WinDbg分析软件崩溃问题？
使用WinDbg可以通过分析崩溃日志，观察线程状态和调用栈，定位崩溃原因。
导致软件崩溃的根本原因是什么？
崩溃的根本原因是接口Stub调用导致的，具体是由于this指针为null。
作者提出了哪些解决办法来应对崩溃问题？
作者提出了三种解决办法：预热接口方法、隔离托管C++和C#、观察多Domain下的托管调用。
多Domain和托管C++混合编程有什么问题？
多Domain和托管C++混合编程的问题很难解决，增加了调试的复杂性。
在调试过程中，如何确认this指针为null的原因？
需要查看CLR源代码，分析VirtualCallStubManager的FindStubManager方法，确认pMgr为null。
使用反射实现功能增强时可能出现什么问题？
使用反射可能导致接口调用出现问题，从而引发崩溃。
🏷️
