c# - 如何处理类库中的 COM QueryInterface 失败

Question

我在实用程序库中遇到问题，它执行一些 COM 互操作。它保留对在调用之间使用的 COM 对象的引用。

如果所有方法都是从使用相同 COM 线程模型的线程调用的，则该类可以正常工作。

但是，如果创建 COM 对象的调用使用与后续调用不同的线程模型，QueryInterface 将失败并返回 E_NOINTERFACE。

我们只有在将 async 分支添加到我们的单元测试时才发现这一点；在此之前，它在所有 MTA 应用程序和所有 STA 单元测试中运行良好......

我想我理解失败的原因(通过 COM docs 、 Chris Brumme's blog )——所使用的 COM 对象支持“两种”线程模型，这导致 C# 在 STA 和 MTA 创建的实例之间创建一个栅栏。

然而，从库的角度来看，我能想到的唯一修复有点垃圾:

• 将此库仅用于 MTA 线程作为不成文的规则
• 更改库以检测来自 STA 线程的调用并失败(使用例如 CurrentThread.ApartmentState)
• 更改库以便为所有 COM 互操作创建自己的 MTA 线程(或者可能只是当传入调用在 STA 线程上时)

有没有更清洁/更简单的选择？这是一个 MCVE:

class Program
{
    [ComImport, Guid("62BE5D10-60EB-11d0-BD3B-00A0C911CE86")] class SystemDeviceEnum { };
    [ComVisible(true), ComImport, Guid("29840822-5B84-11D0-BD3B-00A0C911CE86"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    interface ICreateDevEnum { [PreserveSig] int CreateClassEnumerator([In] ref Guid pType, [Out] out IEnumMoniker ppEnumMoniker, [In] int dwFlags); }
    static ICreateDevEnum createDeviceEnum;
    static Guid VideoInputDeviceCategory = new Guid("860BB310-5D01-11d0-BD3B-00A0C911CE86");
    static void Prepare()
    {
        var coSystemDeviceEnum = new SystemDeviceEnum();
        createDeviceEnum = (ICreateDevEnum)coSystemDeviceEnum;
    }
    static int GetDeviceCount()
    {
        IEnumMoniker enumMoniker;
        createDeviceEnum.CreateClassEnumerator(ref VideoInputDeviceCategory, out enumMoniker, 0);
        if (enumMoniker == null) return 0;
        int count = 0;
        IMoniker[] moniker = new IMoniker[1];
        while (enumMoniker.Next(1, moniker, IntPtr.Zero) == 0) count++;
        return count;
    }
    [STAThread] 
    static void Main(string[] args)
    {
        RunTestAsync().Wait();
    }
    private static async Task RunTestAsync()
    {
        Prepare();        
        await Task.Delay(1);
        var count = GetDeviceCount();
        Console.WriteLine(string.Format("{0} video capture device(s) found", count));
    }    
}

Answer 1

众所周知，COM 线程很少被理解。实际上比线程化 .NET 类更容易上手。很多。几乎每个人都知道，比方说，List<> 或 Random 类不是线程安全的。知道如何以线程安全的方式使用它们的人并不多。 COM 设计者有更崇高的目标，并假设程序员一般不知道如何编写线程安全的代码，而聪明的人应该处理它。

它确实需要处理一些细节。首先也是最重要的，您必须告诉 COM 您愿意为非线程安全但无论如何都从工作线程使用的组件类提供什么样的支持。你在那里犯下了可怕的罪行。当您使用 [STAThread] 时，您就做出了一个 promise 。有两件事你必须做:你绝不能阻塞线程，你必须抽出一个消息循环(又名 Application.Run)。请注意您是如何违反两个 要求的。永远不要撒谎，当你这样做时会发生非常糟糕的事情。但您还没有做到这一点。

您可以从正在使用的组件类中获得的线程支持很容易发现。启动 Regedit.exe 并导航到 HKLM\Software\Wow6432Node\Classes\CLSID。找到您使用的 {guid} 并查看您在 InProcServer32 键中看到的 ThreadingModel 值。您正在使用的是“两者”。意味着它被编写为既可以从 STA 线程工作，也可以从根本不支持线程安全并在 MTA 中运行的线程工作。就像你的主线程和你的任务。正如您所发现的，两者都可以正常工作。请注意，这不是很常见，绝大多数 COM 服务器仅支持“单元”线程模型。 Microsoft 通常会不遗余力地支持这两者。

因此，您在 STA 线程上创建了枚举器对象，并在 MTA 中的线程上使用它。现在 COM 运行时必须做一些非常重要的事情，它必须确保可能从您调用的方法调用的任何回调(又名事件)在同一个 STA 线程上运行，以便任何代码在回调也是线程安全的。换句话说，它必须将来自工作线程的调用编码回您的主线程。相当于 .NET 应用程序中的 Control.Invoke 或 Dispatcher.Invoke。在 COM 中完全自动完成。

这需要做一些在 .NET 中非常容易但在非托管代码中非常困难的事情。该方法的参数必须从一个堆栈帧复制到另一个堆栈帧，以便可以在另一个线程上进行调用。由于反射，在 .NET 中很容易做到。对于非托管代码而言，这并不容易，它需要一个知道方法参数类型的 oracle，以替代丢失的元数据。

该 oracle 也在注册表中找到。使用 Regedit 并导航到 HKLM\Software\Wow6432Node\Classes\Interface 键。在那里找到接口(interface) guid，{29840822-5B84-11D0-BD3B-00A0C911CE86} 正如异常消息告诉您的那样。您会注意到问题:它不存在。是的，异常消息非常糟糕。报告真正的 E_NOINTERFACE 是因为 COM 运行时也找不到其他方法，不支持 IMarshal。如果它在那里，那么您将不得不处理 [STAThread] 谎言，您的线程将死锁。

顺便说一下，使用 ThreadingModel 为“Both”的 COM 对象模型几乎总是支持编码(marshal)处理。只是不适用于您尝试使用的特定。 DirectShow 在过去 10 年已被弃用，取而代之的是 Media Foundation。您找到了 Microsoft 决定停用它的一个很好的理由。

所以这只是您需要知道的事情。一个细节与必须知道 Random 类不是线程安全的没有太大区别。它在 MSDN 中没有很好的记录，但如前所述，您很容易发现它。