305

I developed a Windows service using C#.NET to generate PDF report. To generate PDF file I am using a third party dll. The application is running in my Windows XP platform. When I deployed the service in Windows Server 2008 64 bit version, I got this error:

Retrieving the COM class factory for component with CLSID {46521B1F-0A5B-4871-A4C2-FD5C9276F4C6} failed due to the following error: 80040154.

I registered the DLL using the regsvr32 command. I able to see this CLSID in the registry. But the problem persists.

What could be the problem?

Randy Levy
  • 22,566
  • 4
  • 68
  • 94
gopal
  • 3,681
  • 5
  • 24
  • 25
  • 1
    A web application hosted in the same server is able to generate PDF file without any error. – gopal Jun 24 '09 at 07:59
  • Guys I tried every possible solution but still getting this error. I have assemblies and registered them successfully but still getting same error. Really need help... – newprogress Dec 23 '13 at 11:39

18 Answers18

398

In VS - project properties - in the Build tab - platform target =X86

Fabrice MARIANADIN
  • 4,142
  • 1
  • 16
  • 3
65

I ran into a very similar issue.

I needed to use an old 32-bit DLL within a Web Application that was being developed on a 64-bit machine. I registered the 32-bit DLL into the windows\sysWOW64 folder using the version of regsvr32 in that folder.

Calls to the third party DLL worked from unit tests in Visual Studio but failed from the Web Application hosted in IIS on the same machine with the 80040154 error.

Changing the application pool to "Enable 32-Bit Applications" resolved the issue.

keineahnung2345
  • 2,635
  • 4
  • 13
  • 28
Daniel Ballinger
  • 13,187
  • 11
  • 69
  • 96
61

It sounds like your service was built against 'Any CPU', causing you errors on 64-bit where you are using COM components. You need to build it for x86.

The website is probably running as a 32-bit process which is why it can use the component. Building your solution against x86 will force your service to run as 32-bit.

Ryan Gates
  • 4,501
  • 6
  • 50
  • 90
stevehipwell
  • 56,138
  • 6
  • 44
  • 61
  • I am also facing same problem..here my desktop application is installed successfully on 64bit system..while doing installation I done synchronization successfully but when when I do synchronization from my software it is showing me above error – Mohini Mhetre Mar 28 '14 at 10:42
  • I am trying to register `.ocx file (c:\Windows\SysWow>RegSvr32 genX.ocx)` but getting error **The module failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.** – Naveen Kumar Jun 15 '17 at 08:46
  • And if it's compiled as 32-bit, then the System regsvr32 should be used, not the SysWow64 version. – Fandango68 Sep 04 '19 at 03:39
  • I am getting this error while running SSIS package. Connections are working fine. All properties are correct. Actually SSIS package was running since many months without any error. Suddenly i am getting above error. I tried changing the runtime/debugging to x86 from x64 still issue has not been resolved. – IamVISH Apr 21 '20 at 05:23
19

If you are looking for a way to make this work without recompiling your Any CPU application, here is another potential workaround:

  1. Locate your COM object GUID under the HKey_Classes_Root\Wow6432Node\CLSID\{GUID}
  2. Once located add a new REG_SZ (string) Value. Name should be AppID and data should be the same COM object GUID you have just searched for
  3. Add a new key under HKey_Classes_Root\Wow6432Node\AppID. The new key should be called the same as the COM object GUID.
  4. Under the new key you just added, add a new String Value, and call it DllSurrogate. Leave the value empty.
  5. Create a new Key under HKey_Local_Machine\Software\Classes\AppID\ Again the new key should be called the same as the COM object’s GUID. No values are necessary to be added under this key.

I take no credit for the solution, but it worked for us. Check the source link for more information and other comments.

Source: https://techtalk.gfi.com/32bit-object-64bit-environment/

David Guerra
  • 79
  • 2
  • 6
Joshua Starner
  • 1,573
  • 1
  • 13
  • 13
  • 1
    Most excellent instructions. I was using a third-party tool, leaving me unable to change the build platform. This solution circumvented that issue. Thank you! –  Apr 25 '13 at 15:30
  • I've found the key as you described in step 1, and then I knew which COM object is making the troubles, then I just run regsvr32 on it. Thanks a lot! – MichaelS Jan 23 '14 at 07:34
  • When I did this my local webserver (IIS) started to get access denied. This tells me this was a step in the right direction but I'm not sure who to give access to at this point. http://stackoverflow.com/questions/14019401/80070005-access-is-denied-when-asp-net-website-with-crystal-report-is-deployed-o – user420667 Jul 15 '15 at 21:51
  • HKEY_CLASSES_ROOT is HKEY_LOCAL_MACHINE\SOFTWARE\Classes merged with CURRENT_USER\SOFTWARE\Classes. The AppID under that is shared by 32 and 64-bit platforms. So, (I believe) step 3 is not correct, because AppID should not be 32-bit specific. Given the above, I suggest step 5 should replace step 3 and the last sentence (of step 5) removed. – Phil Haselden Jul 12 '21 at 08:28
  • Which GUID clsid to look for, is it the one what is displayed in the error dialog? – TheTechGuy Oct 12 '22 at 22:29
19

You dont have to configure your project properties platform target X86. You can also configure the iis options to work with x86 like that

  • Select Application pool
  • Select the pool which your app uses
  • Advanced settings
  • Enable 32 bit applications true
nazim hatipoglu
  • 634
  • 10
  • 24
  • This has always been true for me. Never had to set the platform target to X86 but always • Enable 32-Bit Applications = True • Set Identity = ApplicationPoolIdentity • Load User Profile = True – Zath Apr 03 '14 at 15:27
  • I had a similar problem which was fixed as per Nazim's instructions but also had to not "Embed Interop Types" (a property of the referenced dll) and set Copy Local = true. – cymorg Jun 17 '16 at 00:03
  • How do you "Select Application Pool" ? – CodyBugstein May 06 '19 at 15:42
  • Application Pools menu is in the list of iis menu on the left – nazim hatipoglu May 12 '19 at 12:34
  • 1
    Even for me updating the application pool to enable 32-bit worked. Thanks @nazimhatipoglu – Keshab Aug 24 '20 at 22:42
14

The problem is that the server process is 64 bit and the library is 32-bit and it tries to create the COM component in the same process (in-proc server). Either you recompile the server and make it 32-bit or you leave the server unchanged and make the COM component out-of-process. The easiest way to make a COM server out-of-process is to create a COM+ application - Control Panel -> Administrative Tools -> ComponentServices.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • I encountered an error while trying to create a COM+ application. `An error occurred while processing the last operation. [Error code 00690075] The event log may contain additional troubleshooting information.` – KZee Feb 26 '20 at 19:00
10

I had the same issue, but the other answers only supplied one part of the solution.

The solution is two fold:

Remove the 64bit from the Register.

  • c:\windows\system32\regsvr32.exe /U <file.dll>
  • This will not remove references to other copied of the dll in other folders.

or

  • Find the key called HKEY_CLASSES_ROOT\CLSID{......}\InprocServer32. This key will have the filename of the DLL as its default value.
  • I removed the HKEY_CLASSES_ROOT\CLSID{......} folder.

Register it as 32bit:

  • C:\Windows\SysWOW64\regsvr32 <file.dll>

Registering it as 32bit without removing the 64bit registration does not resolve my issue.

Redoman
  • 3,059
  • 3
  • 34
  • 62
Gerhard Powell
  • 5,965
  • 5
  • 48
  • 59
9

I didn't change any compile settings.

Just set "Enable 32-bit Application = True" in AppPool Advanced Settings.

It worked for me

Eduardo Xavier
  • 1,520
  • 21
  • 29
7

The solution for windows 2008 server x64 is:

  1. open cmd.exe with Administrator permission.
  2. Copy the dll to the folder C:\Windows\SysWOW64
  3. run regsvr32 from C:\Windows\SysWOW64
  4. Verify that dll is in registry of Windows.
  5. If you has a .exe x86 that use the dll, the exe must be compiled in x86 mode.
  6. The exe must be installed in folder C:\Program Files (x86)

This procedure is valid, it is ok.

Juan
  • 71
  • 1
  • 1
6

Had a related issue with a different, but similar fix:

I had a Windows service project set to "Any-CPU" using a 64-bit DLL. Same error message. Tried a whole bunch of things, but nothing worked. Finally, I went into project Properties -> Build and noticed that project had "Prefer 32-bit" checked. Unchecked this and no more error.

My guess is that the windows service was expecting a 32-bit DLL, and couldn't find it.

jinushaun
  • 136
  • 1
  • 2
3

I found that my problem related to the actual registration of the DLL.

  • First run "Regedit.exe" from a CMD prompt (I raised it's security level to Administrator, "just in case")
  • then search the Registry (by clicking on "Edit/Find" in the RegEdit menu or by pressing Ctrl+F) for the CLSID showing in the error message which you received regarding the COM class factory. My CLSID was 29AB7A12-B531-450E-8F7A-EA94C2F3C05F.
  • When this key is found, select the sub-key "InProcServer2" under that Hive node and ascertain the filename of the problem DLL in the right hand Regedit frame. showing under "Default".
  • If that file resides in "C:\Windows\SysWow64"(such as C:\Windows\SysWow64\Redemption.dll") then it is important that you use the "C:\Windows\SysWow64\RegSvr32.exe" file to register that DLL from the command line and NOT the default "C:\Windows\System32\RegSvr32.exe" file.
  • So I ran a CMD prompt (under Administrative level control (just in case this level is need required) and type on the command line (in the case of my DLL): C:\Windows\SysWow64\RegSvr32.exe c:\Windows\SysWow64\Redemption.dll the press enter.
  • Close the command window (via "Exit" then Restart your computer (always use restart instead of Close Down then start up, since (strangely) Restart perform a thorough shut down and reload of everything whereas "Shut Down" and Power-Up reloads a stored cache of drivers and other values (which may be faulty).
  • Whenever you register a DLL in the future, remember to use the SysWow64 "RegSvr32.exe" for any DLL stored in the C:\Windows\SysWow64 folder and this problem c(if it is caused by incorrect registration) should not happen again.
Redoman
  • 3,059
  • 3
  • 34
  • 62
Chris Raisin
  • 384
  • 3
  • 7
  • 2
    Great tip, but just be aware that registering a 32bit DLL in SysWow64 then it's assumed the DLL has a wrapper to handle 64 bit requests. – Fandango68 Sep 04 '19 at 03:38
3

To change to x86:

  1. Create a setup project for your solution.
  2. After you create it, Go to Solution Explorer, right click the setup project.
    • Press Configuration Manager.
    • Click on: "Active Solution Platform" combobox and select New (If there is no x86 displayed)
    • Select from first combo x86 then press OK.
    • rebuild Setup project, then rebuild All the project.
Hendrik Brummermann
  • 8,242
  • 3
  • 31
  • 55
3

If you are running a website, you could also try to set your application pool to disable 32-bit Applications (under advanced settings of a pool).

scramblor
  • 63
  • 5
2

In my personal case the issue was fixed searching for the class id in the Windows's Registry on developer machine (because the issue was thrown in a client PC). This action will be placed into the COM component that causes the issue: an x86 library referenced in my .NET project that was not being registered as OCX/COM for the installer or updater application.

Regards

César Qüeb
  • 121
  • 7
1

For anyone using VSTO, the problem for me was a missing reference to the office assembly. It would also appear if you were trying to instantiate certain VSTO objects manually.

Alex
  • 5,364
  • 9
  • 54
  • 69
1

Accepted answer, changing target platform to x86 did not work in may case!

When I have installed crystal report for visual studio and crystal report runtime engine (64-bit) worked in my case!

Some other suggests that, this problem could be resolved by installing both 32-bit and 64-bit runtime engine!

You may give a try!

enter image description here

0

My problem was that I had the wrong MS Sync FrameWork version (1.0) in my project References. After update to the version 2.1, the error was gone and life is good again.

Phogrammer
  • 31
  • 2
0

In my case, I'm producing ms office file like word or excel, I run Win+R and execute dcomcnfg, in the DCOM Config, besides select OFFICE related name item (such as name contains Excel or Word or Office) and Open the properties, select Identity tab and select the interactive user. as this answer,

My error message show CLSID {000209FF-0000-0000-C000-000000000046}, so I have to try to find this specific CLSID in DCOM Config, and it does exsits, and I select it and follow same step set the interactive user, then it works.

yu yang Jian
  • 6,680
  • 7
  • 55
  • 80