return value CoCreateInstance not documented in MSDN

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

George - 05 Aug 2007 07:02 GMT

Hello everyone,

The return value of CoCreateInstance is -2146232576, which is un-documented
in MSDN.

http://msdn2.microsoft.com/en-us/library/ms686615.aspx

What does it mean? What is wrong with my code?

[code]
HRESULT hr = CoCreateInstance(CLSID_MyDriver,
            NULL,
            CLSCTX_INPROC_SERVER,
            IID_IMyDriver,
            reinterpret_cast<void**>(&driver_interface));

if (FAILED(hr))
{
    if (hr == REGDB_E_CLASSNOTREG)
    {
        printf("Couldn't create the instance!... 0x%x\n", hr);
    }
    else if (hr == CLASS_E_NOAGGREGATION)
    {
        printf("Couldn't create the instance!... 0x%x\n", hr);
    }
    else if (hr == E_NOINTERFACE)
    {
        printf("Couldn't create the instance!... 0x%x\n", hr);
    }
    else if (hr == S_OK)
    {
        printf("Couldn't create the instance!... 0x%x\n", hr);
    }
    else
    {
        printf("Couldn't create the instance!... 0x%x\n", hr);
    }
}
[/code]

thanks in advance,
George

Reply to this Message

Sheng Jiang[MVP] - 06 Aug 2007 20:14 GMT

-2146232576=0x80131700
the first bit(8) means error, 13 means FACILITY_URT, a value reserved. for
the .NET Framework SDK teams, 1700 is defined as CLR_E_SHIM_RUNTIMELOAD in
corerror.h

If you are creating a COM component, check the runtime versions in your
component and in your process. Multiple CLR versions can not coexist in the
same process.
You can use bindingredirect in your config file to indicate a different CLR
version should be used for your assembly, visit
http://msdn2.microsoft.com/en-us/library/eftw1fys.aspx

Signature

Sheng Jiang
Microsoft MVP in VC++

> Hello everyone,
>
[quoted text clipped - 39 lines]
> thanks in advance,
> George

Reply to this Message

George - 07 Aug 2007 06:58 GMT

Thanks Sheng Jiang,

Do you mean,

1. The error is caused by I have installed multiple CLR (Microsoft .Net
Common Language Runtime) on the machine?

2. Or, I have installed multiple versions of the assembly (the COM assembly
I developed by myself), which causes conflict?

3. Or, I have used some version of CLR to build the assembly, but the
runtime environment I used to test, is using a different version of CLR,
which causes conflict?

regards,
George

> -2146232576=0x80131700
> the first bit(8) means error, 13 means FACILITY_URT, a value reserved. for
[quoted text clipped - 51 lines]
> > thanks in advance,
> > George

Reply to this Message

Ben Voigt [C++ MVP] - 07 Aug 2007 14:36 GMT

> Thanks Sheng Jiang,
>
[quoted text clipped - 10 lines]
> runtime environment I used to test, is using a different version of CLR,
> which causes conflict?

It most likely means that the application trying to load the assembly, has
already loaded an older version of the CLR, which the assembly can't work
with.

Reply to this Message

George - 08 Aug 2007 06:36 GMT

Thanks Ben,

From your comments, I think the solution is to let the application which is
trying to load the assembly load a proper newer version of CLR which the
assembly, right?

Could I achieve this point by uninstall older version CLR and install new
version of CLR? Thanks.

regards,
George

> > Thanks Sheng Jiang,
> >
[quoted text clipped - 14 lines]
> already loaded an older version of the CLR, which the assembly can't work
> with.

Reply to this Message

Ben Voigt [C++ MVP] - 08 Aug 2007 14:14 GMT

> Thanks Ben,
>
> From your comments, I think the solution is to let the application which
> is
> trying to load the assembly load a proper newer version of CLR which the
> assembly, right?

If I understood you right, yes.

> Could I achieve this point by uninstall older version CLR and install new
> version of CLR? Thanks.

No, that wouldn't work. Normally the newest CLR always loads, unless there
is a manifest asking for an older version (it could be in a different
plugin). If there is, then uninstalling the old version will cause
everything to fail. A better thing to do is create a manifest for the .exe
asking the newest CLR to load when the application starts, that way there's
no chance for a different plugin to load an old CLR.

> regards,
> George
[quoted text clipped - 19 lines]
>> already loaded an older version of the CLR, which the assembly can't work
>> with.

Reply to this Message

George - 09 Aug 2007 03:20 GMT

Thanks Ben,

I think you mean for a system, usually the newest CLR will be loaded unless
a manifest file is used to specify to load an older version of CLR, right?

Do you have any documents about how to write such manifest file.

regards,
George

> > Thanks Ben,
> >
[quoted text clipped - 38 lines]
> >> already loaded an older version of the CLR, which the assembly can't work
> >> with.

Reply to this Message

Rate this thread:

return value CoCreateInstance not documented in MSDN

Free Magazines