What does HRESULT 0x80110484 (COMADMIN_E_CAT_WRONGAPPBITNESS) mean?

 
Previous Next
COMADMIN_E_CAT_UNACCEPTABLEBITNESS COMADMIN_E_CAT_PAUSE_RESUME_NOT_SUPPORTED

COMADMIN_E_CAT_WRONGAPPBITNESS

COMADMIN_E_CAT_WRONGAPPBITNESS is the failure HRESULT 0x80110484 (signed decimal -2146368380, unsigned decimal 2148598916). Its severity bit is 1, facility is 17 (FACILITY_ITF), and the facility-specific code field is 0x0484.

Application bitness and component architecture: exact meaning of COMADMIN_E_CAT_WRONGAPPBITNESS

COM+ recognized the binary architecture but found that it does not match the bitness selected for the destination application. This is an application-versus-binary mismatch, not merely an unreadable or malformed PE file.

AllStat records the Windows SDK description as “There was a type mismatch between a binary and an application”.

Where COMADMIN_E_CAT_WRONGAPPBITNESS occurs

The result appears while importing, installing, copying, or moving a component after COM+ has identified both the file architecture and the application configuration. On 64-bit Windows, the catalog distinguishes 32-bit and 64-bit components, so registry view and proxy/stub architecture also matter.

Typical cause branches

  • a 32-bit DLL is being placed in an application configured for 64-bit components.
  • a 64-bit component is copied into a 32-bit application or package.
  • the main DLL and its proxy/stub or type-library registration came from different architectures.
  • automation connected to the wrong catalog view and resolved a different application configuration than expected.

Evidence to collect before changing the catalog

  • PE machine type for the component, proxy/stub, and every dependent in-process DLL.
  • application ID, application type, and configured bitness before the operation.
  • 32-bit and 64-bit registry-view entries for CLSID, AppID, TypeLib, and ProxyStubClsid32.
  • source package manifest, file hashes, target OS architecture, and the exact COMAdmin method.

Diagnostic sequence for COMADMIN_E_CAT_WRONGAPPBITNESS

  • inspect every binary with an architecture-aware PE tool instead of relying on filenames.
  • repopulate the Applications and Components collections and verify the destination by AppID.
  • compare component architecture with the application bitness and with all marshaling binaries.
  • rebuild or redeploy a consistent architecture set through the owning installer.
  • repeat the original COMAdmin operation and verify activation from a client of the intended architecture.

Retry and recovery

Retry is deterministic until either the binary set or the application bitness changes. Do not solve the mismatch by registering the same DLL in both registry views unless the component was actually built and tested for both.

What this HRESULT does not establish

The HRESULT does not prove that the DLL is corrupt and does not identify which artifact is wrong. The application setting, component DLL, proxy/stub, and type library must be examined as one architecture contract.

Difference from nearby COMADMIN results

COMADMIN_E_CAT_BITNESSMISMATCH concerns disagreement among binaries, while COMADMIN_E_CAT_UNACCEPTABLEBITNESS rejects an unknown or invalid binary type. This value specifically compares a recognized binary with the application.

Practical administration scenario

A deployment copies a 64-bit server DLL into a COM+ application that was created for 32-bit components; catalog validation rejects the component before normal activation begins.

Developer and operations guidance

Record AppID, CLSID, catalog-server architecture, application bitness, PE machine values, registry view, file hashes, and the COMAdmin operation. These fields make the mismatch reproducible without logging package credentials.

Official Microsoft references for COMADMIN_E_CAT_WRONGAPPBITNESS

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