| Previous | Next |
| TYPE_E_NAMECONFLICT | TYPE_E_DLLFUNCTIONNOTFOUND |
TYPE_E_UNKNOWNLCID
Type library does not support the requested LCID
TYPE_E_UNKNOWNLCID is HRESULT 2147647534 (0x8002802E) from winerror.h. AllStat describes it as “Unknown LCID.” The value must be interpreted at type-library loading, creation, documentation lookup, or name resolution using locale metadata, because the same high-level symptom can come from a different contract boundary and require different cleanup.
Diagnostic discriminator: Microsoft describes this condition as “Unknown LCID.” Use that exact state to separate the value from nearby results in the same subsystem.
The decisive Interpretation is that the specified locale identifier is unknown or unavailable for the library operation. Treat this result as a contract result from its owning subsystem and retain the unmodified HRESULT in logs and test assertions.
Where the result appears
- This result belongs to type-library and metadata processing around type-library loading, creation, documentation lookup, or name resolution using locale metadata.
- identify the LIBID, major/minor version, LCID, SYSKIND, file path, resource ID, and the specific ITypeLib or ITypeInfo operation.
- Metadata consumers should treat this result as a contract-version or construction problem until file integrity, registry view, import dependencies, TYPEKIND, and builder phase are verified.
Map this result to one concrete invocation and one concrete object or metadata identity before interpreting the human-readable description.
Typical causes and interpretation boundary
Common cause categories for this HRESULT are: the LCID is invalid; localized resources are absent; a generator writes a locale not supported by the target system. The evidence should distinguish configuration, lifetime, input, identity, resource, and version failures rather than grouping them.
The check that separates it from nearby HRESULTs is: the specified locale identifier is unknown or unavailable for the library operation. The text of it narrows the search, but the owning API state must confirm the condition before automation changes the system.
Evidence and telemetry
- Record it with the type-library path and hash, LIBID and version, LCID, architecture, source package, and producer toolchain.
- capture LCID; library SYSKIND and version; available locale resources; user/system locale; documentation strings requested.
- Retain the exact type, member, field, name, MEMBERID, HREFTYPE, TYPEKIND, or registry path involved in it.
- When it is produced during generation, record construction order, imported libraries, layout/finalization state, and output TLB hash.
- After it, release TYPEATTR, FUNCDESC, VARDESC, BSTR, and interface resources using the matching API even when parsing or lookup fails.
For privacy-safe diagnosis of it, capture the call schema and state transitions but hash or omit confidential payloads.
Diagnostic sequence
- Capture it (0x8002802E) before a compiler, importer, or language runtime reduces it to a generic metadata error.
- Verify the exact type-library identity, file/resource loaded, registry view, architecture, and operation that returned it.
- Prove the decisive metadata condition for this HRESULT: the specified locale identifier is unknown or unavailable for the library operation.
- Test the likely causes independently for this HRESULT: the LCID is invalid; localized resources are absent; a generator writes a locale not supported by the target system.
- For <code>it</code>, enumerate the relevant TYPEATTR, members, imports, names, IDs, locales, and builder state instead of assuming source declarations match deployed metadata.
- Rebuild or reload one corrected metadata generation and verify that it disappears without introducing a different identity or compatibility break.
Correct handling and recovery
The appropriate recovery is to use a valid library-supported LCID, provide invariant metadata where appropriate, and avoid coupling type identity to UI language. Recovery from it should name the component responsible for retry and the evidence that makes another attempt safe.
The failure path for this HRESULT should leave outputs in a known state and avoid double release, double commit, or reuse of stale pointers.
Practical scenario
A browser requests help strings for an unavailable locale and falls back to the library’s neutral LCID.
To prevent recurrence of it, preserve a minimal fixture that asserts both the failing condition and the state after recovery.
Difference from related HRESULTs
DISP_E_UNKNOWNLCID occurs during runtime dispatch; it occurs while working with type metadata.
Classify it by the stated contract difference, since severity bits alone do not determine the correct response.
Developer and administrator guidance
Tools handling it should pin type-library identity and version, avoid caching raw indices across versions, and preserve stable GUIDs and DISPIDs for published contracts. Repair for <code>it</code> should be performed by the metadata producer or installer, not by ad hoc registry edits in the consuming process.
Administrators should compare installed files and registration against the product manifest, repair the matching package, and keep 32-bit and 64-bit registry views explicit. For <code>it</code>, copying a TLB from another machine can silence lookup while creating a more dangerous ABI mismatch.
References
Looking for a different code? Search another status or error code.