none
Retrieving the COM class factory for component with CLSID failed due to the following error: 8007007e

    Question

  •  

    Hi,

     

    I implementing .net 2.0 remoting. My remotable object is a dll that calls a COM interop object.

    Initially my remoting server was a .net 2.0 windows console application. In this scenario everything worked fine.

    I was able to get data back from the remotable dll through the server from the client.

     

    To move this architecture to production I needed to make the remoting server a windows service rather than a windows console application. When I did that the client is able to establish a connection to the remoting server(win service) but as soon as a call is made to the remotable object( that calls a COM interop function) I get the following error:

     

    {System.IO.FileNotFoundException} System.Exception:
    Retrieving the COM class factory for component with CLSID {9E652342-DA0D-488D-BDF2-F367DA425754} failed due to the following error: 8007007e.

     

    any help would be appreciated.

     

    thanks.

     

     

    Wednesday, December 05, 2007 3:11 PM

Answers

  • I was able to resolve the issue. The problem was that my remotable object was calling a COM object that was sitting on the network. Once I deployed my remotable object and win service(remotable server) on the same box as the COM object,everything worked fine.

     

    thanks.

    Friday, December 07, 2007 5:25 PM

All replies

  • 8007007e means some module wasn't found when the loading of the COM object or the object's factory was attempted.

     

    In terms of a service, this is often due to the location of the COM object's binaries and the user context under which the service is running.  Make sure the directory where the COM object binaries are stored are given access to the user under which the service is running, or the impersonation context under which the code is running.

    Wednesday, December 05, 2007 3:25 PM
  •  

    Hi Peter,

     

    Thanks for your response. It looks like the registery entry path for my COM object was using the mapped path to the server on which the COM dependencies are located( which worked for the console remoting server but not for the win service remoting server). I changed the path in the registery to use the correct path using the full server name and I don't get the 8007007e error anymore. However I do get the following error:

     

    System.UnauthorizedAccessException {"Retrieving the COM class factory for component with CLSID {9E652342-DA0D-488D-BDF2-F367DA425754} failed due to the following error: 80070005."} System.UnauthorizedAccessException

    The win service is running under the 'local system account'. Unfortunately I don't have rights to manipulate the directory security settings on the server where the COM object is located and our Network admin is unavailable right now.

    I'll play around with the directory security for the COM object and match it with the account the win service is running under. I'll keep you posted if that resolves the issue.

     

    thanks for your help.

    Wednesday, December 05, 2007 5:53 PM
  • That's a generic access denied code, that could apply to file/directory permissions; but it could also apply to permissions required for the COM object to do what it needs to do. 

     

    If changing file/directory permissions doesn't do what you need, you may find that you'll have to change the user to run the service under.  "local system account' simply may not have the permissions available for that particular COM object...

    Wednesday, December 05, 2007 6:28 PM
  • Hi Peter,

     

    I changed the account under which the win service was running to my account and also granted full control to the directory security for my COM object(on the network) to my account. Oddly enough I get the following error now when I execute my remoting client.The client is able to get a response back from the remoting server but when the COM object call is executed, it hangs for a couple of seconds and then the error comes up.

     

    "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."

    and the win service shuts down. Also following is the stack track from the error:


    Server stack trace:
       at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessResponseException(WebException webException, HttpWebResponse& response)
       at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
       at System.Runtime.Remoting.Channels.SoapClientFormatterSink.SyncProcessMessage(IMessage msg)

    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at WilshireRemotingRemote.WilshireServiceClass.GetAtlasPortfoilios()
       at Client.Form1.Form1_Load(Object sender, EventArgs e) in C:\Anshul\Client\Client\Client\Form1.vb:line 45

     

    Is this happening because somehow the connection closes before the communication between the remoting server and the remotable object is complete and I need to somehow prolong the connection timeout. Or could this still be related to COM security?

     

    thanks.

    Wednesday, December 05, 2007 7:55 PM
  • It's hard to tell exactly why the connection is closed.  It could be that the server code encountered and exception and that's causing the connection to be dropped.  Debugging the server and looking at the WebException.InnerException might give you more detail.
    Wednesday, December 05, 2007 8:40 PM
  • Hi Peter,

     

    I was able to debug the server and it looks like the win service is able to successfully access the COM object on the network. In the output window I can see a bunch of dependant COM dll's being loaded. But it fails to load one of the dependent COM dll's. I have no idea why that is happening. When I debug the console application that dll that the win service is failing on is loaded without a problem.

     

    When the win service fails to load that dependant dll, it crashes and the client recieves the error connection is closed.

    I am not sure how to proceed in resolving this issue.

     

    thanks.

     

    Thursday, December 06, 2007 6:47 PM
  • I forgot to mention that when I debug the server from VS(when its not kicked off from the win service) I don't face any issues. So it has to be the win service security context. I've searched the web but have been unable to find good articles on win service security specifics. I would appreciate it if you could post some links that discuss win service security in detail.

     

    thanks. 

     

    Thursday, December 06, 2007 7:01 PM
  • I was able to resolve the issue. The problem was that my remotable object was calling a COM object that was sitting on the network. Once I deployed my remotable object and win service(remotable server) on the same box as the COM object,everything worked fine.

     

    thanks.

    Friday, December 07, 2007 5:25 PM
  • Hi Anshul ,

    I'm also having the same problem.

    Can u please tell me how to resolve the issue clearly.


    Thanks in advance.
    vizai

    Friday, December 28, 2007 11:40 AM
  • The solution outlined so far was that the assembly that contains the classes that are remoted needs to be put on the client and the server.

     

    Friday, December 28, 2007 2:17 PM
  • I am facing same issue here.

    objAtlas = new AtlasAPI();

    error is throw at above line: Retrieving the COM class factory for component with CLSID {9E652342-DA0D-488D-BDF2-F367DA425754} failed due to the following error: 8007007e.

     

    BUT works fine while debugging. But when moved to QA server, it throws above error. Even it works in QA server when i setup the project and run in debug mode.

    Please suggest how to overcome this issue.

     

    Thanks

    RK

    Thursday, October 20, 2011 9:09 PM