100
votes

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?

19
Can you give more detail with some code?Xaisoft
There are two questions: 1.Did you install / register the COM component on the Windows 7 x64 machine? 2.What the target platform of your application, I think you should set the platform to x86, please do not set it as "Any CPU"? Please register the COM first and then run to test the application, please refer to the document: support.microsoft.com/kb/146219 and Explanation of Regsvr32 usage and error messagesJackWang
I solved it without changing the build target to 'x86'. Solution in the link : <stackoverflow.com/a/55513690/11310933>Sunil Xtha

19 Answers

66
votes

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.

49
votes

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.

16
votes

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.

11
votes

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.

9
votes

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)

5
votes

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.

3
votes

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

3
votes

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

enter image description here

3
votes

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.

2
votes

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

App Pool

Enable 32 bits applications

2
votes

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. IIS App Pool Settings

2
votes

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.

1
votes

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

0
votes

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.

0
votes

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.

0
votes

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)

0
votes

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

0
votes

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

-1
votes

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

enter image description here