| Previous | Next |
| TYPE_E_DLLFUNCTIONNOTFOUND | TYPE_E_SIZETOOBIG |
TYPE_E_BADMODULEKIND
Type-library module kind is invalid for the operation
TYPE_E_BADMODULEKIND is HRESULT 2147649725 (0x800288BD) from winerror.h. AllStat describes it as “Wrong module kind for the operation.” The value must be interpreted at type-library creation or inspection of modules, interfaces, dispatch interfaces, coclasses, and records, because the same high-level symptom can come from a different contract boundary and require different cleanup.
Code-specific check: The defining condition is “Wrong module kind for the operation.” Confirm that condition at the producing API before applying recovery intended for a neighboring result.
The decisive Interpretation is that the API was applied to a module whose TYPEKIND or flags do not permit that operation. Keep the symbolic name beside the raw hexadecimal value so later analysis does not collapse the result into an unrelated COM family.
Where the result appears
- This result belongs to type-library and metadata processing around type-library creation or inspection of modules, interfaces, dispatch interfaces, coclasses, and records.
- 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.
Determine the object and lifecycle phase that owned this result; a UI symptom cannot establish whether the origin was the caller, proxy, runtime, server, or metadata producer.
Typical causes and interpretation boundary
Common cause categories for this HRESULT are: a function-module API targets an interface; a coclass is treated as a module; generated flags conflict with the source declaration. Evaluate these branches independently and require evidence from the owning API before promoting one branch to the root cause.
The check that separates this result from nearby HRESULTs is: the API was applied to a module whose TYPEKIND or flags do not permit that operation. If the decisive fact for this HRESULT is unknown, keep the result unresolved and collect the missing state instead of inferring it from wording.
Evidence and telemetry
- Record it with the type-library path and hash, LIBID and version, LCID, architecture, source package, and producer toolchain.
- capture TYPEKIND and TYPEFLAGS; operation; source declaration; containing library; dual/dispatch attributes; compiler output.
- 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.
Log identifiers, sizes, type tags, states, and hashes while excluding credentials, tokens, document payloads, and complete user arguments.
Diagnostic sequence
- Capture it (0x800288BD) 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 API was applied to a module whose TYPEKIND or flags do not permit that operation.
- Test the likely causes independently for this HRESULT: a function-module API targets an interface; a coclass is treated as a module; generated flags conflict with the source declaration.
- 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 inspect TYPEATTR before operation, correct exporter mappings, and rebuild metadata with the intended module category. The owner of retry for this HRESULT must define idempotency, refreshed state, maximum attempts, backoff, and cancellation responsibility.
After it, apply the API-specific validity rules to outputs and release only resources whose ownership transferred during this attempt.
Practical scenario
A generator attempts to add a DLL entry description to a record type; it emits a module type instead.
A regression test for this HRESULT should force the decisive precondition, assert native outputs, fix only that condition, and confirm the expected neighboring result.
Difference from related HRESULTs
TYPE_E_WRONGTYPEKIND is the general category mismatch; it is associated with an invalid module form for a type-library operation.
Represent this distinction for this HRESULT directly in control flow and dashboards instead of grouping it under a single COM-failure label.
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.