COM对象隐式接口转换是否会导致Null引发参数空异常？

问题背景 #

遇到间歇性的ArgumentNullException，堆栈跟踪显示异常触发于DoSomething3方法，但前面的DoSomething1和DoSomething2调用时row变量均不为null。相关代码如下：

COMRow row = GetCOMRow();
DoSomething1(row);
DoSomething2(row);
DoSomething3(row);
...
// DoSomething methods all look like this:
void DoSomethingX(ICOMRow row)
{
    if (row == null)
        throw new ArgumentNullException(nameof(row));
    ...
}

// the com interface
[ComImport]
[Guid("...")]
[TypeLibType(TypeLibTypeFlags.FDual | TypeLibTypeFlags.FNonExtensible | TypeLibTypeFlags.FDispatchable)]
[SuppressUnmanagedCodeSecurity]
public interface ICOMRow { ... }

[ComImport]
[Guid("...")]
[CoClass(typeof(COMRowClass))]
public interface COMRow : ICOMRow { }

疑问点：调用时从COMRow到ICOMRow的隐式转换是否会触发COM的QueryInterface？若调用失败是否会静默返回null？COM对象本身不稳定（偶尔抛出COMException），是否是导致问题的原因，还有哪些排查方向？

核心原因分析与排查方向 #

1. 隐式转换确实会触发QueryInterface，失败时静默返回null #

当你将COMRow类型的变量传递给接收ICOMRow参数的方法时，CLR会自动执行COM接口转换，这个过程会调用COM对象的QueryInterface方法来获取ICOMRow接口的指针。

• 如果QueryInterface调用失败（比如COM对象内部状态异常、接口未正确实现、对象已被释放），CLR不会抛出异常，而是将该接口引用置为null，这就会导致DoSomething3的参数检查触发ArgumentNullException。
• 这种间歇性的失败，正好对应你遇到的“有时正常有时报错”的现象。

2. COM对象不稳定是核心诱因 #

你提到COM对象偶尔会抛出COMException，说明它的内部状态存在不可靠性，这很可能是导致问题的根源：

• 对象被意外释放：DoSomething2执行过程中，COM端可能主动释放了对象资源，或者其他线程调用了Marshal.ReleaseComObject等方法提前释放了引用，导致后续DoSomething3的接口转换时，QueryInterface因为对象已失效而失败。
• 线程模型冲突：如果COM对象是单线程公寓（STA）类型，但你的代码在多线程环境下访问它，可能会导致间歇性的接口查询失败，进而返回null。
• 内部状态异常：DoSomething2中的操作可能改变了COM对象的内部状态，使其后续无法响应QueryInterface请求。

3. 其他需要排查的点 #

• 引用计数问题：检查是否有其他代码在后台调用Marshal.ReleaseComObject或Marshal.FinalReleaseComObject，提前释放了row对应的COM对象引用。可以用Marshal.GetIUnknownForObject(row)配合Marshal.AddRef和Marshal.Release来获取当前引用计数，在每次调用方法前后记录计数变化。
• DoSomething2的内部操作：仔细检查DoSomething2中对ICOMRow的操作，是否调用了会导致对象失效的方法（比如某些“关闭”或“释放”类的方法）。
• 添加日志监控：在每次调用DoSomethingX前，添加日志记录row是否为null，以及COM对象的哈希码（或唯一标识），帮助定位对象何时变为null。

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