| Previous | Next |
| XACT_E_CLERKEXISTS | XACT_E_TRANSACTIONCLOSED |
XACT_E_RECOVERYINPROGRESS
XACT_E_RECOVERYINPROGRESS is the failure HRESULT 0x8004D082 (signed decimal -2147168126, unsigned decimal 2147799170). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD082.
The requested action conflicts with an active recovery pass
The public Windows text for this HRESULT supplies only its symbolic name, while the SDK groups the range with TXF and CRM errors. The name indicates an active recovery operation, but it does not publicly define which clerk, log, or transaction API returned the value.
AllStat records the Windows message as: “XACT_E_RECOVERYINPROGRESS” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
Recovery can replay durable records, resolve incomplete transactions, and rebuild in-memory ownership after restart. Starting another recovery pass or modifying the same records concurrently can break ordering. The correct response is coordination, not immediate business-operation retry.
Likely causes to separate
- A second component starts recovery while the first instance is still processing durable transaction state.
- Service startup and an administrative repair command overlap on the same log or clerk set.
- A previous recovery appears slow because it is waiting for an in-doubt transaction outcome.
- Automation interprets delayed completion as failure and launches a duplicate recovery worker.
Evidence worth preserving
- Identify the returning interface, active recovery owner, start time, transaction UOWs, and current phase.
- Capture progress events and the oldest record being replayed before deciding that recovery is stuck.
- Record service restarts, failovers, and administrative actions that could have launched parallel passes.
- Preserve DTC and CRM logs; deleting them removes the evidence needed to finish recovery.
Diagnostic sequence
- Confirm whether the active recovery worker is making progress or waiting for a known participant.
- Prevent additional instances from opening the same recovery scope for modification.
- Use supported monitoring interfaces to inspect clerks and records without taking ownership.
- Escalate only after collecting the transaction and log state required by the owning component.
Retry and recovery
Wait for the current recovery pass or resolve the condition blocking it, then retry the management action against the refreshed state. Do not terminate recovery merely to clear the HRESULT unless the product’s documented recovery procedure explicitly requires it.
What this HRESULT does not establish
The code does not prove deadlock, corruption, or permanent failure. It also does not identify whether the active work belongs to COM+ CRM or another TXF/CRM component in the shared SDK range.
Difference from nearby transaction results
XACT_E_REPLAYREQUEST suggests a request related to replay rather than an already active recovery owner. XACT_E_CLERKEXISTS identifies identity conflict without necessarily implying recovery is running.
Practical scenario
A cluster failover launches CRM recovery on the new owner. A health script times out and launches the same repair command, which receives this HRESULT. The duplicate command is removed, and monitoring waits for the original pass to resolve its in-doubt transaction.
Guidance for software and telemetry
Expose recovery owner, phase, age, and progress in telemetry. A generic “service busy” message hides whether waiting is safe or an in-doubt participant needs intervention.
Official Microsoft references
- Microsoft: COM transaction error codes
- Microsoft: HRESULT values in MS-ERREF
- Microsoft: COM+ Compensating Resource Manager
- Microsoft: COM+ interfaces in comsvcs.h
- Microsoft: enable MSDTC diagnostic tracing
Looking for a different code? Search another status or error code.