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 for DISP_E_UNKNOWNLCID is that the target does not recognize or support the supplied LCID for the requested operation. A diagnostic event for DISP_E_UNKNOWNLCID should retain both representations of the HRESULT and the exact API boundary that produced it.

Where the result appears

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

Before assigning cause to DISP_E_UNKNOWNLCID, 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 DISP_E_UNKNOWNLCID 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 DISP_E_UNKNOWNLCID are alternatives, so test one precondition at a time instead of applying several broad repairs together.

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

Evidence and telemetry

  • Record DISP_E_UNKNOWNLCID with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
  • For DISP_E_UNKNOWNLCID, 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 DISP_E_UNKNOWNLCID, but redact actual confidential argument values.
  • Preserve the caller language/runtime, generated interop version, LCID, and whether the call crossed a process boundary when DISP_E_UNKNOWNLCID occurs.
  • After DISP_E_UNKNOWNLCID, call VariantClear, SysFreeString, SafeArrayDestroy, or release interfaces only for values whose ownership was transferred by the documented contract.

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

Diagnostic sequence

  • Capture DISP_E_UNKNOWNLCID (0x8002000C) at IDispatch::GetIDsOfNames or IDispatch::Invoke before the language runtime converts it to a script exception.
  • For <code>DISP_E_UNKNOWNLCID</code>, resolve the deployed member signature from ITypeInfo and compare its DISPIDs, parameter flags, VARTYPEs, optional values, and property-put rules with the caller.
  • Prove the decisive condition for DISP_E_UNKNOWNLCID: the target does not recognize or support the supplied LCID for the requested operation.
  • Inspect the likely binding or representation causes for DISP_E_UNKNOWNLCID: an invalid LCID is passed; the component supports only invariant or installed locales; a remote system lacks the locale data.
  • Reconstruct DISPPARAMS exactly, including reverse positional ordering and named argument placement, then reproduce DISP_E_UNKNOWNLCID with the smallest value set.
  • Verify the result VARIANT, EXCEPINFO, puArgErr, by-reference arguments, SAFEARRAY lock count, and object state after DISP_E_UNKNOWNLCID before deciding on retry.

Correct handling and recovery

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

For DISP_E_UNKNOWNLCID, 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 DISP_E_UNKNOWNLCID 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; DISP_E_UNKNOWNLCID occurs during live Automation dispatch.

Keeping DISP_E_UNKNOWNLCID 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 DISP_E_UNKNOWNLCID at the dispatch boundary and expose the member, parameter, and type information needed to repair the call. A generic retry after <code>DISP_E_UNKNOWNLCID</code> with unchanged DISPPARAMS usually repeats the same deterministic binding error.

For DISP_E_UNKNOWNLCID, deployment owners should compare the registered type library and server binary as one versioned unit. After <code>DISP_E_UNKNOWNLCID</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.