| Previous | Next |
| XACT_E_UNABLE_TO_READ_DTC_CONFIG | XACT_E_ABORTING |
XACT_E_UNABLE_TO_LOAD_DTC_PROXY
XACT_E_UNABLE_TO_LOAD_DTC_PROXY is the failure HRESULT 0x8004D028 (signed decimal -2147168216, unsigned decimal 2147799080). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xD028.
The DTC proxy component could not be loaded into the caller
This HRESULT states that MSDTC was unable to load the DTC proxy DLL. The proxy exposes transaction-manager interfaces to application and resource-manager processes, so failure occurs before ordinary transaction creation, import, enlistment, or outcome processing can proceed through that client path.
AllStat records the Windows message as: “MSDTC was unable to load the dtc proxy dll.” This text should be interpreted at the transaction stage described below rather than as a generic COM failure.
The contract boundary to identify
The result points to component loading, not remote coordinator reachability. File presence alone is insufficient: architecture, registration, dependencies, integrity, code-loading policy, and process bitness can all affect whether the proxy loads correctly.
Likely causes to separate
- The proxy binary or a dependency is missing, damaged, or mismatched with the operating-system component set.
- A 32-bit or 64-bit process resolves an incorrect component registration or unsupported binary path.
- Application-control, antivirus, or code-integrity policy blocks the DLL load.
- An incomplete servicing, rollback, or system-file repair leaves DTC proxy registration inconsistent.
Evidence worth preserving
- Record process architecture, executable path, Windows build, and the first loader error beneath the HRESULT.
- Capture module-load and code-integrity events for the affected process.
- Compare behavior in another native process of the same bitness without copying system DLLs manually.
- Preserve servicing history and component-store health results.
Diagnostic sequence
- Use supported system integrity tools and event logs to identify missing or blocked DTC components.
- Check both architecture-specific registration views when only one process bitness fails.
- Review application-control rules before granting exclusions to a system transaction component.
- After repair, verify acquisition of DTC interfaces before running a distributed business transaction.
Retry and recovery
Repair the Windows component or policy that prevents proxy loading, restart the affected process, and test transaction initialization. Do not download or copy a proxy DLL from another computer; version and servicing mismatches can damage the transaction stack.
What this HRESULT does not establish
The code does not prove that the MSDTC service is stopped or that network communication is blocked. It also does not identify the missing dependency without the underlying loader status.
Difference from nearby transaction results
XACT_E_UNABLE_TO_READ_DTC_CONFIG concerns configuration access. CO_E_DLLNOTFOUND is a broader COM activation result, whereas this constant names the DTC proxy layer.
Practical scenario
Only a legacy 32-bit service fails to initialize distributed transactions after an image repair. Loader telemetry shows its architecture-specific DTC proxy registration is inconsistent. Supported component repair restores the correct proxy, and interface acquisition succeeds before the service resumes work.
Guidance for software and telemetry
Preserve the underlying loader code and module path in telemetry. Generic retry loops can repeatedly crash or stall a process without changing the component state.
Official Microsoft references
- Microsoft: COM transaction error codes
- Microsoft: DTC interfaces
- Microsoft: enable MSDTC diagnostic tracing
- Microsoft: MSDTC security and network access
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.
