| Previous | Next |
| XACT_E_INVALIDLSN | SL_REMAPPING_SP_STATUS_SYSTEM_TIME_SKEWED |
XACT_E_REPLAYREQUEST
XACT_E_REPLAYREQUEST is the failure HRESULT 0x8004D085 (signed decimal -2147168123, unsigned decimal 2147799173). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD085.
Recovery requires a controlled replay path rather than ordinary transaction execution
The public Windows message provides no prose beyond XACT_E_REPLAYREQUEST, and the SDK groups the range with TXF and CRM errors. The name points to replay during recovery, but the HRESULT alone does not define whether it is a command, a required state transition, or a rejection returned by a particular interface.
AllStat records the Windows message as: “XACT_E_REPLAYREQUEST” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
COM+ CRM recovery replays durable log records to a compensator so incomplete work can be completed or compensated. Replay is not equivalent to rerunning the original business request: it must preserve record order, transaction identity, and the compensator’s documented phases.
Likely causes to separate
- Recovery infrastructure determines that durable records must be replayed after restart or failover.
- A component invokes a normal execution path when the current object expects recovery replay.
- A replay cursor or request is duplicated because completion acknowledgement was lost.
- Version skew prevents the compensator from understanding the durable record sequence.
Evidence worth preserving
- Identify the returning interface, transaction UOW, clerk, replay generation, and first requested log record.
- Capture durable record order and compensator version while protecting record payloads.
- Record the recovery phase and whether replay was requested once or repeatedly.
- Preserve the original transaction outcome and any already applied compensation.
Diagnostic sequence
- Verify that the correct compensator and record format are registered for the clerk.
- Process replay only through the documented recovery interface and in durable log order.
- Make compensation idempotent so a repeated request cannot apply the inverse action twice.
- Do not submit the original user operation as a substitute for replay.
Retry and recovery
Enter the component’s supported replay procedure, track each durable record, and persist completion before clearing recovery state. If the emitting API is not CRM, use the call stack and owner documentation to identify the applicable TXF/CRM replay contract before acting.
What this HRESULT does not establish
The constant’s public description is limited, so it cannot prove that replay has started, succeeded, or failed. It also does not authorize deleting log records to suppress repeated requests.
Difference from nearby transaction results
XACT_E_RECOVERYINPROGRESS indicates an active recovery pass. XACT_E_INVALIDLSN identifies an unusable log position that can prevent replay from locating the correct record.
Practical scenario
After a crash, COM+ creates the compensator and requests replay of durable CRM records. Application code mistakenly routes the event to its normal command handler. The implementation separates recovery callbacks, replays records idempotently, and records completion before the clerk is released.
Guidance for software and telemetry
Telemetry must distinguish replay generation, record sequence, and business operation. Redact payloads but retain hashes so duplicate or missing recovery records can be proven.
Official Microsoft references
- Microsoft: COM transaction error codes
- Microsoft: HRESULT values in MS-ERREF
- Microsoft: COM+ Compensating Resource Manager
- Microsoft: ICrmLogControl
- Microsoft: ICrmLogControl::WriteLogRecord
Looking for a different code? Search another status or error code.