| Previous | Next |
| XACT_E_UNABLE_TO_LOAD_DTC_PROXY | XACT_E_PUSH_COMM_FAILURE |
XACT_E_ABORTING
XACT_E_ABORTING is the failure HRESULT 0x8004D029 (signed decimal -2147168215, unsigned decimal 2147799081). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD029.
The local transaction can no longer accept work because it is aborting
AllStat states that the local transaction has aborted. In practice the symbolic name emphasizes abort processing: the current transaction must not be treated as active or eligible for new resource work, commit, or propagation.
AllStat records the Windows message as: “The local transaction has aborted.” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
The result is about the transaction’s state, not the original cause of abort. A timeout, explicit application decision, participant failure, deadlock, or coordinator policy may have initiated the abort; the HRESULT seen by a later caller is secondary evidence.
Likely causes to separate
- Another participant or the application already requested abort.
- A transaction timeout triggered coordinator abort while work was still running.
- A resource manager failed prepare or lost the ability to guarantee its vote.
- Concurrent code continues using a transaction object after cancellation or failure.
Evidence worth preserving
- Record transaction UOW, first abort signal, timeout, participant list, and final known outcome.
- Capture the earliest failure or vote rather than only repeated calls that observe the aborting state.
- Log which thread attempted the rejected operation and whether it owned cancellation.
- Preserve resource-specific rollback and compensation results.
Diagnostic sequence
- Stop issuing new work on the transaction and notify all owners of the shared context.
- Find the first abort cause in coordinator, application, and resource-manager logs.
- Wait for or query the terminal outcome before releasing durable recovery information.
- Reconcile external side effects that were not protected by the transaction.
Retry and recovery
Dispose of the aborted transaction context and start a new business attempt only after the original outcome and side effects are understood. Retry must be idempotent or guarded by a durable operation key; an abort does not automatically undo nontransactional calls.
What this HRESULT does not establish
The HRESULT does not identify who requested abort or why. It also does not mean the transaction is merely “busy,” and a commit retry on the same object is not a valid recovery action.
Difference from nearby transaction results
XACT_E_ABORTED explicitly says the transaction has already been aborted. XACT_E_INDOUBT means the final outcome cannot be established, which requires different reconciliation.
Practical scenario
A request exceeds its transaction deadline, and MSDTC begins abort. A worker thread then tries to enlist another resource and receives this result. The service stops the workflow, waits for rollback completion, and retries under a new idempotency key only after checking external effects.
Guidance for software and telemetry
Design one owner for transaction cancellation and propagate state changes to all workers. Dashboards should count the initiating abort reason separately from later XACT_E_ABORTING observations.
Official Microsoft references
- Microsoft: COM transaction error codes
- Microsoft: ITransaction
- Microsoft: OleTx transaction protocol
- Microsoft: enable MSDTC diagnostic tracing
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.