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?
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.
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.
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)
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.
By registering the class (specifically its CLSID) — see e.g. here.
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.
The way that I resolved this issue was to register the
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.
For me, I had to create 64 bit build configuration.
in my case
my platform is x64
the Dll library(sdk) and the
redistributable package is x64
in the solution explorer
navigate to your project
change the Platform target from AnyCPU to x64
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.
My solution was to change the “Enable 32-Bit Applications” to True in the advanced settings of the relative app pool in IIS.
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/
I should note I am running Visual Studio 2017.
Target cpu = x86
Embed Interop Type = true (in the properties window)
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.
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