COM call not working when hosting executable runs as a service

We have an executable that hosts a COM server, say x.exe. The COM object is instantiated as follows on the calling site:

hRes = CoCreateInstance(CLSID_InterceptX, NULL, CLSCTX_SERVER, 
                IID_IInterceptX, (void**)&pInterceptX);

It all works fine when x runs as an regular application.

We have a tool that encapsulates x.exe so that it runs as a service under Windows. In this case, we never receive 开发者_开发技巧a COM call in x.exe (validated by logging). Here is the weird part: From logging the calling site, I can tell that the COM object has been successfully instantiated and also the call to an interface function does not produce an error (SUCEEDED(hres) is true).

Any ideas?

I guess one (or possibly all) of three things are happening (sorted by likelihood):

(1) A LocalService value in the AppID key has not been configured, making it start as a regular program instead.

(2) When the "srvany" (or equivalent) program executes the COM server, it doesn't pass necessary command-line options (like "-automation") for it to register the server object. Most frameworks register class objects automatically, though. Log the command-line passed to the server to see if this is the case.

(3) The server does not call CoInitializeSecurity (most frameworks don't) and does not declare AccessPermissions. Check this with dcomcnfg. However, this should have made the call fail, not start a new server.

You don't say under which account the service is running; have you tried running it as the same account as the interactive user, and allowing it to interact with the desktop (as a debug measure -- you shouldn't do that in production!)?

I have struggled with exactly the same problem when running a VB6 COM server application (an OPC server) as a Windows NT service (there is no indication in the original question whether the COM server is a VB6 application, but in my case it is). At the end a Microsoft article has confirmed that COM/DCOM will not work when a VB6 application is ran as a service (regardless of the way you manage to get the application to run as a service in the first place).

Here is a quote from the article:

Microsoft does not currently recommend, and does not support, running Visual Basic applications as Microsoft Windows NT, Windows 2000 and Windows XP Services because the applications may exhibit unstable behavior when installed and run as Microsoft Windows Services

And another:

Developers can expect difficulties with efforts to employ Microsoft technologies such as ODBC, DCOM, OLE Automation, and DAO in a Microsoft Windows Service written in Microsoft Visual Basic. For this reason, and for those reasons already noted, Microsoft advises developers to avoid using these technologies in a Microsoft Windows NT Service written in Microsoft Visual Basic.