| Previous | Next |
| XACT_E_CLERKNOTFOUND | XACT_E_RECOVERYINPROGRESS |
XACT_E_CLERKEXISTS
XACT_E_CLERKEXISTS is the failure HRESULT 0x8004D081 (signed decimal -2147168127, unsigned decimal 2147799169). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD081.
Recovery-clerk creation conflicts with an existing identity
The Windows SDK provides no prose beyond the symbolic name and groups this value with TXF and CRM errors. The name indicates that an operation expected to create or register a clerk encountered an existing clerk, but the exact interface and uniqueness scope must be obtained from the caller.
AllStat records the Windows message as: “XACT_E_CLERKEXISTS” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
In COM+ CRM, a clerk is associated with durable records and a transaction context. Reusing an identifier can represent duplicate initialization, recovery replay, or stale process state. It should not be solved by deleting the existing clerk until ownership and transaction outcome are known.
Likely causes to separate
- Initialization executes twice for the same transaction or recovery identity.
- A restarted component creates a new clerk before reconnecting to durable state left by the previous instance.
- Two workers race to register the same logical recovery participant.
- A test or deployment reuses identifiers that were assumed to be globally fresh.
Evidence worth preserving
- Record the returning method, requested clerk identity, existing clerk metadata, transaction UOW, and application instance.
- Capture which process created the existing object and whether it still owns active recovery work.
- Preserve the sequence of registration, log writes, force-to-disk operations, and restart events.
- Check for duplicate activation or retry after an ambiguous timeout.
Diagnostic sequence
- Determine whether the existing clerk is the object the caller should reuse or a genuine conflicting instance.
- Make clerk registration idempotent at the application level when the API permits reacquisition.
- Serialize startup and recovery ownership so only one component creates the participant.
- Do not purge the existing durable log until its transaction outcome and compensation records are understood.
Retry and recovery
Reacquire the existing clerk when it belongs to the same recovery generation, or resolve the duplicate owner before creating another. A retry with the same identity and unchanged state will repeat the conflict.
What this HRESULT does not establish
The public constant does not define the identifier format, namespace, or exact API. It also does not prove that the existing clerk is healthy or safe to reuse.
Difference from nearby transaction results
XACT_E_CLERKNOTFOUND occurs when lookup cannot find the requested identity. XACT_E_TRANSACTIONCLOSED concerns transaction lifecycle rather than identity uniqueness.
Practical scenario
Two service instances start after failover and both attempt to create the same recovery participant. One succeeds and the other receives this HRESULT. Leader election is fixed, and the second instance attaches to monitoring rather than modifying durable records.
Guidance for software and telemetry
Use stable transaction correlation plus a separate process-generation identifier. Logs should show both the requested identity and the owner of the existing clerk.
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.