C# Application crashes on method call to COM Class

I have a C# Winforms application that makes a call to a COM class. When debugging using Visual Studio it steps into the c++ code and returns S_OK but when the function returns visual studio hangs and the application crashes. I have to end process on the VS process to stop the program from running. If i run the app outside of visual studio the application simply crashes.

Everything was working fine and i have no idea what i may have done to cause this problem.

Any help is appreciated. Thanks

This is the interface definition

typedef struct
{
    long    ExpiryData
    BSTR    IssuedBy;
} LicenceData;

[
    object,
    uuid (5A734F95-EABE-440B-8B7E-0F73538A24AC), 
    pointer_default(unique),
    helpstring("ILicenceReader Interface"),
]
interface ILicenceReader : IDispatch
{
    HRESULT ReadLicenceFile ([in, out]LicenceData* plicenceData, LPCTSTR filePath);
};

[
    uuid(C2833A21-6586-4648-ABC8-D42BC3225699)      
]
coclass LicenceReader
{
    [default] interface ILicenceReader;
};

I have referenced the COM dll and allowed VS to generate the Interop and the usage in the c# application:

LicenceData data = new LicenceData();

ILicenceReader reader = new LicenceReader();

reader.ReadLicenceFile(ref data, filePath);

Thanks for your help.

2012-04-04 22:39
by Sjblack

Perhaps you could provide details about the COM calls that you're making? Additionally, information about OS, CPU architecture (32bit vs. 64bit), compiled CPU architecture (AnyCPU vs. x86), etc all could be helpful - Reddog 2012-04-04 22:59

Seems a problem with the stack. Could you show the signature of your COM function, how you declare in C# and how you call it - Steve 2012-04-04 23:00

Configure the debugger to stop on SEH (Menu->Debug->Exceptions for VS). Run applcation with the debugger attached, but don't use step by step execution. See what exception will be reporte - Igor Chornous 2012-04-05 04:55

I turned on all exceptions and it still just kills visual studio. It's running on 64bit windows 7 machine. The target platform is x86 in both the c# app and the COM dll. The function call passes back a stuct by ref with a few strings and ints in - Sjblack 2012-04-05 07:39

@Sjblack, show us the IDL file and a correspondent C# definition of all the interfaces and classes involved in the operatio - Igor Chornous 2012-04-05 07:54

Updated the Post with the details - Sjblack 2012-04-05 08:00

@Sjblack, C# code looks good to me. Maybe the problem is withing the COM object ? Also, it is a very bad idea to use LPCTSTR as a parameter type. It is better to use BSTR instead - Igor Chornous 2012-04-05 08:41

I'll bet that the COM subsystem is trying to unmarshall a BSTR allocated on the stack, or perhaps allocated with a smart pointer on the stack.

BSTRs have to be allocated with SysAllocString. The result from this can be returned as-is as it's not on the stack and nothing will try to free it erroneously.

If you use a smart pointer BSTR class such as CComBSTR or _bstr_t then you'll need to set the IssuedBy member via a Detach. CComBSTR::Detach() will return the pointer to the BSTR and not try to free it when that local instance of CComBSTR goes out of scope.

plicenceData->IssuedBy = CComBSTR("Some Dude").Detach();

Another possibility is that you try to do something like plicenceData = new plicenceData within your COM class, overwriting the instance passed in. That won't work.

In the end, pretty much the only reason a COM function fails after it's finished and returned is because of marshalling issues. It's the layer between your C# code and the called C++ that's trying to translate the data across apartment and possibly process boundaries. You need to ensure that you follow the COM rules to the letter to allow marshalling to do it's job.

So, double check all your pointers. Are they on the stack or on the heap? They need to be on the heap. Are all BSTRs allocated appropriately? Using smart BSTR classes will usually help significantly, but just remember that you can't return the raw members. Use these classes as they're expected to be used.

2012-05-23 00:11
by Tra5is