| Previous | Next |
| XACT_E_RECOVERYINPROGRESS | XACT_E_INVALIDLSN |
XACT_E_TRANSACTIONCLOSED
XACT_E_TRANSACTIONCLOSED is the failure HRESULT 0x8004D083 (signed decimal -2147168125, unsigned decimal 2147799171). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD083.
The recovery or logging operation targets a closed transaction
Microsoft’s public message table repeats only the constant name and places the range under TXF and CRM errors. The symbolic meaning indicates that the transaction context used by the operation has closed, so later log, replay, or clerk activity cannot assume an active transaction.
AllStat records the Windows message as: “XACT_E_TRANSACTIONCLOSED” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
A closed transaction can have committed, aborted, or completed its recovery lifecycle. The HRESULT does not reveal which terminal outcome occurred. Callers must use the transaction UOW and coordinator or CRM state to determine whether cleanup, compensation, or simple object release is appropriate.
Likely causes to separate
- A worker writes or forces a CRM log record after transaction completion has begun.
- An asynchronous callback retains a transaction-bound object beyond its valid lifetime.
- Recovery code reuses a clerk or log-control object from an earlier transaction generation.
- Concurrent completion closes the transaction between a state check and the requested operation.
Evidence worth preserving
- Record the returning method, transaction UOW, last known outcome, clerk identity, and object creation time.
- Capture commit, abort, timeout, and recovery events that precede the first closed-state result.
- Log thread ownership and callbacks that retain transaction-scoped interfaces.
- Preserve whether durable records were already forced before closure.
Diagnostic sequence
- Stop using the transaction-bound object and query the authoritative terminal outcome.
- Audit lifetime management so callbacks cannot outlive the transaction context they reference.
- Reacquire current monitoring objects rather than reusing a closed clerk or log-control interface.
- Reconcile any unprotected side effect attempted after closure.
Retry and recovery
Release stale transaction-scoped interfaces and continue based on the confirmed terminal outcome. If new work is required, create a new transaction and do not attach old recovery identifiers unless the documented replay protocol calls for them.
What this HRESULT does not establish
The code does not say “committed” or “aborted,” and it should not be translated into either outcome. The public message also does not establish a specific CRM method as the source.
Difference from nearby transaction results
XACT_E_NOTRANSACTION is the general transaction-object result for work already committed or aborted. This later range should be diagnosed with the returning TXF/CRM interface and recovery context.
Practical scenario
A CRM worker queues a log write to another thread and returns. The transaction completes before that thread uses the log-control object, which then reports a closed transaction. The implementation moves durable logging into the valid transaction phase and cancels late callbacks.
Guidance for software and telemetry
Attach explicit lifetime state to transaction-bound objects. Telemetry should include the last valid phase and terminal outcome source rather than only the later closed-state HRESULT.
Official Microsoft references
- Microsoft: COM transaction error codes
- Microsoft: HRESULT values in MS-ERREF
- Microsoft: COM+ Compensating Resource Manager
- Microsoft: ICrmLogControl
- Microsoft: ITransaction
Looking for a different code? Search another status or error code.