Bug: winrt::hresult_error::originate asserts when using a clr.dll based error info object about cppwinrt HOT 5 CLOSED

RoOriginateErrorInformation's documentation doesn't seem to say that it resets the error info. The implementation respects RO_ERROR_REPORTING_SUPPRESSSETERRORINFO and RO_ERROR_REPORTING_USESETERRORINFO flags to RoSetErrorReportingFlags ... the logic for when RoOriginate... calls SetErrorInfo appears to be like this:

if (FlagNotSet(RoErrorFlags, RO_ERROR_REPORTING_SUPPRESSSETERRORINFO))
{
    if (FlagSet(RoErrorFlags, RO_ERROR_REPORTING_USESETERRORINFO) || IsDebuggerPresent())
    {
        SetErrorInfo(...);
    }
}

There's other paths through RoOriginateLanguageException that would cause the call to SetErrorInfo to be skipped. I'm inclined to fix up this path against "could not get the extended error info" as that's not really a developer problem as much as an environmental problem.

@ChrisGuzak can you grab a time-travel trace of the test you've got so we can see what's happening?

from cppwinrt.

Adding @manodasanW as I think he originally owned/wrote the origination APIs.

from cppwinrt.

Looks like the hresult_error case handles this properly:

While the originate path does not:

And worse, the originate path is triggered in the "the current info does not implement IRestrictedErrorInfo" case of the hresult_error ctor.

I'd expect that this is a bad assumption on C++/WinRT's part - there's certainly runtimes that will SetErrorInfo(pCustomErrorInfo) that does not implement IRestrictedErrorInfo so we should harden the code with that in mind.

from cppwinrt.

The latter is preceded by a call to RoOriginateLanguageException so that assertion should always hold.

from cppwinrt.

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

from cppwinrt.