Вызов 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,

У нас есть инструмент, который инкапсулирует x.exe so that it runs as a service под виндой. В этом случае мы никогда не получим COM-вызов в x.exe (проверено журналированием). Вот странная часть: от регистрации вызывающего сайта я могу сказать, что объект COM был успешно создан, а также вызов функции интерфейса не вызывает ошибку (SUCEEDED(hres) правда).

Есть идеи?

Answer 1

Я предполагаю, что происходит одна (или, возможно, все) из трех вещей (отсортированных по вероятности):

(1) Значение LocalService в ключе AppID не настроено, поэтому вместо этого оно запускается как обычная программа.

(2) Когда программа "srvany" (или эквивалентная) выполняет COM-сервер, она не передает необходимые параметры командной строки (например, "-automation") для регистрации объекта сервера. Большинство фреймворков регистрируют объекты классов автоматически. Зарегистрируйте командную строку, переданную на сервер, чтобы узнать, так ли это.

(3) сервер не вызывает CoInitializeSecurity (большинство фреймворков этого не делают) и не объявляет AccessPermissions. Проверьте это с dcomcnfg, Однако это должно было сделать сбой вызова, а не запускать новый сервер.

Вы не говорите, под какой учетной записью работает служба; Вы пробовали запустить его под той же учетной записью, что и интерактивный пользователь, и позволить ему взаимодействовать с рабочим столом (в качестве меры отладки - вы не должны делать это в рабочей среде!)?

Answer 2

Я столкнулся с точно такой же проблемой при запуске приложения COM-сервера VB6 (OPC-сервер) в качестве службы Windows NT (в исходном вопросе нет указания на то, является ли COM-сервер приложением VB6, но в моем случае это так), В конце статья Microsoft подтвердила, что COM/DCOM не будет работать, когда приложение VB6 запускается как служба (независимо от того, как вам удается запустить приложение как службу в первую очередь).

Вот цитата из статьи:

Microsoft в настоящее время не рекомендует и не поддерживает запуск приложений Visual Basic в качестве служб Microsoft Windows NT, Windows 2000 и Windows XP, поскольку приложения могут работать нестабильно при установке и запуске в качестве служб Microsoft Windows.

И другой:

Разработчики могут ожидать трудностей при использовании технологий Microsoft, таких как ODBC, DCOM, OLE Automation и DAO, в службе Microsoft Windows, написанной на Microsoft Visual Basic. По этой причине и по тем причинам, которые уже отмечались, Microsoft рекомендует разработчикам избегать использования этих технологий в службе Microsoft Windows NT, написанной на Microsoft Visual Basic.