Keywords: COM component | 64-bit system | registry error | WCF service | IIS configuration
Abstract: This article provides a comprehensive exploration of the "80040154 Class not registered" error encountered when running applications on 64-bit Windows systems. By examining COM component registration mechanisms, interoperability between 32-bit and 64-bit processes, and WCF service configuration, it outlines a complete workflow from error diagnosis to solution. Key topics include using ProcMon to trace registry access, adjusting project target platforms to x86, and configuring IIS application pools to enable 32-bit applications, offering developers a thorough approach to resolving such compatibility issues.
Problem Background and Error Symptoms
When running applications on 64-bit computers using Visual Studio 2012, developers often encounter the error message: Retrieving the COM class factory for component with CLSID {F2D4F4E5-EEA1-46FF-A83B-A270C92DAE4B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)). This error typically occurs when calling third-party DLL libraries (e.g., Inventor PackandGo), indicating COM component registration failure due to compatibility issues between 32-bit and 64-bit environments.
Root Cause Analysis
The fundamental cause of this error is the mismatch in registry lookup paths when a 64-bit process attempts to invoke a 32-bit COM component. In 64-bit Windows systems, registry entries for 32-bit COM components are located under HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID, while 64-bit processes default to searching HKLM\CLSID and HKCR\CLSID. This inconsistency prevents the system from locating the component, resulting in a "class not registered" exception.
Diagnostic and Tracing Methods
Tools like ProcMon.exe can precisely trace registry access behavior. By monitoring process access to CLSID keys, developers can confirm if lookup failures stem from incorrect paths. For instance, in a case study, ProcMon showed that the process found no entries in HKLM\CLSID, verifying the issue arose from the different locations of 32-bit components in the 64-bit registry.
Solution Implementation Steps
First, adjust project configurations to force the process to look in the correct path. In Visual Studio, navigate to project properties and change the "Target platform" from "Any CPU" to "x86". This ensures the application runs in 32-bit mode, accessing registry entries under Wow6432Node. However, this change alone may lead to a System.BadImageFormatException, indicating assembly load failure.
To resolve this, configure the application pool in IIS. Locate the corresponding application pool, and in advanced settings, set the "Enable 32-bit Applications" property to "True". This configuration allows the IIS host process to run in 32-bit mode, compatible with the x86 target platform, avoiding image format exceptions. After deploying updates, the application should successfully invoke 32-bit COM components, eliminating the "class not registered" error.
Supplementary References and Best Practices
Other solutions recommend similar approaches, such as setting the "Target CPU" to x86 via project properties' "Advanced Compile Options". This emphasizes the importance of unifying target platforms. In practice, it is advisable to always test compatibility across 32-bit and 64-bit environments, use tools to monitor registry access, and ensure deployment configurations (e.g., IIS settings) align with project targets. For applications dependent on third-party DLLs, verifying component bitness and adjusting build and deployment strategies accordingly can prevent such errors.