| Previous | Next |
| CO_E_NOT_SUPPORTED | CO_E_MSI_ERROR |
CO_E_RELOAD_DLL
COM requires a DLL to be loaded again
CO_E_RELOAD_DLL is HRESULT 2147500066 (0x80004022) from winerror.h. AllStat describes it as “A dll must be loaded.” The value must be interpreted at in-process COM server loading, unloading, or class-factory resolution, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the runtime determined that the required DLL is not resident in the usable state and must be loaded before continuing. When this result crosses a language or process boundary, preserve its original numeric form before projections replace it with a broad exception class.
Where the result appears
- This result may surface in in-process COM server loading, unloading, or class-factory resolution.
- The first boundary to preserve for it is the exact activation, initialization, call-control, or lifetime step that returned it.
- record whether the failure occurred before an object identity existed, while a method was running, or during shutdown; those phases imply different ownership and retry rules.
Triage of this result starts by locating the exact owner of the failing state, including object identity, apartment, package, and deployment generation.
Typical causes and interpretation boundary
Common cause categories for it are: the module was unloaded after class factories were released; dependency resolution changed; registration points to a replaced binary. Do not treat the cause list for it as a checklist of simultaneous failures; use traces and postconditions to select the matching branch.
The check that separates this result from nearby HRESULTs is: the runtime determined that the required DLL is not resident in the usable state and must be loaded before continuing. A recovery decision for it should wait until the decisive condition is observed in call data, component state, or metadata.
Correct handling and recovery
The appropriate recovery is to allow COM to perform a clean reload, keep class factories and module locks balanced, and investigate repeated unload/reload churn rather than pinning the DLL forever. A retry policy for it needs a bounded attempt count, a state refresh step, and a rule for reconciling work that may already have completed.
Cleanup following it must be generation-aware: do not destroy shared state or outputs owned by an earlier successful operation.
Practical scenario
A server releases its final module lock just before another activation; COM reloads the registered DLL and obtains a fresh class factory.
Coverage for it should include the exact failure, a corrected success case, and the closest related HRESULT so classification remains stable.
Difference from related HRESULTs
CO_E_DLLNOTFOUND means the module cannot be found; it indicates the runtime needs a valid reload.
Tests and telemetry should encode the boundary around it so future wrappers do not flatten it into an ambiguous generic exception.
Developer and administrator guidance
Code handling it should classify it by lifecycle and ownership rather than by the high bit alone. For <code>it</code>, initialization failures normally require rebuilding the process or thread environment, capability results require a fallback, and uncertain remote outcomes require reconciliation before retry.
Operational dashboards should keep it distinct from generic COM failures and attach deployment, service, package, runtime, policy, and architecture dimensions. Administrators should avoid broad registry edits, blanket firewall changes, or permission expansion unless the captured evidence for it identifies that subsystem.
References
- Microsoft: COM processes, threads, and apartments
- Microsoft: CoInitializeEx
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.