| Previous | Next |
| TYPE_E_UNSUPFORMAT | TYPE_E_LIBNOTREGISTERED |
TYPE_E_REGISTRYACCESS
OLE type-library registry access failed
TYPE_E_REGISTRYACCESS is HRESULT 2147647516 (0x8002801C) from winerror.h. AllStat describes it as “Error accessing the OLE registry.” The value must be interpreted at type-library registration, lookup, or unregistration in the Windows registry, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the operation could not read or modify the registry location used for type-library metadata. A diagnostic event for this HRESULT should retain both representations of the HRESULT and the exact API boundary that produced it.
Where the result appears
- This result belongs to type-library and metadata processing around type-library registration, lookup, or unregistration in the Windows registry.
- 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.
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 this HRESULT are: permissions deny access; the wrong WOW64 view is used; policy blocks writes; registry data is damaged or unavailable. The candidate causes for this HRESULT 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 operation could not read or modify the registry location used for type-library metadata. When the boundary condition behind it has not been proven, avoid retries or repairs that assume a different neighboring HRESULT.
Evidence and telemetry
- Record it with the type-library path and hash, LIBID and version, LCID, architecture, source package, and producer toolchain.
- capture registry path and view; user or machine scope; process bitness; access token; virtualization; underlying Win32 error.
- 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.
Telemetry for this HRESULT should be reproducible without copying secret values: prefer GUIDs, lengths, flags, sanitized names, and correlation IDs.
Diagnostic sequence
- Capture it (0x8002801C) 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 operation could not read or modify the registry location used for type-library metadata.
- Test the likely causes independently for this HRESULT: permissions deny access; the wrong WOW64 view is used; policy blocks writes; registry data is damaged or unavailable.
- 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 capture the underlying registry error, choose the correct scope and view, elevate only deployment tooling, and repair registration atomically. 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 32-bit installer writes only the 32-bit TypeLib view while a 64-bit client looks in the other view; the package registers both required views.
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_LIBNOTREGISTERED means lookup completed but no registration exists; it means the registry operation itself failed.
Keeping it separate from its neighbor improves retry, cleanup, and user messaging because the two results imply different postconditions.
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.