none
Autogenerated RCW throws AccessViolationException. RRS feed

  • Question

  • Hello everyone! I'm writing a small OPC Client application. To connect to a server through COM there is a C++ /clr project which uses auto-generated .tlh and .tli files. Those file are generated at build cos' I use #import directive for a .tlb library. When I'm trying to call some of interface methods I'm getting an AccessViolationException. Is there any known problem with the #import "*.tlb" generated wrappers? Server itself works fine when I'm using ready OPC clients.
    The code is

    -- IDL --

    // IOPCCommon

    [
        object,
        uuid(F31DFDE2-07B6-11d2-B2D8-0060083BA1FB),
        // async_uuid(32E8D702-A335-4fc1-8F4B-663F505C7D62),
        pointer_default(unique)
    ]
    interface IOPCCommon : IUnknown
    {

        HRESULT SetLocaleID(
            [in] LCID dwLcid
        );

        HRESULT GetLocaleID(
            [out] LCID *pdwLcid
        );

        HRESULT QueryAvailableLocaleIDs(
            [out]                     DWORD  * pdwCount,
            [out, size_is(,*pdwCount)] LCID ** pdwLcid
        );

        HRESULT GetErrorString(
            [in]          HRESULT  dwError,
            [out, string] LPWSTR * ppString
        );

        HRESULT SetClientName(
            [in, string] LPCWSTR szName
        );
    }

    Caller code is

            IOPCCommonPtr * commonPtr;

            HRESULT hRes = m_ServerInterface->GetInterfacePtr()->QueryInterface<IOPCCommonPtr>(&commonPtr);

            if (SUCCEEDED(hRes))
            {
                unsigned long dwCount, *localeIds;

                commonPtr->GetInterfacePtr()->GetLocaleID(&dwCount); <- AccessViolationException


    Configuration: .NET 2.0, VS2005 SP1, WinXP Sp2 and Vista Home Ultimate (Second PC)

    Thank You.
    Friday, August 29, 2008 6:07 PM

Answers

  • I'm trying to figure out what this has to do with RCWs and .NET.  #import does not generate an RCW, it generates a header file with declarations from the type library (the .tlh file) and a file that contains small stub functions to allow smart pointers derived from the _com_ptr_t class to call the COM interface methods (the .tli file).  These small stubs are not capable of generating AV, it is invariably the interface method that AVs.  You should be able to readily diagnose this with a debugger, looking at the call stack.  It is however likely that the last recognizable method on the stack is the stub function, you probably don't have debug symbols for the actual COM component.

    Post to the C++ General forum.  You will however not likely get a lot of help with debugging AVs, there are far too many possible causes for them.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Wednesday, September 3, 2008 10:41 AM
    Saturday, August 30, 2008 11:41 AM
    Moderator