HRESULT 0x80040E58 (DB_E_BADHRESULT): meaning and diagnosis

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

OLE DB rejected provider-side error metadata because the HRESULT stored in the error record is invalid for the error-object contract.

Previous	Next
DB_E_DATAOVERFLOW	DB_E_BADLOOKUPID

DB_E_BADHRESULT

Meaning

Windows documents DB_E_BADHRESULT as “HRESULT is invalid”. In this case, provider-side OLE DB error metadata contains an HRESULT that the error-object machinery considers invalid; the public contract does not identify a consumer data method.

Relevant contract

OLE DB error objects can contain multiple records. Provider-side error construction combines an HRESULT, lookup ID, optional parameters, custom error object and dynamic-error lifetime; each identifier has a different namespace and validation rule.

Investigation of this result should start with the provider code building or resolving the OLE DB error record and the exact IErrorRecords operation.

Diagnostic sequence

Identify the exact failing stage: provider-side OLE DB error metadata contains an HRESULT that the error-object machinery considers invalid; the public contract does not identify a consumer data method.

Conditions that specifically lead to it

Cause 1: an error record is built with a nonconforming return value.
Cause 2: memory corruption alters ERRORINFO.hrError.
Cause 3: a provider mixes a native status code with an HRESULT field without conversion.

Evidence to collect

A useful diagnostic event records provider CLSID and version, process architecture, interface IID and method, object correlation ID, transaction state and the immediately preceding HRESULT. When recording diagnostic data involving native database messages, error parameters and command fragments, use types, lengths, hashes or redacted identifiers rather than secrets or complete business data.

Evidence 1: the raw ERRORINFO structure before insertion.
Evidence 2: the provider code path constructing the error record.
Evidence 3: the original native status and conversion function.

Corrective actions

Action 1: store a valid HRESULT in ERRORINFO.hrError.
Action 2: validate provider-generated error records in tests.
Action 3: keep native status in provider-specific fields rather than overloading HRESULT.

Retry and recovery

Retry rule: retry only after correcting provider error-record construction; repeating the data operation is not a remedy.

Difference from nearby HRESULT values

DB_E_BADLOOKUPID concerns the message lookup key, while DB_E_BADHRESULT concerns the return-code field itself.

Practical scenario

A custom provider writes a database integer code directly into hrError; mapping it to a documented HRESULT restores error lookup. Keeping it with the method and object state makes this scenario diagnosable instead of reducing it to “database error”.

Official Microsoft references

Looking for a different code? Search another status or error code.