none
RCW does not populate ComException.Message correctly RRS feed

  • Question

  • Hi,

    I have two similiar problems:

    (1)
    My COM server calls SetComErrorInfo with a descripion as part of the error info and then fails with some negative HRRESULT.
    The RCW creates a ComException and correctly populates the ErrorCode member of the ComException with the HRESULT that actually was returned by the server.
    However, the Message property of the ComException does not contain the string of IErrorInfo->GetDescription - it contains the string "Exception from HRESULT: 0x80040858".
    What might be the problem?

    Using a C++ client returns the correct error message of IErrorInfo:

    CComPtr<IErrorInfo> ptriErrorInfo;
    hr = GetErrorInfo(ul, &ptriErrorInfo);
    CComBSTR bstrDescr;
    hr = ptriErrorInfo->GetDescription(&bstrDescr);



    (2) If I use ildasm/ilasm for interop assembly to change a method signature to use "preservesig" to return the HRESULT of the method instead of the [out,retval] paramter - a call to Marshal.GetExceptionForHR(hr); does generate a ComException with the expected HRESULt but again with the "wrong" Message.
    Any ideas?


    Thanks,
    DPOMT

    Sunday, February 21, 2010 8:12 PM

Answers

  • I've got more info from our COM expert:
    Apparently this should work. The likely problem is that your COM object does not implement ISupportErrorInfo properly. It must be implemented and InterfaceSupportsErrorInfo has to return S_OK for the IID of the interface through which the call was made. Otherwise CLR ignores the thread’s IErrorInfo.

    -Karel
    • Marked as answer by DPOMT Monday, February 22, 2010 10:30 PM
    Monday, February 22, 2010 6:43 PM
    Moderator

All replies

  • IMO everything points out to the fact that CLR doesn't call IErrorInfo::GetDescription at all. I'll try to get more info why ...

    -Karel
    Monday, February 22, 2010 12:39 AM
    Moderator
  • A wild guess:  You are not constructing your HRESULT appropriately.  Don't quote me, but I believe that all user-defined errors are 0x8007....  Yours is not.  Basically, you are not using the ITF_FACILITY (or something like that -don't remember it right now-).
    MCP
    Monday, February 22, 2010 6:00 AM
  • The HR is defined as
    #define E_INCONSISTENT_IMPLICIT_AND_EXPLICIT_OWNER      MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF, 0x858)

    I read that the range reserved for user-defined errors is 0x80040200 to 0x8004FFFF - this corresponds
    to the general FACILITY_ITF range allocated to errors from an interface.
    Monday, February 22, 2010 7:18 AM
  • Ok, you see?  I had it all wrong.  Good thing you didn't quote me on this one. :-)  I probably have a mix up between user-defined and HRESULT's from Win32 error codes.  So I guess my guess is a no no.

    MCP
    Monday, February 22, 2010 2:27 PM
  • I've got more info from our COM expert:
    Apparently this should work. The likely problem is that your COM object does not implement ISupportErrorInfo properly. It must be implemented and InterfaceSupportsErrorInfo has to return S_OK for the IID of the interface through which the call was made. Otherwise CLR ignores the thread’s IErrorInfo.

    -Karel
    • Marked as answer by DPOMT Monday, February 22, 2010 10:30 PM
    Monday, February 22, 2010 6:43 PM
    Moderator
  • I've got more info from our COM expert:
    Apparently this should work. The likely problem is that your COM object does not implement ISupportErrorInfo properly. It must be implemented and InterfaceSupportsErrorInfo has to return S_OK for the IID of the interface through which the call was made. Otherwise CLR ignores the thread’s IErrorInfo.

    -Karel

    Hello Karel,

    thanks a lot for investigating on this topic - that helped me in finding the solution!
    My COM object does implement ISupportErrorInfo but does not handle all implemented interfaces in InterfaceSupportErrorInfo.
    The described issue with missing Message property in ComException indeed only occurs if InterfaceSupportErrorInfo does not return S_OK for interface corresponding to the interface call.

    Thanks for solving this issue!
    DPOMT
    Monday, February 22, 2010 10:30 PM