| Previous | Next |
| SL_REMAPPING_SP_STATUS_DEBUGGER_DETECTED | CONTEXT_E_ABORTING |
CONTEXT_E_ABORTED
CONTEXT_E_ABORTED is the failure HRESULT 0x8004E002 (signed decimal -2147164158, unsigned decimal 2147803138). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xE002.
The root component voted to finish, but the transaction could not commit
This result is observed at the automatic-transaction completion boundary. A root COM+ component may return success and call SetComplete, yet COM+ can replace that apparent success with this HRESULT when the coordinated transaction ultimately aborts.
AllStat describes the result as “The root transaction wanted to commit, but transaction aborted.” for it, this wording identifies the immediate COM+ condition, while surrounding context and earlier events determine why it was reached.
Contract boundary
The decisive event is the final outcome of the root transaction, not merely the return value produced inside the component method. Resource-manager votes, a timeout, a downstream abort vote, or an infrastructure failure can overturn a local commit vote after the business method has finished.
Causes that fit this specific result
- A participating database, queue, or other resource manager voted to abort during prepare.
- The automatic transaction exceeded its configured timeout before commit completed.
- Another component called
SetAbort, returned a failure under auto-done rules, or otherwise marked the transaction inconsistent. - MSDTC lost contact with an enlisted participant while resolving the final outcome.
Evidence to preserve before changing the system
- Capture the transaction identifier and correlate COM+, MSDTC, database, and message-queue events.
- Record each component vote and the first participant that reports rollback or prepare failure.
- Preserve the configured transaction timeout and the elapsed time from root activation to method return.
- Log whether the application originally returned success before COM+ substituted the final HRESULT.
Diagnostic sequence
- Treat the transaction outcome as aborted and do not publish side effects that assumed commit.
- Find the first abort vote or timeout rather than diagnosing only the root component.
- Reconcile external work that was not enlisted in the COM+ transaction before retrying.
- Repeat the business operation only with an idempotency key or a confirmed rollback state.
Retry and recovery
Correct the participant, timeout, or communication condition that caused the abort. A retry is safe only after the original unit of work is known not to have committed and nontransactional side effects have been reconciled.
What the result does not establish
The code does not prove that the root component explicitly requested rollback. It also does not identify which resource manager rejected the transaction.
Difference from nearby HRESULT values
CONTEXT_E_ABORTING is returned when another method is called while the transaction is already aborting. XACT_E_ABORTED is a transaction-manager result without the same COM+ root-return-value context.
Practical scenario
An order component updates SQL and enqueues a transactional message, calls SetComplete, and returns success. The queue resource manager rejects prepare, so COM+ changes the client-visible result to this HRESULT and the service records the transaction UOW before deciding whether the order may be retried.
Developer and telemetry guidance
Telemetry should distinguish the method result, the component vote, and the final coordinated outcome. Alert on the first participant failure, not on every root object that receives the propagated abort.
Official Microsoft references
- Microsoft: COM transaction and context error codes
- Microsoft: how COM+ modifies return values
- Microsoft: managing automatic COM+ transactions
- Microsoft: COM+ troubleshooting
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.