0

I have inherited a Microsoft Visual C++ COM project which is a dependency of a core C# application I work with. When recompiling the project and regenerating the interop DLL (using tlbimp), several methods in my library that take in an OLE_HANDLE change their signature from the previous version of my interop DLL.

I wasn't around when the previous interop was generated, but it was almost certainly compiled under VS2005 on Windows Server 2003 / Windows XP. My workstation is now Windows 7 using Visual Studio 2010 (C++ Visual Studio Compiler version 16.00.40219.01 for x64).

This is the generated C# interface for the original and new DLL (using ILSpy):

New Interface (second parameter is marshaled using the ComAliasName attribute & as int):

[TypeLibFunc(64)]
[MethodImpl(MethodImplOptions.InternalCall)]
public virtual extern void GetSequence([MarshalAs(UnmanagedType.Interface)] [In] INameValueArray nvArray, [ComAliasName("stdole.OLE_HANDLE")] [In] int nvSequence);

Old Interface (second parameter is uint):

[TypeLibFunc(64)]
[MethodImpl(MethodImplOptions.InternalCall)]
public virtual extern void GetSequence([MarshalAs(UnmanagedType.Interface)] [In] INameValueArray nvArray, [In] uint nvSequence);

As far as I can see, the input IDL file hasn't changed and there don't seem to be any #includes / conditional statements that would affect the definition of an OLE_HANDLE.

Whenever the methods in question are invoked, an AccessViolationException is thrown.

Does anyone have any ideas why the generated interface may have changed (not sure if any changes in MIDL/TLBIMP would result in this behaviour) or how I might start to debug this further?

Header:

virtual HRESULT STDMETHODCALLTYPE GetSequence(INameValueArray *nvArray, OLE_HANDLE *nvSequence);

C++ source for method:

HRESULT MyNamespace::GetSequence(INameValueArray *nvArray, OLE_HANDLE *nvSequence)
{
    if(!nvArray || !nvSequence)
        return E_POINTER;
    (*nvSequence) = (OLE_HANDLE) (((CNameValueArray *)nvArray)->GetSeq());
    return S_OK;
}
Henry Thacker
  • 63
  • 1
  • 5
  • Can you show the C++ version? – Simon Mourier Jun 10 '13 at 06:00
  • It's Visual Studio 2010 - Compiler version 16.00.40219.01 for x64 – Henry Thacker Jun 10 '13 at 09:20
  • I meant the C++ version of the method :-) – Simon Mourier Jun 10 '13 at 09:26
  • Sorry - replied when half asleep :-) Question updated with source. Thanks! – Henry Thacker Jun 10 '13 at 10:05
  • OLE_HANDLE is very old and very obscure. And very broken, it cannot actually store a handle value properly. Handles are 64-bit values in 64-bit code, OLE_HANDLE's underlying native type is UINT, a 32-bit value. It isn't clear whether that has anything to do with your code crashing, the *nvSequence* variable doesn't quack much like a handle. – Hans Passant Jun 10 '13 at 11:45
  • It seems the ComAliasName OLE_HANDLE is used for ActiveX Wrapping code (for example in the internal AxWrapperGen.ComAliasEnum GetComAliasEnum method), so not specifically during the managed<->native marshaling process. Is the server out of process? in process? 32-bit? 64-bit? – Simon Mourier Jun 10 '13 at 12:11
  • The server is in process, compiled for AnyCPU (64-bit preferred). – Henry Thacker Jun 10 '13 at 12:43
  • Sorry that was for the interop DLL. The C++ library is x86, confirmed with depends.exe. – Henry Thacker Jun 10 '13 at 13:37

0 Answers0