How to solve COM Exception Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))?

When I try to create a instance of a COM class it throws an exception as

Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Please suggest how could i solve it?

You need to make sure all of your assemblies are compiling for the correct architecture. Try changing the architecture for x86 if reinstalling the COM component doesn't work.

It looks like whichever program or process you're trying to initialize either isn't installed on your machine, has a damaged installation or needs to be registered.

Either install it, repair it (via Add/Remove Programs) or register it (via Regsvr32.exe).

You haven't provided enough information for us to help you any more than this.

My problem and the solution

I have a 32 bit third party dll which i have installed in 2008 R2 machine which is 64 bit.

I have a wcf service created in .net 4.5 framework which calls the 32 bit third party dll for process. Now i have build property set to target 'any' cpu and deployed it to the 64 bit machine.

when i tried to invoke the wcf service got error "80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"

Now i used ProcMon.exe to trace the com registry issue and identified that the process is looking for the registry entry at HKLM\CLSID and HKCR\CLSID where there is no entry.

Came to know that Microsoft will not register the 32 bit com components to the paths HKLM\CLSID, HKCR\CLSID in 64 bit machine rather it places the entry in HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID paths.

Now the conflict is 64 bit process trying to invoke 32 bit process in 64 bit machine which will look for the registry entry in HKLM\CLSID, HKCR\CLSID. The solution is we have to force the 64 bit process to look at the registry entry at HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID.

This can be achieved by configuring the wcf service project properties to target to 'X86' machine instead of 'Any'.

After deploying the 'X86' version to the 2008 R2 server got the issue "System.BadImageFormatException: Could not load file or assembly"

Solution to this badimageformatexception is setting the 'Enable32bitApplications' to 'True' in IIS Apppool properties for the right apppool.

Also note that the class context when initializing can create that exception. If you have an object which is coded as INPROC_SERVER but you try to CoCreateInstance as CLSCTX_LOCAL_SERVER, you will also get that error.

You need to ensure the object is registered and the CoCreateInstance is creating an instance with the correct class context.

If you are using 64-bit COM components in a web application on IIS, make sure the application pool is set to not allow 32 bit applications (Enable 32-Bit Applications: false in advanced settings)

I got it to work by Enabling 32 bit applications in the Application Pool advanced settings. Right click on the application pool and choose advanced settings - enable 32 bit applications. This may help someone out there.

By registering the class (specifically its CLSID) -- see e.g. here.

in my case

my platform is x64

the Dll library(sdk) and the redistributable package is x64

so

1. in the solution explorer navigate to your project

2. open Properties

3. change the Platform target from AnyCPU to x64

The way that I resolved this issue was to register the COM via regsvr32.

ensure that the COM you are invoking is registered.

My application was using xceedcry.dll and I was not registering it. Once I registered it, the application worked fine.

My solution was to change the "Enable 32-Bit Applications" to True in the advanced settings of the relative app pool in IIS.

In my case the class was registered properly and built in ANY CPU / 64 bit mode.

But the Enable 32-bit Applications property of the IIS Application pool of the application which uses the class was set to True.

Class was not found because of the architecture mismatch between the application pool configuration and the actual registered class.

Setting Enable 32-bit Applications to False fixed the issue.

I had the same issue using MapWinGis. I found the solution, working on visual studio 2015 windows forms proyect, just right click on the proyect-> properties-> Build, set configuration to All configurations and in the conbobox "platform target" set it to x64.

For me, I had to create 64 bit build configuration.

I have faced the same issue when we tried to upgrade our application from .NET framework 3.5 to v4.7.2.

In my case, everything mentioned above (targeting architecture to x86, registering COM DLLs, were already done)

The only thing worked for me is recreating interop DLL by running tlbimp command with latest .NET framework (in my case it was v4.7.2) and then use this DLL to rebuild the project. That solved it.

I ran into this issue calling a .Net assembly from a C++ client via COM. It turns out that one of the assemblies the .Net assembly depended on could not be found. I wrestled for a while trying to figure out what was wrong with the 1st assembly, but it was actually one of the 1st assembly's dependencies. I received two different errors when calling CoCreateInstance() from the C++ client. The first was: REGDB_E_CLASSNOTREG Class not registered And the second try was: 0x80131040 : The located assembly's manifest definition does not match the assembly reference.

So check that your assembly's references are present. I discovered this by browsing the 1st assembly with dotPeek and noticing one of it's references was missing. Placing the correct version of the dependency in the folder resolved both errors.

I was compiling my application targeting any CPU and main problem turned out that adobe reader was installed older v10.x needs to upgrade v11.x, this is the way how I get to resolve this issue.

I ran into the same issue using a COM class, i.e. 'Class not registered exception' at runtime. For me I was able to resolve by going to the app.config file and change the 'startup' and 'supportedRuntime' elements to something like:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

You can read more about the details here http://stackoverflow.com/questions/1604663/

and here https://msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx

I should note I am running Visual Studio 2017. Target cpu = x86 Embed Interop Type = true (in the properties window)

go to the directory of .Net framework and register their the respective dll with Regsvr32.exe white space dll path.

I have faced the same issue. After done some research i found fix for me and it may useful. The issue is not only related to re-installation as of my observation, it depends on access permissions also.

Step 1: Repair the particular COM object.

Step 2: Component Services > Computers > My Computer > DCOM Config > Select your COM object > Right click > Properties > Security tab > Access Permissions > Choose Customize > Click EDIT > Select IIS_USER (If not exists create with complete rights) and give complete access and click OK.

Move to Identity tab > You can select "Interactive user" or "This user" > Click Apply and OK. If you choose "This user", we have to give Administrative privileged user to that server

Step 3: Open IIS Manager > Restart the Application Pools.

Note: If required please restart the server

Here find the solution, run mmc -32 tool (not dcomcfg)

On 64 bit system with 32 bit Office try this:

Start
Run
mmc -32
File
Add Remove Snap-in
Component Services
Add
OK
Console Root
Component Services
Computers
My Computer
DCOM Config
Microsoft Excel Application