将可执行文件作为服务运行时，COM调用不起作用

Question

我们有一个托管COM服务器的可执行文件，例如x.exe。在呼叫站点上COM对象的实例化如下：

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

全是works fine when x runs as an regular application。

我们有一个在Windows下封装x.exe so that it runs as a service的工具。在这种情况下，我们永远不会收到x.exe中的COM调用（由日志记录验证）。这是一个奇怪的部分：从记录调用网站，我可以告诉COM对象已成功实例化，并且对接口函数的调用不会产生错误（SUCEEDED(hres)为真）。

任何想法？

Answer 1

我想一个（或可能全部）的三件事情正在发生（按可能性排序）：

（1）中的AppID密钥A LocalService价值尚未配置，使得它开始作为一个经常性项目，而不是。 （2）当“srvany”（或等效）程序执行COM服务器时，它不会传递必要的命令行选项（如“-automation”）来注册服务器对象。不过，大多数框架会自动注册类对象。记录传递给服务器的命令行，看看是否是这种情况。 （3）服务器不会调用CoInitializeSecurity（大多数框架没有），也不声明AccessPermissions。请使用dcomcnfg进行检查。但是，这应该导致通话失败，不会启动新的服务器。

您不会说服务在哪个帐户下运行;你是否曾尝试以与交互式用户相同的帐户运行它，并允许它与桌面进行交互（作为调试措施 - 您不应该在生产中这样做）？

Answer 2

作为Windows NT服务运行一个VB6 COM服务器应用程序（一个OPC服务器）时，我一直在努力解决完全相同的问题（原始问题中没有提示COM服务器是否为VB6应用程序，但在我的情况是这样）。 最后一个Microsoft article已确认当VB6应用程序作为服务运行时（无论您如何设法让应用程序首先作为服务运行），COM/DCOM将不起作用。

以下是文章报价：

微软目前并不提倡，不支持，在运行Visual Basic应用程序如微软的Windows NT，Windows 2000和Windows XP的服务，因为应用程序可能会出现不稳定行为安装并运行微软Windows服务

而另一时：

开发人员可以期待DIF努力在Microsoft Visual Basic中编写的Microsoft Windows服务中采用Microsoft技术（例如ODBC，DCOM，OLE自动化和DAO）。出于这个原因以及已经提到的原因，Microsoft建议开发人员避免在Microsoft Visual Basic中编写的Microsoft Windows NT服务中使用这些技术。