HRESULT 0x80040E15 (DB_E_CANTCANCEL): meaning and diagnosis

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

Command cannot be canceled. OLE DB diagnosis and safe retry guidance.

Previous	Next
DB_E_ERRORSINCOMMAND	DB_E_DIALECTNOTSUPPORTED

DB_E_CANTCANCEL

Command cannot be canceled

Exact value and interpretation

DB_E_CANTCANCEL has the unsigned 32-bit value 2147749397 (0x80040E15) and the signed representation -2147217899. AllStat defines the result as “Command cannot be canceled”. In the concrete failure represented here, ICommand::Cancel or an asynchronous cancellation path cannot cancel the current operation.

The high bit is set for DB_E_CANTCANCEL, so it is a failure HRESULT rather than a success or informational status. Its facility field is 4 (FACILITY_ITF) and its low code is 3605 (0x0E15). Those bit fields place DB_E_CANTCANCEL in an interface-defined family, but they do not reveal the provider, object identity, method, rowset generation or command state that produced it.

OLE DB contract boundary

DB_E_CANTCANCEL must be interpreted against this contract: an OLE DB command moves through explicit states: command definition, properties and parameters are established before optional preparation and execution; dialect, query-tree and optimizer contracts are provider-specific and should be inferred only from reported capabilities.

Start with the active command object, its state transition history, dialect and provider error records when investigating DB_E_CANTCANCEL. Preserve DB_E_CANTCANCEL before ADO, ATL, .NET, a database abstraction layer or an application exception replaces it with a generic message; the exact interface and method matter because one OLE DB object can expose several contracts with different preconditions.

Evidence to collect before changing the system

A useful DB_E_CANTCANCEL record includes provider CLSID and version, process architecture, interface and method, COM apartment and thread, object correlation ID, transaction state, and the first preceding HRESULT. When DB_E_CANTCANCEL involves command text, parameter values, object names and query-plan details, record types, lengths, hashes or redacted identifiers instead of secrets or full business data.

Evidence 1 for DB_E_CANTCANCEL: the command identity and execution phase at cancellation time.
Evidence 2 for DB_E_CANTCANCEL: timestamps for Execute, Cancel and completion.
Evidence 3 for DB_E_CANTCANCEL: provider capability and any server-side request identifier.

Specific conditions that produce this result

Cause 1 for DB_E_CANTCANCEL: the provider does not support cancellation for this command phase.
Cause 2 for DB_E_CANTCANCEL: execution already completed before the cancel request arrived.
Cause 3 for DB_E_CANTCANCEL: the operation is inside a non-interruptible provider or server section.

Diagnostic sequence

Capture DB_E_CANTCANCEL immediately at the native OLE DB return and obtain the current OLE DB error object before another COM call replaces thread error information.
Identify the exact stage for DB_E_CANTCANCEL: ICommand::Cancel or an asynchronous cancellation path cannot cancel the current operation.
For DB_E_CANTCANCEL, compare the live command, rowset, accessor or schema state with the metadata and properties actually granted by the provider.
For DB_E_CANTCANCEL, inspect per-binding, per-property, per-row or per-record statuses whenever the method supplies them; the aggregate result may not identify the rejected element.
For DB_E_CANTCANCEL, reproduce the issue with the smallest command, rowset or definition operation that preserves the same contract boundary.
For DB_E_CANTCANCEL, apply one evidence-backed correction, then verify that the operation succeeds and does not merely change into a nearby HRESULT.

Retry and recovery policy

Retry rule for DB_E_CANTCANCEL: retrying Cancel is useful only if the operation remains active and the provider documents repeated cancellation; otherwise wait for the terminal result. A safe DB_E_CANTCANCEL retry must use a changed input, object generation, provider capability or state transition. If the call returning DB_E_CANTCANCEL could have created, updated, deleted or copied data, determine partial completion before replaying it.

For DB_E_CANTCANCEL, use bounded retries and preserve cancellation. For DB_E_CANTCANCEL, configuration and contract failures should normally fail fast; concurrency, resource or transient state failures may justify retry only after their stated precondition changes.

Corrective actions

Action 1 for DB_E_CANTCANCEL: treat cancellation as best effort and continue observing final completion.
Action 2 for DB_E_CANTCANCEL: avoid reusing or releasing shared state until the provider reports the final outcome.
Action 3 for DB_E_CANTCANCEL: use provider-specific cancellation only when officially supported.

Practical incident

A timeout thread calls Cancel after the provider has already finished but before the completion callback is processed; handling the final Execute result avoids misreporting DB_E_CANTCANCEL as a query failure. The diagnostic value comes from retaining DB_E_CANTCANCEL together with the failing interface and object state, not from reducing every provider result to “database error”.

Implementation guidance

Code handling DB_E_CANTCANCEL should release OLE DB resources in ownership order, preserve every provider error record, and log granted properties rather than only requested properties. When handling DB_E_CANTCANCEL, handles such as HACCESSOR, HROW, HCHAPTER and provider-specific region tokens must never be treated as portable integers across object lifetimes.

When DB_E_CANTCANCEL crosses an abstraction boundary, attach a stable correlation ID and structured fields for the native HRESULT, provider source, interface IID, method, object generation and operation phase. For DB_E_CANTCANCEL, do not log passwords, access tokens, complete SQL text or unrestricted row values merely to make the event easier to search.

Difference from related HRESULT values

DB_E_CANCELED reports that an operation was actually canceled, while DB_E_CANTCANCEL reports that cancellation could not be performed. Keep these outcomes separate in telemetry and user-facing remediation because DB_E_CANTCANCEL requires a different next action.

Official Microsoft references

Microsoft: OLE DB commands — official documentation relevant to DB_E_CANTCANCEL.
Microsoft: ICommand — official documentation relevant to DB_E_CANTCANCEL.
Microsoft: OLE DB command states — official documentation relevant to DB_E_CANTCANCEL.

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