HRESULT 0x80028028 (TYPE_E_QUALIFIEDNAMEDISALLOWED): meaning

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

TYPE_E_QUALIFIEDNAMEDISALLOWED means a type-library operation received a qualified name where only an unqualified local identifier is allowed.

Previous	Next
TYPE_E_UNDEFINEDTYPE	TYPE_E_INVALIDSTATE

TYPE_E_QUALIFIEDNAMEDISALLOWED

Qualified type name is not allowed here

TYPE_E_QUALIFIEDNAMEDISALLOWED is HRESULT 2147647528 (0x80028028) from winerror.h. The documented description is “Qualified name disallowed.” The value must be interpreted at type-library construction or binding where an API expects an unqualified local identifier.

What distinguishes this value: “Qualified name disallowed.” Capture evidence for that condition directly so a similar result from the same facility is not confused with this result.

The supplied name contains namespace or qualification syntax forbidden for the selected metadata operation.

Where the result appears

This result belongs to type-library and metadata processing around type-library construction or binding where an API expects an unqualified local identifier.
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.

Typical causes and interpretation

Common cause categories are: a fully qualified source-language name is passed to an OLE API; generated names include module prefixes; escaping rules are wrong. The evidence should distinguish configuration, lifetime, input, identity, resource, and version failures rather than grouping them.

Key distinction: the supplied name contains namespace or qualification syntax forbidden for the selected metadata operation.

Evidence to preserve

Record the HRESULT with the type-library path and hash, LIBID and version, LCID, architecture, source package, and producer toolchain.
Capture raw name; API receiving it; containing library/module; namespace separator; expected local identifier; producer toolchain.
Retain the exact type, member, field, name, MEMBERID, HREFTYPE, TYPEKIND, or registry path involved in the failing operation.
When the failure occurs during type-library generation, record construction order, imported libraries, layout/finalization state, and output TLB hash.
After the failing call, release TYPEATTR, FUNCDESC, VARDESC, BSTR, and interface resources using the matching API even when parsing or lookup fails.

For privacy-safe diagnosis of this HRESULT, capture the call schema and state transitions but hash or omit confidential payloads.

Diagnostic sequence

Capture the HRESULT (0x80028028) before a compiler, importer, or language runtime reduces the value to a generic metadata error.
Verify the exact type-library identity, file/resource loaded, registry view, architecture, and operation that returned the HRESULT.
Prove the relevant metadata condition: the supplied name contains namespace or qualification syntax forbidden for the selected metadata operation.
Test the likely causes independently: a fully qualified source-language name is passed to an OLE API; generated names include module prefixes; escaping rules are wrong.
For TYPE_E_QUALIFIEDNAMEDISALLOWED, 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 the HRESULT no longer occurs without introducing a different identity or compatibility break.

Correct handling and recovery

The appropriate recovery is to supply the local identifier required by the API and store namespace relationships through the supported metadata structures.

Practical scenario

A generator passes Library.Interface as a member name; it changes the member to Interface and records the containing library separately.

Difference from related HRESULTs

TYPE_E_AMBIGUOUSNAME can result when an unqualified name matches several items; this code rejects qualification syntax itself.

Developer and administrator guidance

Tools handling this HRESULT should pin type-library identity and version, avoid caching raw indices across versions, and preserve stable GUIDs and DISPIDs for published contracts. Repair for TYPE_E_QUALIFIEDNAMEDISALLOWED 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 TYPE_E_QUALIFIEDNAMEDISALLOWED, 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.