Is there a list of COM error codes somewhere?
Related: HRESULT: 0x80010105 (RPC_E_SERVERFAULT) question
From Standard COM Errors (at least for Microsoft Commerce Server):
The following table shows the most common standard COM errors returned
by the properties and methods of the Commerce Server objects:
Constant Value (32-bit) Description
S_OK 00000000 The standard return value used to communicate successful completion.
S_FALSE 00000001 An alternate success value, typically used to communicate successful, but non-standard completion. The precise meaning depends on the method or property in question.
E_UNEXPECTED 8000FFFF Catastrophic failure error.
E_NOTIMPL 80004001 Not implemented error.
E_OUTOFMEMORY 8007000E Out of memory error.
E_INVALIDARG 80070057 One or more arguments are not valid error.
E_NOINTERFACE 80004002 Interface not supported error.
E_POINTER 80004003 Pointer not valid error.
E_HANDLE 80070006 Handle not valid error.
E_ABORT 80004004 Operation aborted error.
E_FAIL 80004005 Unspecified error.
E_ACCESSDENIED 80070005 General access denied error.
Com Errors Search Engine
I got following information from the Windows Kits header file WinError.h:
//
// MessageId: RPC_E_SERVERFAULT
//
// MessageText:
//
// The server threw an exception.
//
#define RPC_E_SERVERFAULT _HRESULT_TYPEDEF_(0x80010105L)
Related
I'm wondering if LLVM fatal errors are really "fatal" - ie. they invalidate the entire state of the system and are not recoverable.
For example (I'm using the llvm-c interface), the default behavior of the following code:
LLVMMemoryBufferRef mb = LLVMCreateMemoryBufferWithMemoryRange(somedata, data_length, "test", 0);
LLVMModuleRef module;
if (LLVMParseBitcode2(mb, &module) != 0) {
fprintf(stderr, "could not parse module bitcode");
}
is that if the pointer somedata points to invalid bitcode, the fprintf is never executed, but instead the entire process aborts with its own fatal error message on stderr.
However, there is supposedly an interface to catch such errors: LLVMFatalErrorHandler. However, after installing an error handler, the process still just aborts without calling the error handler.
The documentation in LLVM is very poor overall, and the C interface is barely documented at all. But it seems like super-fragile design to have the entire process abort in a mandatory way if some bitcode is corrupt!
So, I'm wondering if "fatal" here implies, as usual - that if such an error occurs, we may not recover and continue using the library (for example trying some different bitcode or repairing the old one, for example), or if it is not really a "fatal" error and we can have the FatalErrorHandler or some other means of catching and notify, or take other remediating actions, and continue the program.
Ok, after reading through the LLVM source for 10+ hours and enlisting the help of a friendly LLVM dev, the answer here is that this is not in fact a fatal error, after all!
The functions called above in the C interface are deprecated and should have been removed; LLVM used to have a notion of "global context", and that was removed years ago. The correct way to do this - so that this error can be caught and handled without aborting the process - is to use the LLVMDiagnosticInfo interface after creating an LLVMContext instance and using the context-specific bitcode reader functions:
void llvmDiagnosticHandler(LLVMDiagnosticInfoRef dir, void *p) {
fprintf(stderr, "LLVM Diagnostic: %s\n", LLVMGetDiagInfoDescription(dir));
}
...
LLVMContextRef llvmCtx = LLVMContextCreate();
LLVMContextSetDiagnosticHandler(llvmCtx, llvmDiagnosticHandler, NULL);
LLVMMemoryBufferRef mb = LLVMCreateMemoryBufferWithMemoryRange(somedata, data_length, "test", 0);
LLVMModuleRef module;
if (LLVMGetBitcodeModuleInContext2(llvmCtx, mb, &module) != 0) {
fprintf(stderr, "could not parse module bitcode");
}
The LLVMDiagnosticInfo also carries with it a "severity" code that indicates the seriousness of the error (sometimes mere warnings or perfomance hints are returned). Also, as I suspected, it is not the case that failing to parse bitcode invalidates the library or context state.
The code that was aborting with the cruddy error message was just a stop-gap to let legacy apps which still called the old API functions work - it set up a context and a minimal error handler which behaves in this way.
I have been reading the MSDN dev guide to COM. However the code on this page is confusing. Reproducing here:
The following code sample shows the recommended way of handling unknown errors:
HRESULT hr;
hr = xxMethod();
switch (GetScode(hr))
{
case NOERROR:
// Method returned success.
break;
case x1:
// Handle error x1 here.
break;
case x2:
// Handle error x2 here.
break;
case E_UNEXPECTED:
default:
// Handle unexpected errors here.
break;
}
The GetScode function doesn't seem to be defined, nor is NOERROR, and searching MSDN didn't help. A web search indicated that GetScode is a macro that converts HRESULT to SCODE, however those are both 32-bit ints so I'm not sure what it is for.
It was suggested that it is a historical artifact that does nothing on 32-bit systems, but on 16-bit systems it converts hr to a 16-bit int. However, if that is true, then I do not see how E_UNEXPECTED would be matched, since that is 0x8000FFFF. Also, it's unclear whether x1 and x2 are meant to be 0x800..... values, or some sort of truncated version.
Finally, this code treats all-but-one of the success values as errors. Other pages on the same MSDN guide say that SUCCEEDED(hr) or FAILED(hr) should be used to determine between a success or failure.
So, is this code sample really the "recommended way" or is this some sort of documentation blunder?
This is (pretty) old stuff. The winerror.h file in the SDK says this:
////////////////////////////////////
// //
// COM Error Codes //
// //
////////////////////////////////////
//
// The return value of COM functions and methods is an HRESULT.
// This is not a handle to anything, but is merely a 32-bit value
// with several fields encoded in the value. The parts of an
// HRESULT are shown below.
//
// Many of the macros and functions below were orginally defined to
// operate on SCODEs. SCODEs are no longer used. The macros are
// still present for compatibility and easy porting of Win16 code.
// Newly written code should use the HRESULT macros and functions.
//
I think it's pretty clear. I would trust the SDK first, and the doc after that.
We can see SCODE is consistently defined like this in WTypesbase.h (in recent SDKs, in older SDKs, I think it was in another file):
typedef LONG SCODE;
So it's really a 32-bit.
The text is correct; one should be wary of blindly returning failure codes from internal functions, particularly if your code uses a facility code defined elsewhere in the system.
Specifically, at the COM interface function level, you should ensure that the error codes you're returning are meaningful for your interface, and you should remap errors that originate from inside the function to meaningful error codes.
Practically speaking, however, nobody does this, which is why you see bizarre and un-actionable error dialogs like "Unexpected error".
I wrote a very simple code that reads and writes from a card. I got an error:
An unhandled exception of type
'System.Runtime.InteropServices.MarshalDirectiveException' occured in
ReadandWrite.exe
Additional information: PInvoke restriction: can not return variants.
Code Snippet:
Console.WriteLine("Address = 0x3c3, Value = 0x", MX4.r_1byte(963).ToString)
I am trying to understand the error and how to fix it.
Sounds like you're forgetting to declare an Interop Type for one or more of your Public methods/properties. See this MSDN thread.
i'm talking to a COM object (Microsoft ADO Recordset object). In a certain case the recordset will return a failed (i.e. negative) HRESULT, with the message:
Item cannot be found in the collection
corresponding to the requested name or
ordinal
i know what this error message means, know why it happened, and i how to fix it. But i know these things because i read the message, which fortunately was in a language i understand.
Now i would like to handle this exception specially. The COM object threw an HRESULT of
0x800A0CC1
In an ideal world Microsoft would have documented what errors can be returned when i try to access:
records.Fields.Items( index )
with an invalid index. But they do not; they most they say is that an error can occur, i.e.:
If Item cannot find an object in the
collection corresponding to the Index
argument, an error occurs.
Given that the returned error code is not documented, is it correct to handle a specific return code of `0x800A0CC1' when i'm trying to trap the exception:
Item cannot be found in the collection
corresponding to the requested name or
ordinal
?
Since Microsoft didn't document the error code, they technically change it in the future.
They did document this error code, but it's hard to find:
ErrorValueEnum:
adErrItemNotFound 3265 -2146825023 0x800A0CC1 Item cannot be found in the collection that corresponds to the requested name or ordinal.
..so, as its' a documented error code, it is safe to test for it explicitly.
You'll have to decide whether or not it is worth the risk, but I believe that it is unlikely that Microsoft will change this error code. Checking for this particular error code is a pretty robust way to go.
Yes, it is fine. It is in fact a documented error code, although finding them is never easy. It is defined in the msdao15.idl Windows SDK file, adErrItemNotFound (error 3265)
I'm evaluating Server 2008. My C++ executable is getting this error. I've seen this error on MSDN that seems to have required a hot-fix for several previous OSes. Anyone else seen this? I get the same results for the 32 & 64 bit OS.
Code snippet:
HRESULT GroupStart([in] short iClientId, [in] VARIANT GroupDataArray,
[out] short* pGroupInstance, [out] long* pCommandId);
Where the GroupDataArray VARIANT argument wraps a single-dimension SAFEARRAY of VARIANTs wrapping a DCAPICOM_GroupData struct entries:
// DCAPICOM_GroupData
[
uuid(F1FE2605-2744-4A2A-AB85-1E1845C280EB),
helpstring("removed")
]
typedef struct DCAPICOM_GroupData {
[helpstring("removed")]
long m_lImageID;
[helpstring("removed")]
unsigned char m_ucHeadID;
[helpstring("removed")]
unsigned char m_ucPlateID;
} DCAPICOM_GroupData;
After opening a support case with Microsoft, I can now answer my own question. This is (now) a recognized bug. The issue has to do with marshalling on the server side, but before the server code is called. Our structure is 6 bytes long, but this COM implementation is interpreting it as 8, so the marshalling fails, and this is the error you get back. The workaround, until a Service Pack is released to deal with this, is to add two extra bytes to the structure to pad it up to 8 bytes. We haven't run across any more instances that fail yet, but we still have a lot of testing to do still.
We ran into the same error recently with a client/server app communicating via DCOM. It turned out that the size of a marshalled interface pointer going across the wire (i.e., not local) had changed (gotten bigger). You might like to check whether your code is doing any special marshalling via CoMarshalInterface or the like.