1

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

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

这一切works fine when x runs as an regular application。

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

有任何想法吗？

4

2 回答 2

2

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

(1) AppID 键中的LocalService值未配置，使其作为常规程序启动。

(2) 当“srvany”（或等效）程序执行 COM 服务器时，它没有传递必要的命令行选项（如“-automation”）来注册服务器对象。不过，大多数框架会自动注册类对象。记录传递给服务器的命令行以查看是否是这种情况。

(3) 服务器不调用CoInitializeSecurity（大多数框架不调用）并且不声明AccessPermissions。用dcomcnfg. 但是，这应该使调用失败，而不是启动新服务器。

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

于 2010-11-13T14:41:08.707 回答
0

在将 VB6 COM 服务器应用程序（OPC 服务器）作为 Windows NT 服务运行时，我遇到了完全相同的问题（原始问题中没有表明 COM 服务器是否是 VB6 应用程序，但在我的情况下是） . 最后，一篇Microsoft 文章证实，当 VB6 应用程序作为服务运行时，COM/DCOM 将不起作用（无论您首先设法让应用程序作为服务运行的方式如何）。

这是文章的引述：

Microsoft 目前不推荐也不支持将 Visual Basic 应用程序作为 Microsoft Windows NT、Windows 2000 和 Windows XP 服务运行，因为这些应用程序在安装和作为 Microsoft Windows 服务运行时可能表现出不稳定的行为

还有一个：

开发人员在使用 Microsoft Visual Basic 编写的 Microsoft Windows 服务中使用诸如 ODBC、DCOM、OLE 自动化和 DAO 等 Microsoft 技术时会遇到困难。由于这个原因，以及已经提到的那些原因，Microsoft 建议开发人员避免在用 Microsoft Visual Basic 编写的 Microsoft Windows NT 服务中使用这些技术。

于 2014-03-25T12:42:44.610 回答