| Previous | Next |
| TYPE_E_UNKNOWNLCID | TYPE_E_BADMODULEKIND |
TYPE_E_DLLFUNCTIONNOTFOUND
Type-library referenced DLL function is missing
TYPE_E_DLLFUNCTIONNOTFOUND is HRESULT 2147647535 (0x8002802F) from winerror.h. AllStat describes it as “Function not defined in specified DLL.” The value must be interpreted at module type information or Automation metadata binding an entry point in a DLL, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the function declared by the type library cannot be found in the specified module exports. For reliable triage of this result, store the native HRESULT and symbolic identity before generic error handling rewrites either one.
Where the result appears
- This result belongs to type-library and metadata processing around module type information or Automation metadata binding an entry point in a DLL.
- 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.
The root-cause boundary for this HRESULT is the component that returned it, not the application screen on which the result was eventually displayed.
Typical causes and interpretation boundary
Common cause categories for this HRESULT are: the DLL version removed the export; name decoration differs; bitness is wrong; the type library and implementation are from different packages. Investigate this result through falsifiable cause hypotheses and keep the first lower-level failure that explains the observed HRESULT.
The check that separates it from nearby HRESULTs is: the function declared by the type library cannot be found in the specified module exports. Use the decisive condition for this HRESULT as a test assertion; if it cannot be asserted, diagnosis is not complete.
Evidence and telemetry
- Record it with the type-library path and hash, LIBID and version, LCID, architecture, source package, and producer toolchain.
- capture DLL path and version; function name or ordinal; architecture; export table; type-library declaration; dependency search path.
- 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.
Logs for this HRESULT should expose enough structure to reproduce the failure without becoming a secondary store of sensitive input data.
Diagnostic sequence
- Capture it (0x8002802F) 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 function declared by the type library cannot be found in the specified module exports.
- Test the likely causes independently for this HRESULT: the DLL version removed the export; name decoration differs; bitness is wrong; the type library and implementation are from different packages.
- 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 deploy matching DLL and TLB versions, inspect the real export table, and avoid search-path substitutions that load another module. Do not loop on it; retry only under a documented transient condition with bounded delay and post-operation reconciliation.
After observing it, separate local resource cleanup from server-side reconciliation and perform each only for the failing activity ID.
Practical scenario
A type library declares EntryPointA but the deployed DLL exports only EntryPointW; package versions are aligned.
The acceptance test for this HRESULT should prove that the proposed repair changes the predicted contract fact rather than merely hiding the message.
Difference from related HRESULTs
TYPE_E_LIBNOTREGISTERED concerns locating the library itself; it means the library loaded but its declared implementation entry point is absent.
Preserve the neighboring-result distinction for this HRESULT in metrics and incident reports to avoid applying the wrong remediation.
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.