如何获取Marshal持有的RCW列表 排查Excel插件COM对象残留问题

问题描述 #

• 开发的Excel插件需长期持有大量Excel原生对象引用，用户关闭Excel时偶发程序挂起、后台残留Excel进程的问题。
• 目前业界对COM对象释放存在两类观点：一派主张信任GC自动回收，另一派主张需要手动执行清理。最初采用信任GC的方案，在插件卸载时额外执行如下代码做兜底清理：

do {
    GC.Collect();
    GC.WaitForPendingFinalizers();
}
while (Marshal.AreComObjectsAvailableForCleanup());

• 该方案落地后问题仍随机出现，根因难以定位。后续在所有相关位置补充了Marshal.ReleaseComObject调用，挂起残留问题仍偶发。
• 推测：既然可以通过Marshal.AreComObjectsAvailableForCleanup判断是否存在待清理COM对象，说明Marshal内部维护了一份集中的RCW列表，希望找到方法获取该列表，查看其持有的原生对象信息，从而定位导致残留的问题对象。
• 查阅Marshal类的公开方法未找到相关接口，查看.NET参考源码时发现相关逻辑最终调用如下内部本机方法，追踪链路中断：

[ResourceExposure(ResourceScope.None)]
[MethodImplAttribute(MethodImplOptions.InternalCall)]
internal static extern int InternalReleaseComObject(Object o);

• 现寻求可枚举Marshal持有的RCW对象的可行方案，同时征集其他可保障Excel正常关闭的优化建议。

解决方案 #

RCW枚举定位泄漏对象的方法 #

.NET未公开直接枚举所有RCW的官方API，可通过以下两种方式定位泄漏的RCW对象：

• 调试阶段可借助CLR调试接口ICorDebug遍历进程托管堆，筛选所有类型为System.__ComObject的存活实例，即为当前进程内未释放的RCW。拿到RCW实例后，可通过Marshal.GetIUnknownForObject获取原生IUnknown指针，配合COM的IProvideClassInfo接口查询对应原生对象的类型信息，结合引用链定位持有该对象的代码位置。
• 效率更高的方式是直接使用内存分析工具（如dotMemory、CLR Profiler）抓取问题场景下的进程dump，直接筛选System.__ComObject类型对象，工具会自动展示每个RCW的引用根路径，可直接定位到是哪段代码持有了对象引用导致无法释放，无需自行编写调试逻辑。

Excel插件COM对象释放优化实践 #

• 严格遵循谁创建、谁释放的原则使用Marshal.ReleaseComObject，不要对非自己代码创建的COM对象调用该方法，也不要混合使用手动释放和GC回收逻辑处理同一对象，否则会导致RCW引用计数紊乱，反而引发对象访问异常、无法释放的问题。
• 不要用全局静态变量持有Excel长生命周期对象（如Application、Workbook、Worksheet），这类引用会阻断GC对RCW的回收，直接导致Excel进程无法退出。如果确实需要全局访问这类对象，要在WorkbookBeforeClose、应用退出等事件中主动解绑所有关联的事件委托、清空对象引用。
• 重点排查隐式创建的COM对象泄漏：链式调用COM属性（如xlApp.Workbooks[1].Worksheets[1].Range["A1"]）时，Workbooks集合、Worksheets集合这类中间返回的对象都是独立的RCW，不手动释放就会造成泄漏。编写代码时尽量避免COM对象链式调用，每访问一级子对象就用单独变量接收，使用完成后按从内层到外层的顺序依次释放。
• 所有COM对象的访问、释放操作必须在Excel主线程（STA线程）执行，不要在后台线程执行GC兜底回收、Marshal.ReleaseComObject调用，否则容易引发RPC调用死锁，直接导致Excel挂起无法退出。
• 执行兜底GC回收前，必须先解绑所有注册到Excel对象的事件委托：事件委托会持有事件源的强引用，未解绑的情况下对应RCW的引用计数永远不会归零，无论执行多少次GC回收都无法释放对象。

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