记一次 .NET 某CRM物流行业管理系统 崩溃分析
💡
原文中文，约6400字，阅读约需16分钟。
📝
内容提要
一位朋友在Linux上运行的.NET程序崩溃，分析dump文件发现崩溃源于终结器线程调用析构函数时，_nativeAssemblyLoadContext为null，导致访问违例。建议使用using替代终结器，以避免严重后果。
🎯
关键要点
- 朋友在Linux上运行的.NET程序崩溃，原因不明。
- 使用procdump抓取dump文件进行分析。
- 崩溃原因是SIGSEGV信号，表示段错误，_nativeAssemblyLoadContext为null导致访问违例。
- 终结器线程调用AssemblyLoadContext的析构函数时出现问题。
- 建议使用using替代终结器，以避免程序崩溃。
- 提供两种解决方案：1) 使用using替代兜底线程，2) 使用harmony进行实时跟踪。
- 总结警示：能用using就不要依赖终结器线程，避免灾难性后果。
❓
延伸问答
为什么.NET程序在Linux上会崩溃？
崩溃是由于终结器线程调用析构函数时，_nativeAssemblyLoadContext为null，导致访问违例。
如何分析.NET程序崩溃的dump文件？
可以使用procdump抓取dump文件，然后在Visual Studio中打开进行分析。
崩溃时的SIGSEGV信号表示什么？
SIGSEGV信号表示段错误，通常是由于访问了无效的内存地址。
如何避免.NET程序崩溃？
建议使用using语句替代终结器，以避免依赖终结器线程导致的崩溃。
在崩溃分析中，_nativeAssemblyLoadContext为何会为null？
_nativeAssemblyLoadContext为null可能是由于InitializeAssemblyLoadContext函数未正确赋值。
使用harmony进行实时跟踪有什么好处？
使用harmony可以在出现_nativeAssemblyLoadContext为null时，实时获取调用栈信息，便于调试。
➡️
