What does HRESULT 0x8002000C (DISP_E_UNKNOWNLCID) mean?

 
Previous Next
DISP_E_BADINDEX DISP_E_ARRAYISLOCKED

DISP_E_UNKNOWNLCID

Automation call uses an unsupported locale identifier

DISP_E_UNKNOWNLCID is HRESULT 2147614732 (0x8002000C) from winerror.h. AllStat describes it as “Unknown language.” The value must be interpreted at IDispatch name lookup or invocation that requests locale-sensitive conversion, because the same high-level symptom can come from a different contract boundary and require different cleanup.

The decisive Interpretation is that the target does not recognize or support the supplied LCID for the requested operation. A diagnostic event for it should retain both representations of the HRESULT and the exact API boundary that produced it.

Where the result appears

  • This result is returned while Automation binds or executes IDispatch name lookup or invocation that requests locale-sensitive conversion.
  • retain the member name and DISPID, invocation flags, LCID, cArgs, cNamedArgs, and the exact VARIANTARG sequence in reverse Automation order.
  • The output contract for it includes puArgErr, EXCEPINFO, result VARIANT, by-reference values, and SAFEARRAY lock or ownership state; inspect them before cleanup.

Before assigning cause to this result, identify the responsible thread, apartment, process, library generation, and server instance rather than relying on the final dialog text.

Typical causes and interpretation boundary

Common cause categories for it are: an invalid LCID is passed; the component supports only invariant or installed locales; a remote system lacks the locale data. The candidate causes for it are alternatives, so test one precondition at a time instead of applying several broad repairs together.

The check that separates this result from nearby HRESULTs is: the target does not recognize or support the supplied LCID for the requested operation. When the boundary condition behind it has not been proven, avoid retries or repairs that assume a different neighboring HRESULT.

Evidence and telemetry

  • Record this result with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
  • capture LCID value; user and system locale; target-supported locales; conversion being attempted; type-library locale.
  • Log VARIANT type tags, dimensions, bounds, lengths, and null/empty distinctions for it, but redact actual confidential argument values.
  • Preserve the caller language/runtime, generated interop version, LCID, and whether the call crossed a process boundary when it occurs.
  • After it, call VariantClear, SysFreeString, SafeArrayDestroy, or release interfaces only for values whose ownership was transferred by the documented contract.

Telemetry for it should be reproducible without copying secret values: prefer GUIDs, lengths, flags, sanitized names, and correlation IDs.

Correct handling and recovery

The appropriate recovery is to use a documented supported LCID, prefer invariant typed values, and avoid guessing locale from display language. Before retrying it, specify which precondition changed and how duplicate effects or stale outputs will be detected.

Inspect every output before cleanup because interfaces, buffers, server effects, or metadata handles may be partially initialized.

Practical scenario

A client passes a custom LCID copied from configuration; switching to the application’s supported locale restores name lookup.

Test it by reproducing the smallest failing contract, recording postconditions, and then changing a single input or state transition.

Difference from related HRESULTs

TYPE_E_UNKNOWNLCID occurs while loading or creating type information; it occurs during live Automation dispatch.

Keeping it separate from its neighbor improves retry, cleanup, and user messaging because the two results imply different postconditions.

Developer and administrator guidance

Automation adapters should handle it at the dispatch boundary and expose the member, parameter, and type information needed to repair the call. A generic retry after <code>it</code> with unchanged DISPPARAMS usually repeats the same deterministic binding error.

Deployment owners should compare the registered type library and server binary as one versioned unit. After <code>it</code>, re-registering arbitrary DLLs or changing locale system-wide is inappropriate unless the captured metadata proves registration or LCID drift.

References

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