Error 80040154 retreiving COM Class factory

Question

Greetings,

    I have a VB.NET application that references a 3rd party Com component. The file is Interop.WINTSRRLIB.dll. My VB.NET application has a project reference to the COM comonent which lives in the directory:  C:\WaveTracker.

    The application runs fine. When I sent it to my customer, he installed in on his desktop machine. It runs fine. Then he copied all of the application files (which live in C:\WaveTracker) to his laptop. However, on his laptop, he gets the error:

"System.Runtime.InteropServices.COMException (0x80040154). Retrieving the COM class factory for component xxxx failed due to the following error: 80040154"

    The customer swears he has the .NET 2.0 Framework installed properly on his laptop. Any ideas on how I can get over this problem???

Kind Regards,

 

Scott

 

Answer 1

The COM component needs to be registered on his laptop.  Start + Run, regsvr32 c:\wavetracker\componentname.dll

Answer 2

I had my customer try this (register thedll with regsrvr32) and he reports to me that the system responds with a message that says that the file was loaded but the entry point could not be found and therefore was not registered. The application still aborts with the same 80040154 error.

I can find no evidence that I had registered the dll on my system (with regsrvr32), nor does my customer remember registering it on his desktop system (where the application works and accesses the dll correctly).

So, I guess I am somewhat flummoxed here...any further advice?

Tx,

Scott

Answer 3

Sounds like he was trying to register the wrong DLL.  If it is a COM component, it should allow itself to be registered.  To find out what DLL you really need to be registered, pay attention to the GUID reported in the error message.  It will look something like "{750fdf0e-2a26-11d1-a3ea-080036587f03}".  Start Regedit.exe on your PC and navigate to HKCR\CLSID.  Find the GUID that was reported in the error message.  Open the key and look for the value of 'InProcServer32', it should point to the DLL.

Answer 4

The GUID reported in the 80040154 message does not show in in a registry search. When attempting to register the dll, the error message is that the DLLRegistryServer entry point cannot be found.

The customer allowed me to access the problem system remotely...there is only one copy of the dll "interop.wintssrapilib.dll" on his system and it is the correct version. In fact, I transferred all of the application files from my system directly to his sytsem and the error persists.

Also, I have a few small dLLs in the application that I wrote....I have never had to 'register' them to have the application work. Furthermore, when I do attempt to register them (just to shed some light on this problem), I (again) get the error that the DllRegister Server entry point cannot be found.

I think this may be an instance of the dll-hell I have always heard about. Any clue as to what is happening?

Tx

 

Scott

 

 

Answer 5

Make sure you look in the registry of a PC on which your app works.  Don't do a search, just look through the keys in HKCR\CLSID for the GUID, they are sorted alphabetically.  The fact that you can't find a DLL that can be registered with regsvr32 is a strange problem.  If might live in another folder, c:\windows\system32 perhaps.  Look at the properties of the WinTSRRapiLib reference in your project. Also, the component may itself use another ActiveX component that requires registration.  Like the VB6 runtime files for example.

Another way to debug this problem is to use the RegMon utility, available for free at www.sysinternals.com.  It shows you how your app uses the registry.  Run it on yours and run it on the customer's and compare the two.

Answer 6

i went to www.sysinternals.com and downloaded a few utilities that led me to the problem...'listdlls' and 'procexp' were very useful. The problem was simply that the 3rd party dll required other dlls that were not on the system. So I installed the required (other) dlls and everything is fine.

Thanks for your help and recommendations.

 

Scott

Answer 7

Hi Scott, could you please tell me which utilities you downloaded from www.sysinternals.com, how can i find them at this page?

I have the save trouble with a web service

Thanks for your help

Answer 8

You need to register the com class on the web server too. Run .reg and .bat of your DLL on the web server.

 

Answer 9

Hello Friend,

the file you reffered to register "interop.wintssrapilib.dll" is only the wrapper fro your original file.
You can't register this wrapper file with regsvr32.exe. You need the original component file "wintssrapilib.dll".

So you copy the file "wintssrapilib.dll" to C:\WaveTracker and issue the command "regsvr32 C:\WaveTracker\wintssrapilib.dll".

I hope your problem solved..


Senthil Kumar D,
[e-mail]

Answer 10

it looks like you deinstalled some component and it unregisted your dll. Simply reinstall it or fire regsvr32

Answer 11

I'm running a 32-bit custom app on 64-bit windows xp sp2.  It starts fine, but when it tries to connect to another app (also 32-bit) I get the problem referenced here (80040154 retreiving COM Class factory).  So,  I went to the GUID directory for for 32-bit procs in a 64-bit architecture (HKCR\Wow6432Node\CLSID) and found the GUID referenced in the error msg.  Looked at the proc and then regsitered it with regsrv32.  Registration went successfully. 

However, I still get the same error when running the program and trying to connect.  Any addt'l thoughts on this?

Answer 12

It sounds like your app is running in 64-bit mode.  That would be automatic if it is a .NET app.  Use Corflags.exe or Build + Platform Target to force it to run in 32-bit mode.

---

Hans Passant.

Answer 13

Corflags worked like a charm.  .NET was indeed trying to force it to run as a 64bit app.  Running corflags with the /32bit+ switch modified the .exe properties and allowed for the app to start and connect without incident.  Thanks so much - appreciate your quick (and accurate) response!

Mike

Answer 14

Please register the dll's and restart IIS to fix the Issue.

Answer 15

80040154

Answer 16

If you're getting the error within a website I managed to fix this error by going into IIS and going into the Advanced Settings of the Application Pool the website is using.  There is an option to "Enable 32-bit Applications" which will probably be set to False.  Set it to True and restart the website.

Answer 17

I know it is not constructive, but I just have to say it. After a couple of frustrating days struggling with this needless, pointless issue. This is a ridiculous way of doing things. I am struggling to do all this stupid stuff with DLL within the .NET/COM framework. It is so complicated it could be a monty python sketch. Can't you guys at Microsoft possibly, ever, make something that just works?

I mean, why the ____ should I need to personally worry about the registry? This is crazy. Can't you see how crazy this is?

Answer 18

Hi...

If you have enabled the option "Enable 32-bit Applications". Can you execute the applications
which are developed in 64 bit ? I think, that is not possible. So, we willn't get the advantage of
64 bit, am i right ?

Also, how will you enable the "Enable 32-bit Applications" ? I dont find any options in IIS application pool.
I have enabled it through command prompt.

Answer 19

I have been building my App for 'Any CPU' and that has worked fine together with the COM object the App denpend upon. Then I installed a 64-bit OS and continues to build against Any CPU and got this error code when trying to use the COM object. It turned out I had to build against x86 to still use the COM object. But that shouldn't be a problem (as long as I can run it on my x64 OS (which I can)).
Just a note...

Answer 20

In some cases, certain DLLs (like capicom) cannot be placed within the Inetpub folder.  If you are still having trouble with this error, try placing, and registering, the DLL somewhere on the C:\ drive (i.e., C:\SharedDLLs).  That worked for me.

Answer 21

I have this same issue. I have an application which was build with 'Any CPU'. This application seemed to be working fine. I moved all my code from my desktop to my laptop and I started getting this error. The only difference between my laptop and desktop is the Operating System. Both are using 32 bit version on OS and all the .net versions are same. the only difference one is using XP and the other Windows 7. I tried finding the CLSID in regedit, but this is not present. Any other ideas as to how can i fix this??

Answer 22

Might depend on the version of VS you are running.  A couple of things to try:

- Re-install the framework and restart IIS
- Try publishing the solution (if its VS2008) and setting up a virtual directory via that.

Answer 23

I know it is not constructive, but I just have to say it. After a couple of frustrating days struggling with this needless, pointless issue. This is a ridiculous way of doing things. I am struggling to do all this stupid stuff with DLL within the .NET/COM framework. It is so complicated it could be a monty python sketch. Can't you guys at Microsoft possibly, ever, make something that just works?

I mean, why the ____ should I need to personally worry about the registry? This is crazy. Can't you see how crazy this is?

I share your anxiety lol

Answer 24

When registering a COM object in Windows 7, be sure to run the command prompt in Adminstrator Mode. Right click on the command prompt icon and select "Run as Administrator". To simplify things, I have set the properties of my command window to always run as administrator.

Answer 25

I too have the same problem and i have tried running it as admin...but it did not work..

---

Sharing is profitable only if it happens with knowledge.

Answer 26

Did you try placing the DLL outside InetPub (see my post above)?

Answer 27

what is InetPub ?

---

Sharing is profitable only if it happens with knowledge.

Answer 28

In one development project, I've installed into 64 bit machines the same old library I've used on 32 bit machines.

I get that ugly error {Retrieving the COM class factory for component with CLSID {blawblaw-blaw-blaw-blaw-blablaw} failed due to the following error: 80040154}

 As it turns out, when compared to the 32 bit machine, the actual underlying components did not install on the 64 bit machine. It did place them into the C:\Windows\SysWOW64 dir. So, what I did was then add the matching components from the SysWOW64 dir, in Component Services, under the COM+ Application entry's Components tree item. Just right-click - New - Component = Hit Next in Wizard, then Click 'Import component(s) that already registered', then next - then click '32 Bit  Registry' check box to see those entries - then scroll down to your items, and select all of them to match your working machine.

All worked fine then.

Hope this helps!

Answer 29

To enable auditing, open User Manager and select "Audit" from the Policies" menu. Select the "File and Object Access" failure read more 80040154

---

http://types-of-snakes.blogspot.com/

Answer 30

I have same error that this forum is about. I work in a location where we cannot download any freeware from off the internet and run it on our network. So it there an alternative to RegMon that come included in Windows (server)? I developed a web application that works fine on my development workstation (Vista, VS 2008), all the DLL's are in a BIN folder within the project folder. I simply do a Copy Website over to our IIS machine which has a virtual directory that houses the files for the web app. When i run the app i get the error. Now i tried to register the dll's that doesnt work. It doesnt register successfully. I made sure the dll,xml and anyother file in my bin directory was moved over to the IIS. I did also look in the IIS registery to see if that same GUID was there and it is not. How can i get that over to the IIS server since i cant successfully register the dll file.

---

Network+, MCP

Answer 31

Hi Hans,

 

My case, a web application is using the 32bit DLL, how to solve the problem? can I use "corflags.exe" to solve it? how?

 

Cheers,

Jack

Answer 32

Corflags.exe worked like a charm!!! Thanks it saved my day!!!

Keep good answers coming in...

 

Answer 33

Hi Peter,

Your COM object is already build for 32-bit. But your applicatioin builded for any CPU. Thats why, your application is working on both the environments. when a reference is calling to the COM component (ie. 32-bit) your application will throws the error.

Answer 34

Try Running Visual Studio 2008 as administrator. I believe this would solve your issue. If it doesn't help, open your project file using notepad and inside the <ProjectExtensions> tag find  <IISUrl> and delete the URL between <IISUrl> and </IISUrl> then save your project and reload it in Visual Studio.

Answer 35

PLEASE HELP!!!!

Me, I have exactly the same problem: An ASP.NET application that was running correctly on Windows server 2003 but does not work anymore (Showing above famous message) as soon as I transferred it on Windows Server 2008. The DLL is Interop.Encryption which is a higher level consumer of Encryption.DLL.   I have installed a DLL dependency detector (Dependency Walker) application toolkit and finally find out that the problematic DLL that caused all these issues is MSVBM60.DLL which is Microsoft Visual Basic 6 run time ActiveX installed on new server.

 Does anybody knows the easy step by step solution for this problem?  Please help me out! but not with referral articles, I'm not interested for any hightech  paper to read and add my knowledge about the advanced Microsoft VB6 compatibility structure on 64 bit machines with COM object fan outs, etc. [I believe this problem must not happen at all for a 2004 Dll running on 2008 OS version; is Microsoft's job to read DLLs and create them as they must…]

Thanks

Answer 36

Well, I solved my problem after few hours search.

 

In my case error message showed VB6 DLL error as a dependency in my application (which was using Encryption.dll and Interop.Encryption.dll). I tried to register VB6 Dll (MSVBVM60.DLL) but was not able. The DLL itself needed 2 other dependent dlls that I found one on our old server and downloaded another (which was ieshims.dll) and placed in both folders (syswow64 and system32) but could not register them in windows server 2008 neither.

 

The point, by my guess, is that some old Dlls look into System32 directory (eventhough this directory is dedicated for 64 bit dlls in WinS2008) and open them internally; MSVBVM60.DLL  do not need those dependent dlls be registered globally; All I needed was copy them to folders. Most messages I received were misleading; directing to register or security issues . Now everything seems to work so far.

 

Answer 37

THis did the trick - I had an old (circa 2005) COM DLL which ran fine as part of a web application on a 32 bit machine.  When I moved to a 64 bit Win 7 machine for development, I could Reference the COM object from withing VS just fine, and intellisense worked.  But, when actually instantiating the object (dim o as new MyOldComObject.xxx) it would throw an error.

Setting Application Pool / Advance Objects / Enable 32 bit applications fixed it right up...  Thanks!

 

Answer 38

We found this to be isolated to the client missing the OWC (Office Web Components) simply installing the OWC latest release brought in the needed DLL files.

Answer 39

This is all too TRUE...

Answer 40

Hi, I just found this thread in a Google search. Going all the way back to the very first post by Scott Masters, I have a very similar problem. The COM component I'm using is from Microsoft, it is DSOFile and it is an Office File properties reader. I found the answers in this thread very helpful. I looked at HKCR\CSLID\DSOFile and the found the dll is registered on my computer, looked at my users' computer and there was no entry for DSOFile. I copied the dll to the users computer, registered it using regsvr32 and voila! Problem fixed!

My real reason for this post then is to ask the question: why didn't the setup.exe built using the publishing wizard copy the dll and register it on the users' computer? What ever happened to "OnceClick"???? If I have to manually do this on each users' computer then what good is the setup.exe? Is there something I am missing (setting or something in the project in Visual Studio e.g.)?

Thanks in advance for your help!

Answer 41

This solved my problem.

The guys talks annoyingly slow but his solution worked for me.

In a nutshell, change the Target CPU in Advanced Compiler Settings to x86

http://www.youtube.com/watch?v=pDtyGns6mOw

PJ

Answer 42

Registering the dependencies of the failing DLL worked. Thanks!

Answer 43

This worked for me.  Thank you!!

Answer 44

Make sure you look in the registry of a PC on which your app works.  Don't do a search, just look through the keys in HKCR\CLSID for the GUID, they are sorted alphabetically.  The fact that you can't find a DLL that can be registered with regsvr32 is a strange problem.  If might live in another folder, c:\windows\system32 perhaps.  Look at the properties of the WinTSRRapiLib reference in your project. Also, the component may itself use another ActiveX component that requires registration.  Like the VB6 runtime files for example.

Another way to debug this problem is to use the RegMon utility, available for free at www.sysinternals.com.  It shows you how your app uses the registry.  Run it on yours and run it on the customer's and compare the two.

Very old post, still helps to identify which missing by looking up the GUID in working machine. Mine was missing sqlxml4.dll as i had to move legacy application into new server. I was able search the GUID in registry, worked fine.

Answer 45

Just want to thank you, I've written a component in C++ 6.0 and couldn't get it to work on a Windows 10 machine in Excel - I didn't know about HKCR\Wow6432Node and was pulling my hair out trying to get it to work.  With your help it now works perfectly.

Again , many thanks!

Ben