Pass a COM object across processes

Question

Hi,
I need to pass a COM object from process A to B.  I didn't find a good code example for IMoniker.  So I am trying to test a simpler solution.  Please refer to the following snippet of code.  There is a problem.  When the execution
reaches GetActiveObject in B, the system hangs.  "HRESULT h" in several places returns S_OK.   Does anybody have a clue?  Please help me out.  Thanks for your help in advance.
// the definition of the COM object
EXTERN_C const IID IID_IUniverse;
#if defined(__cplusplus) && !defined(CINTERFACE)
    MIDL_INTERFACE("91CAF3F6-BD4D-4DDC-9C35-59F5DB20D570")
    IUniverse : public IDispatch
    public:
// PROCESS A:
HRESULT h = RegisterActiveObject (cwApp, IID_IUniverse, ACTIVEOBJECT_STRONG , &dwRegister);
// PROCESS B:
HRESULT h = CoInitialize(NULL);
IUniverse *p = NULL;
HRESULT h = GetActiveObject(IID_IUniverse, NULL, (IUnknown**)&p);
if (p)
  CComPtr<IUniverse> cwApp(p);
JD

Answer 1

On 1/27/2015 7:43 PM, jdyng77 wrote:
I did some research on this issue to help me better understand your comments here.  I still don't fully understand the problem.  Please help me out.  Or, if I can get around the problem by using IMoniker and IRunningObjectTable instead,
I would be more than happy doing that.
Unlikely. If, as I suspect, the problem is that the server thread blocks, then the client won't be able to obtain the interface pointer from it by any means. Any IPC mechanism you might want to use kind of assumes that both parties remain responsive.
WaitForSingleObject() is the opposite of "responsive".
The third party (3rd pty) provides a COM interface.  I write a COM server A
In-process (a DLL) or out-of-process (an EXE)? From your description, I would assume in-proc.
that has an implementation for this interface.  I believe the 3rd pty must have called CoInitialize(NULL) before it instantiates object A.
It must have, yes. This is only significant if A is an in-proc server.
The 3rd pty passes a COM object of IUniverse to A.  I can call IUniverse's methods in A without any problem.  The need here is to transfer the IUniverse object to another process B so that B can call IUniverse's methods.  The problem
is that B hangs.
My guess is, B hangs because A hangs. In one of your responses, you suggest that you are calling WaitForSingleObject (waiting on process B's handle, I presume). In so doing, you have created a deadlock. B is trying to communicate with A to retrieve the
interface pointer, but A is waiting for B to exit.
After A registers IUniverse pointer (whether in ROT or as active object), it should return to the caller. Said caller likely spins a message pump - but by blocking and not returning, you don't allow it to run.
The thread where A sits is created in the 3rd pty.  If I understand you correctly, the 3rd pty must "retrieve and dispatch window messages in a timely manner".  I think it does because it calls A when a window button is clicked.
3rd pty would, if only A would let it. By sitting in the message handler, A prevents the caller from retrieving messages in a timely manner.
But I don't know whether I should use Class, File or Item IMoniker.
Item moniker is the easiest to use by far. It just wraps a piece of text. You create one with CreateItemMoniker: pass L"!" (by convention) in the first parameter, and arbitrary string in the second. Both parties (one that registers in ROT, and
one that picks up) should agree on and use the same string, of course.
Igor Tandetnik