What does HRESULT 0x8004D080 (XACT_E_CLERKNOTFOUND) mean?

 
Previous Next
XACT_E_LU_TX_DISABLED XACT_E_CLERKEXISTS

XACT_E_CLERKNOTFOUND

XACT_E_CLERKNOTFOUND is the failure HRESULT 0x8004D080 (signed decimal -2147168128, unsigned decimal 2147799168). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD080.

The requested recovery clerk is absent from the current recovery context

The public Windows message text for this HRESULT repeats only the symbolic name. The SDK places the 0x8004D080 range under “TXF & CRM errors,” so the precise emitting API is not publicly established by the message alone. The safe interpretation is that code dealing with a recovery clerk could not locate the requested clerk identity.

AllStat records the Windows message as: “XACT_E_CLERKNOTFOUND” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.

The contract boundary to identify

COM+ Compensating Resource Manager documentation uses clerks to hold durable log records for a transaction and exposes monitoring interfaces for clerk state. A concrete diagnosis still requires the returning interface, clerk identifier, transaction UOW, and product component; the constant name is not enough to claim a particular method.

Likely causes to separate

  • The caller uses a clerk identifier from a previous process, transaction, or recovery generation.
  • Recovery or cleanup has already removed the clerk before monitoring or replay code queries it.
  • A race exists between clerk enumeration and a later lookup.
  • The application expects CRM infrastructure on a code path that did not register or durably create a clerk.

Evidence worth preserving

  • Log the exact interface and method returning the HRESULT, clerk identifier, transaction UOW, and process identity.
  • Capture clerk enumeration immediately before lookup and note recovery or cleanup events between the calls.
  • Preserve COM+ CRM event logs and component versions.
  • Record whether the query targets live processing, monitoring, or restart recovery.

Diagnostic sequence

  • Confirm that the clerk was created and registered in the same transaction context expected by the caller.
  • Avoid retaining monitor objects or clerk identifiers across COM+ application restarts.
  • Serialize enumeration and lookup if the API contract does not guarantee a stable snapshot.
  • If the product is not using COM+ CRM, identify the actual TXF/CRM owner from the call stack before applying CRM-specific remediation.

Retry and recovery

Refresh the clerk inventory and reacquire the object from the current recovery context. Do not fabricate a clerk or delete logs to bypass the lookup. If the transaction is incomplete, preserve durable records until the owning component determines the correct recovery action.

What this HRESULT does not establish

Microsoft’s public message does not state whether the missing clerk is a CRM monitor object, an internal TXF object, or another component in the shared range. The page therefore cannot name a guaranteed API owner without runtime evidence.

Difference from nearby transaction results

XACT_E_CLERKEXISTS represents the opposite identity conflict. XACT_E_RECOVERYINPROGRESS indicates that recovery activity, rather than absence alone, blocks the requested operation.

Practical scenario

A monitoring service caches a CRM clerk identifier, then the COM+ application completes recovery and removes that clerk. A later detail request returns this HRESULT. The monitor refreshes its snapshot and reports that the previous object is no longer current.

Guidance for software and telemetry

Treat clerk identifiers as generation-scoped. Include the returning interface in telemetry because it is the evidence needed to distinguish public CRM usage from an internal transaction subsystem.

Official Microsoft references

Looking for a different code? Search another status or error code.