將可執行文件作爲服務運行時，COM調用不起作用

我們有一個託管COM服務器的可執行文件，例如x.exe。在呼叫站點上COM對象的實例化如下：將可執行文件作爲服務運行時，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)爲真）。

任何想法？

來源

2010-06-03 Mitch

您是否試過Process Monitor？ – sharptooth 2010-06-03 13:00:02

很難與HRESULT爭論。聽起來問題在於你的日誌代碼。 – 2010-06-03 13:55:29

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

（1）中的AppID密鑰A LocalService價值尚未配置，使得它開始作爲一個經常性項目，而不是。（2）當「srvany」（或等效）程序執行COM服務器時，它不會傳遞必要的命令行選項（如「-automation」）來註冊服務器對象。不過，大多數框架會自動註冊類對象。記錄傳遞給服務器的命令行，看看是否是這種情況。（3）服務器不會調用CoInitializeSecurity（大多數框架沒有），也不聲明AccessPermissions。請使用dcomcnfg進行檢查。但是，這應該導致通話失敗，不會啓動新的服務器。

您不會說服務在哪個帳戶下運行;你是否曾嘗試以與交互式用戶相同的帳戶運行它，並允許它與桌面進行交互（作爲調試措施 - 您不應該在生產中這樣做）？

來源

2010-11-13 14:41:08 RolKau

作爲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服務中使用這些技術。

來源

2014-03-25 12:42:44

將可執行文件作爲服務運行時，COM調用不起作用

回答

相關問題