38

Moving a working C# project from a 64-bit Windows 7 machine to a 32-bit XP machine caused the following error:

Retrieving the COM class factory for component with CLSID {681EF637-F129-4AE9-94BB-618937E3F6B6} failed due to the following error: 80040154.

681EF637-F129-4AE9-94BB-618937E3F6B6 is not in the registry so it is not properly installed, but this is same ID that was previously a problem on the 64-bit Windows 7 machine.

The solution to this error on the 64-bit Windows 7 machine was found here (change Platform Target to x86) but this does not solve the problem on the 32-bit XP machine.

How do I find the DLL associated with 681EF637-F129-4AE9-94BB-618937E3F6B6, or, even better, how do I repair this exception?

Lypyrhythm
  • 326
  • 2
  • 12
jacknad
  • 12,453
  • 38
  • 115
  • 190
  • As far as I know, there is no way for a processes (64 or 32) to load a 32 bit dll (32 or 64 respectively). – Arun Aug 25 '11 at 21:42
  • 1
    Note that the error code is REGDB_E_CLASSNOTREG. So this can occur when a COM/ActiveX control is not installed on the machine or not installed for the bitness of the process. – Ritsaert Hornstra Feb 22 '18 at 10:55

4 Answers4

23

To find the DLL, go to your 64-bit machine and open the registry. Find the key called HKEY_CLASSES_ROOT\CLSID\{681EF637-F129-4AE9-94BB-618937E3F6B6}\InprocServer32. This key will have the filename of the DLL as its default value.

If you solved the problem on your 64-bit machine by recompiling your project for x86, then you'll need to look in the 32-bit portion of the registry instead of in the normal place. This is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{681EF637-F129-4AE9-94BB-618937E3F6B6}\InprocServer32.

If the DLL is built for 32 bits then you can use it directly on your 32-bit machine. If it's built for 64 bits then you'll have to contact the vendor and get a 32-bit version from them.

When you have the DLL, register it by running c:\windows\system32\regsvr32.exe.

ulidtko
  • 12,505
  • 10
  • 49
  • 82
Ciaran Keating
  • 2,688
  • 17
  • 19
14

I had the same issue in a Windows Service. All keys where in the right place in the registry. The build of the service was done for x86 and I still got the exception. I found out about CorFlags.exe

Run this on your service.exe without flags to verify if you run under 32 bit. If not run it with the flag /32BIT+ /Force (Force only for signed assemblies)

If you have UAC turned you can get the following error: corflags : error CF001 : Could not open file for writing Give the user full control on the assemblies.

Console output

Preben Huybrechts
  • 5,118
  • 2
  • 27
  • 57
  • Can you clarify - is the screenshot what the image flags SHOULD be? Or is the screenshot situation what caused problems for you? I am getting the poster's COMException and my executable has the exact same flags as in the screenshot. – Calvin Fisher Jun 06 '13 at 17:46
  • @CalvinFisher This is the screenshot how it should be. (In my case) – Preben Huybrechts Jun 10 '13 at 15:33
8

WORKAROUND:

The possible workaround is modify your project's platform from 'Any CPU' to 'X86' (in Project's Properties, Build/Platform's Target)

ROOTCAUSE

The VSS Interop is a managed assembly using 32-bit Framework and the dll contains a 32-bit COM object. If you run this COM dll in 64 bit environment, you will get the error message.

kalidoss
  • 451
  • 6
  • 13
  • This worked for me. The sample exe's worked but when I compiled the code and tried the new exe I received the COM error. The SDKTestPlus3.exe worked fine. Only my compiled exe did not work. After changing VS to build x86 istead of Any CPU, the compiled exe finally worked. Thanks! – Damon Oct 24 '18 at 19:07
-1

Move excel variables which are global declare in your form to local like in my form I have:

Dim xls As New MyExcel.Interop.Application  
Dim xlb As MyExcel.Interop.Workbook

above two lines were declare global in my form so i moved these two lines to local function and now tool is working fine.

Ulf Gjerdingen
  • 1,326
  • 3
  • 15
  • 20
Yogesh
  • 11