Вызов COM не работает при размещении исполняемого файла в качестве службы

У нас есть исполняемый файл, на котором размещен 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. В этом случае мы никогда не получаем COM-вызов в x.exe (подтверждено протоколированием). Вот странная часть: из журнала вызывающего сайта я могу сказать, что экземпляр COM-объекта был успешно создан, а также вызов функции интерфейса не приводит к ошибке (SUCEEDED(hres) верно).

Любые идеи?


windows-services com dcom
person Mitch    schedule 03.06.2010    source источник
comment
Вы пробовали монитор процессов?   -  person sharptooth    schedule 03.06.2010
comment
Трудно спорить с HRESULT. Мне кажется, что проблема в вашем коде регистрации.   -  person Hans Passant    schedule 03.06.2010

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

person RolKau    schedule 13.11.2010

arrow_upward
0
arrow_downward

Я боролся с точно такой же проблемой при запуске приложения 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.

person Francois Nel    schedule 25.03.2014