What does HRESULT 0x80110428 (COMADMIN_E_COMPFILE_BADTLB) mean?

 
Previous Next
COMADMIN_E_COMPFILE_CLASSNOTAVAIL COMADMIN_E_COMPFILE_NOTINSTALLABLE

COMADMIN_E_COMPFILE_BADTLB

COMADMIN_E_COMPFILE_BADTLB is the failure HRESULT 0x80110428 (signed decimal -2146368472, unsigned decimal 2148598824). Its severity bit is 1, facility is 17 (FACILITY_ITF), and the facility-specific code field is 0x0428.

Exact meaning

AllStat describes this condition as “The TypeLib could not be loaded.” COM+ has progressed beyond locating the component and is attempting to obtain type information needed to describe its classes, interfaces, and methods. The associated type library—embedded in the component or supplied as a separate file—cannot be opened and interpreted as a usable COM type library.

The HRESULT does not by itself say whether the metadata is missing, corrupt, incompatible with the selected component, or inaccessible. It also does not prove that the component DLL cannot be loaded or that DllGetClassObject is unavailable; those are separate inspection boundaries with their own COMADMIN results.

How COM+ receives type information

ICOMAdminCatalog::InstallComponent takes a DLL path and optional type-library path. Microsoft specifies that the type-library argument is empty when the metadata is embedded in the DLL. A nonempty argument selects an external type library. Therefore diagnostics must first establish which source COM+ was expected to use; testing an unrelated registered type library can conceal the packaging error.

COM+ needs type metadata for interface, method, marshaling, and catalog information. A file may be a valid PE image and still fail this stage because its embedded resource is absent or malformed, or because the external .tlb belongs to another build.

Evidence to preserve

  • The component DLL path and the exact type-library argument passed to InstallComponent, including whether that argument was intentionally empty.
  • Hashes and file versions for both the component and external .tlb, plus the build identifier that should have produced them together.
  • The result of loading the chosen metadata source with LoadTypeLibEx using REGKIND_NONE, including the subordinate HRESULT.
  • The resulting TLIBATTR values when loading succeeds elsewhere: LIBID, major/minor version, LCID, and system kind.
  • For embedded metadata, the PE resource inventory and the resource identifier used by the build, not merely a registry entry for the same LIBID.
  • Installer and code-signing logs that show whether post-build processing stripped, replaced, or damaged resources.

Failure patterns

  • No embedded type library: the deployment passes an empty type-library path, but the selected DLL was built without the expected type-library resource.
  • Wrong external metadata: the package pairs a component with a .tlb from another product, architecture package, branch, or version.
  • Invalid type-library image: the file exists but is truncated, zero length, incorrectly generated, or not a type library at all.
  • Resource damage: signing, packing, resource editing, or an installer transform changed the embedded metadata after the component build.
  • Path or access problem for the external file: COM+ can inspect the component but cannot open the explicitly supplied .tlb. Preserve the lower-level file status so this is not confused with malformed metadata.
  • Version skew: the type library loads but describes classes or interfaces inconsistent with the component selected for installation. Rebuild and package both artifacts from one source revision.

Diagnostic sequence

  • Determine whether COM+ is supposed to use embedded or external metadata from the actual InstallComponent arguments.
  • For an external file, verify its path and hash, then call LoadTypeLibEx without registration. Record the exact load HRESULT before attempting any catalog repair.
  • For embedded metadata, inspect the DLL's resources and test loading the component path as a type-library source. Confirm that the expected resource survived the final signed artifact.
  • Read ITypeLib::GetLibAttr and enumerate the declared coclasses and interfaces. Compare LIBID and version with the deployment manifest and generated headers.
  • Compare the metadata artifact with the component's build outputs. A registered copy elsewhere on the machine does not validate the file being installed.
  • Regenerate the type library from the authoritative IDL, rebuild the component, sign/package the pair together, and repeat installation in a clean catalog test environment.

Practical scenario

A release pipeline rebuilds a COM+ DLL but copies an older external Accounting.tlb into the package. The DLL exists and can be opened, yet the supplied type-library file is damaged during packaging and LoadTypeLibEx cannot parse it. Re-registering the old LIBID may change registry state but does not repair the artifact COM+ was asked to inspect.

Retry and recovery

Do not retry unchanged metadata. A meaningful retry follows replacement of the missing or invalid type library, correction of the external path, restoration of access, or rebuilding the DLL with a valid embedded resource. Use hashes to prove that the retried component/type-library pair is the corrected pair rather than another copy of the failed release.

Distinguishing nearby COMADMIN results

  • COMADMIN_E_COMPFILE_DOESNOTEXIST fails before metadata analysis because the component path resolves to no file.
  • COMADMIN_E_COMPFILE_LOADDLLFAIL identifies failure to load the component DLL, not failure to parse its type library.
  • COMADMIN_E_BADREGISTRYLIBID concerns an invalid or unusable registered LIBID; this result concerns loading the type library associated with the component file being inspected.
  • COMADMIN_E_COMPFILE_NOTINSTALLABLE means the inspected file provides no component that COM+ can install even after available metadata is considered.

Telemetry and build guidance

Record component and type-library paths separately, whether metadata was embedded, both hashes, LIBID/version/LCID, the exact LoadTypeLibEx result, resource inventory, package build number, and signing timestamp. Build validation should load the final packaged artifact—not only an intermediate output—and compare its type information with the generated interface definitions before deployment reaches COM+.

Official Microsoft references

Looking for a different code? Search another status or error code.