.NET服务GC终结器崩溃 DestroyScout析构访问违例问题排查

• DestroyScout是.NET Framework反射发射（Reflection.Emit）模块的内部清理类，它析构时调用RuntimeMethodHandle.Destroy(m_methodHandle)要销毁的目标，是动态生成方法对应的非托管资源：包括动态方法编译后生成的x86机器码内存页、IL元数据、异常处理表、JIT编译信息等，这些资源分配在CLR非托管堆上，不归GC托管堆直接管理，必须手动触发释放。

• 你遇到的是动态方法非托管资源生命周期管理的竞态bug，Dump里记录的异常码0xC0000005（内存访问违例）出在GC终结器线程，说明GC执行清理时，持有的m_methodHandle已经是野指针：要么对应的非托管内存已经被其他路径提前释放，要么指向的内存已经被回收覆写，属于非托管资源重复释放类问题。
• 对照你贴出的DestroyScout源码，它在执行销毁前做了两层校验：判断句柄是否为空、判断持有方法引用的托管DynamicResolver对象是否存活。但这两层校验在x86架构、CLR 4.7.3920.0版本下存在明确的竞态时间窗口：
  • 校验通过的瞬间，DynamicResolver可能已经被GC回收，非托管方法内存已经被其他清理路径释放
  • 该版本CLR存在已知的DynamicMethod清理逻辑缺陷，在服务类应用高频生成、释放动态方法的场景下，低概率（每周一次）触发崩溃完全符合这类竞态bug的特征
  • 调试时看到的System.ExecutionEngineException是CLR检测到自身非托管内存访问违例后抛出的顶层异常，不是业务代码直接抛出的异常，局部变量无法查看是因为Release模式下代码做了优化，终结器执行时相关字段已经被释放或不在寄存器中。
• 你在Windows 10环境分析Server 2016生成的Dump，因为两个系统的CLR补丁版本可能存在差异，会进一步加大局部变量、调用栈分析的误差。

• 第一步先排查业务代码中所有动态生成IL方法的场景，重点覆盖：
  • 动态序列化/反序列化组件：比如老版本Newtonsoft.Json的动态类型转换、自定义ORM的对象映射方法生成
  • 动态代理/AOP组件：比如Castle DynamicProxy、老版本Unity/Autofac的拦截代理生成
  • 自行编写的DynamicMethod、ILGenerator相关反射发射代码
  • 开启了RegexOptions.Compiled选项的正则表达式，高并发场景下会生成大量动态方法
• 优先验证框架层面的修复方案：
  • 你当前使用的CLR 4.7.3920对应.NET Framework 4.7.2版本，先将服务器上的.NET Framework升级到4.8并安装最新累积更新，.NET Framework 4.8修复了多例DynamicMethod终结器清理的竞态问题，是成本最低的修复方式
  • 如果暂时无法升级框架，可以在应用的app.config/web.config的runtime节点下添加如下配置，将动态方法的清理逻辑从GC终结器线程转移到AppDomain卸载时执行，彻底规避竞态窗口：

    <AppContextSwitchOverrides value="Switch.System.Reflection.Emit.DisableDynamicMethodLazyCleanup=true" />
    

    这个配置的副作用是动态方法占用的非托管内存在应用运行期间不会主动释放，如果你的服务不是无限制生成动态方法，内存占用不会有明显上涨。
• 进一步Dump定位的注意事项：
  • 不要直接在Windows 10环境分析Server 2016抓取的Dump，需要先从服务器拷贝对应版本的clr.dll、mscorlib.dll到分析环境，加载对应符号后再使用WinDbg的!dumpheap -type DynamicResolver命令枚举所有存活的动态方法对象，通过根引用回溯定位是哪个组件生成的动态方法触发了问题
  • 可以在测试环境开启CLR终结器日志，配置注册表路径HKLM\SOFTWARE\Microsoft\.NETFramework下的GCFinalizeLog=1值，复现问题时可以抓到崩溃前最后一个被终结的动态方法的生成调用栈。

内容的提问来源于stack exchange，提问作者Dominique