| Previous | Next |
| XACT_S_ALLNORETAIN | XACT_S_SINGLEPHASE |
XACT_S_ABORTING
Transaction abort is already in progress
XACT_S_ABORTING is HRESULT 315400 (0x0004D008) from winerror.h. AllStat describes it as “An abort operation was already in progress.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the COM transaction and MSDTC protocol, this result means that an abort operation was already in progress. The application should preserve it until it has validated the exact condition represented by this return value.
What must be true before accepting it
Verify that the caller does not issue conflicting commit, enlist, or repeated abort operations while termination is underway. The documented condition must be demonstrated so this result is not mistaken for an unrelated success state.
Any state transition preceding this result must be included in rollback, continuation, and retry planning.
Where the status is encountered
- This result can be returned during ITransaction commit or abort processing; log the exact method and object state instead of interpreting the constant outside that contract.
- It can be returned during resource-manager enlistment and coordinated outcomes; log the exact method and object state instead of interpreting the constant outside that contract.
- It can be returned during transaction event-sink notification passes; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
Evidence and telemetry
- preserve unit of work.
- preserve abort initiator and reason.
- preserve current transaction phase.
- preserve outstanding resource callbacks.
- preserve terminal abort event.
Also record xact_s_aborting_operation, xact_s_aborting_state_before, xact_s_aborting_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Use redacted telemetry for this HRESULT, retaining only the stable technical identifiers that distinguish the operation.
Correct handling and recovery
Wait for the terminal abort result using the coordinator’s completion mechanism. Cancel dependent work and preserve the first reason that initiated abort.
Retry it only when a documented input or state has changed. Use the code-specific next action for this HRESULT; avoid treating all informational HRESULT values as retry signals.
Practical scenario
A timeout handler calls abort while another thread has already started it. The second thread receives this status and waits instead of racing a commit request.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
Comparing it with related statuses protects the caller from applying failure recovery to normal state.
References
- Microsoft: COM transaction status codes — official Microsoft material used to interpret it.
- Microsoft: ITransaction::Commit
- Microsoft: ITransaction::Abort
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.