Foreach fails with a marshalled COM interface

Question

We have a 32-bit COM component written with ATL in C++. When there's a need to use it from 64-bit .NET, we create a COM+ application and everything works allright.

Recently we noticed strange behaviour on Win2k8. The COM object in our component fires an event and we process it in .NET code. The event has a parameter also passed from the unmanaged code.

Here's partial definition for clarification (IDL notation):

interface IOurCollectionInterface : IDispatch 
{
[propget, restricted, id(DISPID_NEWENUM)]]
HRESULT _NewEnum( [out, retval] IUnknown** result );
}

interface IOurObjectInterface : IDispatch 
{
[propget]
HRESULT Collection( [out, retval] IOurCollectionInterface** result );
}

The event handler is passed a IOurObjectInterface instance. Inside we try to run a foreach() loop.

void onEvent( IOurObjectInterface ourObject )
{
    foreach( object element in ourObject.Collection ) {
       //do stuff
    }
}

The code crashes on the line with foreach with the following message: QI for IEnumVARIANT failed on the unmanaged server

IEnumVARIANT is for sure implemented by the object which is returned by the IOurCollectionInterface::get__NewEnum() implementation. The code above works allright on WinXP and Win2k3 but not on Win2k8.

What's the reason for such behaviour?

Answer 1

Hard to be sure. But would suspect a marshalling issue.

Have you checked that the implementation of IOurCollectionInterface._NewEnum is actually being called?

What kind of COM marshalling are you using? If typelib, is the typelib correctly registered?

Does it work if the interface is implemented in process?

---

From a comment by sharptooth:

Typelib marshalling is used and the typelib is registered. Even worse, this stuff workfs allright when invoked from a WinForms application on the same machine but fails when invoked from an NT service run under a local user.

If the WinForms app and service are run as different users, time to check security very carefully. Start with COM+ security, and then check with Process Monitor for registry/file access issues (this seems unlikely, but is always possible).

Answer 2

Try running with System account and check events for more info about errors.