Interpreting HRESULTS returned from .NET/CLR: 0x8013XXXX
Yi Zhang - CLR
17 Dec 2010 12:21 AM
What is 0x8013XXXX
[left]Occasionally you might run into mysterious HRESULTs returned
from .NET that begins with 0x8013, for example, 0x80131522. Unfortunately
the error lookup shipped with Visual Studio doesn’t really work on
those strange HRESULTs. What are they?
It turns out they are in fact, defined by .NET/CLR in the header files. All
these failure/success HRESULTs are defined in corerror.h in your platform SDK
include directory (typically C:\Program Files
(x86)\Microsoft SDKs\Windows\v7.0A\Include). All these HRESULTs have their
facility defined as FACILITY_URT=0x13 (in which URT stands for Universal
Runtimeis an old 3-letter acronym for CLR, there are other funny old names
for CLR - COM+ is one of them). If you don’t recall what facility is, you
can think it as a category for the error – a
HRESULT have facility = FACILITY_URT is returned from CLR.
If you look at the binary layout of a HRESULT below, you’ll see any CLR
failure code will begin with 0x8013, and all the success code will
begin with 0x0013.
Interpreting the HRESULT
Let’s say you are seeing a HRESULT 0x80131522, how do you know what error
it is? Actually it is quite straight-forward - all the HRESULTs are defined
in corerror.h in the following fashion:
MAKE_HRESULT is a windows macro which does some simple bit math and use
SEVERITY_ERROR, FACILITY_URT, and val (as the lower 16-bits) to compose
a HRESULT. So if you open corerror.h in your favorite editor, and search
for the lower 16-bits which is 1522, you’ll easily locate the line:
#define COR_E_TYPELOAD EMAKEHR(0x1522)
Now you’ve probably already figured out it is a type load failure. But what
if the name doesn’t give us any meaningful information? If that’s the case,
now it is time to look it up in the resource DLL.
Look it up in mscorrc.dll
All the resources used by the native implementation of CLR (mscorwks/mscorsvr
in v1/v2, clr.dll in v4) are saved in mscorrc.dll. Every resource string in
resource DLLs have a resource ID. If you add 0x6000 to HRESULT code
(the lower 16-bits part), you’ll get the error message ID in the resource.
For example, the error message ID for 0x80131522 will be 0x6000+0x1522=29986.
Now, open mscorrc.dll in Visual Studio (or whatever resource editor you got),
and find the string ID with 29986:
clip_image003 (see url or pdf)
Now you know the error message is: Could not find or load type.
A full list of HRESULTs
To save everyone from looking things up from corerror.h and mscorrc.dll,
I made a table consists of every error HRESULT in .NET 4.0 and their
corresponding error message (extracted by a little tool I wrote).
Note that there are some HRESULTs don’t have corresponding resource
strings as they don’t follow the rules I talked about above and those
are listed as <N/A> in the table below.
[/left]
