不情愿地通过RPC调用QueryInterface

Question

在我的应用程序中，我创建了一个对象 A，该对象创建了一个对象 B，两者都是通过 CreateInstance 实现的。两个对象应该存在于同一个进程中。

现在我看到对象 B 在请求某个接口时返回 E_NOINTERFACE，尽管我在 COM_MAP 中定义了它：

class B:
{
    // ....
BEGIN_COM_MAP(B)
    COM_INTERFACE_ENTRY(IB)
    COM_INTERFACE_ENTRY(IDispatch)
    COM_INTERFACE_ENTRY(IXXX) // the interface I'm interested in
END_COM_MAP()
    // .....
};

并且 A 代码：

#define FORWARD_ERROR( expr ) { hr=expr; if( !SUCCEEDED( hr ) ) return hr;}
IBPtr b;
FORWARD_ERROR( b.CreateInstance( __uuidof( B ), 0, CLSCTX_INPROC_SERVER ) );

IXXXPtr x;
HRESULT hrIf = b.QueryInterface( __uuidof( IXXX ), x );
// ===> now x is NULL, and hrIf contains E_NOINTERFACE

当我调试它并在 COM_MAP 中放置断点时，我看不到我的源代码在最底层，但是一些ole32.dll的CRpcThread::WorkerLoop。

我不知道如何指示应该通过 OLE 和 RPC 调用 QueryInterface。有什么想法吗？

Answer 1

根据您的描述，这绝对是​​编组启动。编组是通过 RPC 进行隧道调用来完成的，因此看起来相当奇怪，但这就是 Windows 上的完成方式。

消费者线程可能使用 COINIT_APARTMENTTHREADED 调用 CoInitializeEx()。由于要创建的对象被标记为Free，因此它不可能在调用者的公寓中创建（请参阅这个关于公寓的很好的解释）。相反，COM 尝试打开编组，而您可能没有任何东西以便于编组，在这种情况下，CoCreateInstance() 返回 E_NOINTERFACE，因为 COM 内部工作请求 它将用于的一堆接口编组，一旦所有这些请求失败，它就会以 E_NOINTERFACE 结束并返回它，这对您来说当然一点也不方便。

然后，您从 Free 更改为 Both，这意味着 “Apartment of Free as COM sees fit” COM 被正式允许将对象放入与呼叫者同一公寓，但没有编组是必需的，因此您不会再看到那些看起来很奇怪的错误代码。

Answer 2

当我从多线程上下文创建对象时，B 类的线程模型是“自由”的。将 B 切换为“两者”解决了问题。