CODEWITHSUNDEEP
visual-studiocomatl
user1411477
user1411477

Reputation: 53

Unable to create a com object using proxy stub dll

Using Visual c++ 6.0, I have created an ATL based .EXE server . (VC6 as I am dealing with legacy code, a .exe server as I need to test operation in an out of process context, currently the .exe server is essentialy a no op)

I have built and registered the corresponding proxy stub DLL.

I have a client app that does

  1. CoCreateInstance of IUnknown which invokes FinalConstruct in server object and succeeds (so server is correctly invoked)
  2. OleRun of returned IUnknown interface succeeds
  3. QueryInterface on IUnknown pointer for my server object fails with error code of 0x8000402 (No such interface supported) for the IMarshall interface

These steps were copied from (comip.h::CreateInstance)

The problem appears to be that the proxystub dll is not being invoked (it doesn't appear in the Modules list in the IDE, nor in loaded modules list in debug window)

The OleCom Object viewer for my class and interface can be seen here https://skydrive.live.com/redir?resid=AE43106917EBD9E1!191&authkey=!AIOWeS5P3o2mlpw

8891..ca4d is the class interface id for my object

A298...420c is the interface ID for my server object (IDispatch based)

TIA for any assistance

Upvotes: 1

Views: 1115

Answers (1)

Tra5is
Tra5is

Reputation: 146

It's possible that your issue is that the component that is implementing the IRunnableObject interface isn't registering itself in the Running Object Table. This will mean that the CoCreateInstance itself will succeed, however, when the object it called on, the RPC code will be unable to find it.

This MSDN page indicates: http://msdn.microsoft.com/en-us/library/windows/desktop/ms694517(v=vs.85).aspx

    Notes to Implementers
    The object should register in the running object table if it has a 
    moniker assigned. The object should not hold any strong locks on itself; 
    instead, it should remain in the unstable, unlocked state. The object 
    should be locked when the first external connection is made to the object.

I'm a little worried about why you're also using the IMarshall interface. Normally it's not necessary to write custom marshaling code, thus you won't need to use this interface.

As long as you don't reference a custom interface the default marshaller in ole32.dll or oleauto32.dll will be used. That's most likely why you don't see your proxy being loaded. 

    In the case of most COM interfaces, the proxies and stubs for standard 
    marshaling are in-process component objects which are loaded from a 
    systemwide DLL provided by COM in Ole32.dll.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms692621(v=vs.85).aspx

Upvotes: 0

Related Questions