none
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

     

    Tuesday, September 26, 2006 10:44 PM

Answers

  • 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.
    Friday, September 29, 2006 12:55 AM
  • 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

    Friday, September 29, 2006 2:51 AM

All replies

  • The COM component needs to be registered on his laptop.  Start + Run, regsvr32 c:\wavetracker\componentname.dll
    Tuesday, September 26, 2006 10:49 PM
  • 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

    Wednesday, September 27, 2006 3:53 PM
  • 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.
    Wednesday, September 27, 2006 4:07 PM
  • 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

     

     

    Thursday, September 28, 2006 10:22 PM
  • 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.
    Friday, September 29, 2006 12:55 AM
  • 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

    Friday, September 29, 2006 2:51 AM
  • 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

    Wednesday, November 01, 2006 4:44 PM
  • You need to register the com class on the web server too. Run .reg and .bat of your DLL on the web server.

     

    Wednesday, May 21, 2008 9:43 PM
  • 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,
    sd_senthilkumar@hotmail.com
    Monday, September 01, 2008 5:16 AM
  • it looks like you deinstalled some component and it unregisted your dll. Simply reinstall it or fire regsvr32
    • Proposed as answer by SHornung Tuesday, October 09, 2012 3:49 PM
    Tuesday, September 16, 2008 1:31 PM
  • 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?

    • Edited by msp115 Friday, November 14, 2008 12:43 AM
    Friday, November 14, 2008 12:41 AM
  • 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.
    • Proposed as answer by Brad Deem 2 Friday, July 29, 2011 7:22 PM
    Friday, November 14, 2008 1:00 AM
  • 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
    • Edited by msp115 Monday, November 17, 2008 7:41 PM
    Monday, November 17, 2008 4:09 PM
  • Please register the dll's and restart IIS to fix the Issue.
    Tuesday, April 14, 2009 12:01 PM
  • 80040154
    • Proposed as answer by messengr Saturday, September 26, 2009 11:33 AM
    Saturday, September 26, 2009 11:33 AM
  • 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.
    Tuesday, December 01, 2009 9:51 AM
  • 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?
    • Proposed as answer by asadim Thursday, March 25, 2010 4:31 PM
    Tuesday, December 15, 2009 3:50 PM
  • 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.

    Wednesday, December 23, 2009 6:43 AM
  • 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...
    Sunday, January 10, 2010 11:35 AM
  • 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.
    Thursday, February 04, 2010 10:29 PM
  • 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??
    Friday, March 12, 2010 12:47 AM
  • 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.

    Friday, March 12, 2010 4:07 PM
  • 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
    Wednesday, March 24, 2010 10:48 PM
  • 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.
    Wednesday, March 31, 2010 6:52 PM
  • 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.
    Thursday, July 22, 2010 1:53 PM
  • Did you try placing the DLL outside InetPub (see my post above)?
    Thursday, July 22, 2010 3:08 PM
  • what is InetPub ?
    Sharing is profitable only if it happens with knowledge.
    Thursday, July 22, 2010 6:02 PM
  • 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!

    Monday, September 13, 2010 5:37 PM
  • 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/
    Wednesday, November 17, 2010 7:49 PM
  • 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
    Monday, January 24, 2011 6:13 PM
  • 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

    Wednesday, February 09, 2011 2:54 AM
  • Corflags.exe worked like a charm!!! Thanks it saved my day!!!

    Keep good answers coming in...

     

    Thursday, February 10, 2011 8:46 PM
  • 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.

    Wednesday, February 16, 2011 6:51 AM
  • 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.

    Thursday, February 17, 2011 3:39 AM
  • 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




    Tuesday, May 24, 2011 7:02 PM
  • 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.

     


    • Proposed as answer by A.Oveissian Thursday, May 26, 2011 6:43 PM
    Thursday, May 26, 2011 6:43 PM
  • 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!

     

    Friday, August 26, 2011 5:52 PM
  • 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.

    Friday, September 30, 2011 11:00 PM
  • This is all too TRUE...
    Wednesday, January 18, 2012 4:51 PM
  • 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!

    Friday, January 20, 2012 8:29 PM
  • 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

    Wednesday, May 09, 2012 12:28 AM
  • Registering the dependencies of the failing DLL worked. Thanks!
    Tuesday, October 15, 2013 2:58 PM
  • This worked for me.  Thank you!!
    Wednesday, November 27, 2013 3:55 PM