Ограничение сервера exe ATL только одним процессом (экземпляром)

Question

У меня есть ATL exe-сервер, написанный на C ++ (Visual Studio 2010, с объединением dll прокси-стержня). Исполняемый файл скомпилирован для Windows 7 x86 и x64. Следующее происходит на обеих архитектурах:

Exe-сервер ATL должен функционировать как «серверный процесс», то есть - для каждой машины должен существовать один процесс (MyATLServer.exe, ТОЛЬКО один!), И многие клиенты (давайте будем простыми: на одной машине) потребляют COM объекты из него. Сервер сохраняет состояние приложения (в памяти), и все клиенты должны «делиться» этим состоянием, используя открытые COM-объекты сервера.

Сервер exe обычно запускается при запуске системы, потому что он вызывается COM-вызовом для создания одного из размещенных на нем объектов. Вызов происходит изнутри процесса spoolsv.exe (служба диспетчера очереди печати). Это приводит к тому, что серверный процесс запускается от имени пользователя «SYSTEM» (я полагаю, из-за того, что spoolsv.exe работает с «SYSTEM»).

Когда один из клиентов создает COM-объект с сервера ATL, создается другой процесс (снова MyATLServer.exe) (выполняется под пользователем, вошедшим в Windows), поэтому он не может совместно использовать состояние приложения с «исходным» «один (который работает под« СИСТЕМА »). Второй клиент подключится к тому, который был создан зарегистрированным пользователем («второй»).

После поиска бесчисленных форумов в сети мне удалось сделать следующие выводы:

1) Мой сервер ATL использует модуль ATL по умолчанию (автоматически сгенерированный VS2010), который наследуется от ATL :: CAtlExeModuleT <>. Копаясь в заголовках ATL, я уверен, что этот модуль вызывает AtlComModuleRegisterClassObjects с правильными флагами для этого вида использования (dwClsContext = CLSCTX_LOCAL_SERVER, flags = REGCLS_MULTIPLEUSE | REGCLS_SUSPENDED). Так что это исключает.

2) Используя start -> run -> dcomcnfg -> DCOM Config -> MyATLServer -> Properties, я установил параметр «Этот пользователь» на вкладке «Удостоверение» (с пользователем локального администратора). На вкладке «Местоположение» параметр «Запустить приложение на этом компьютере» не выбран и выделен серым цветом. Это заставило меня искать снова, и я попал сюда: http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/4f63ee11-e472-40f9-85db-a6b235d7579c. Ссылка объясняет, что x64-версия утилиты dcomcnfg глючит, и ее следует использовать в 32-битной версии под x64 Windows (start-> run -> 'mmc comexp.msc / 32'). После проверки на двух системах (по одной на каждой) я обнаружил, что параметр «Запустить приложение на этом компьютере» выделен серым цветом и не выбран на обоих.

С этого момента я полностью потерян (и пытаюсь подавить разочарование ... :-)). Я на правильном пути? Кто-нибудь делал это раньше?

Или первоначальное намерение - как сделать мой ATL exe-сервер «отдельно обработанным»?

Спасибо!

Омри

Answer 1

Хорошо ... Итак, наконец я собираюсь ответить себе: -)

Я нашел время, чтобы попытаться решить эту проблему снова (и снова ...). После установки 2 разных новых машин разработчика (Win7x86 и Win7x64) и использования ТОЛЬКО 32-битной версии dcomcnfg - работала одна машина, 32-битная (Win7x86)!

Копаясь в "нерабочих" машинах, я обнаружил, что столкнулся с GUID, черт возьми! На компьютере с архитектурой x64 COM-объекты были зарегистрированы с разными идентификаторами GUID, чем значения в файлах кода (генерировать код). Чтобы сделать это даже трудным, я использовал точки подключения, которые также были зарегистрированы с недопустимыми идентификаторами GUID. Под этим я подразумеваю - значения GUID в реестре не были правильными! До сих пор я понятия не имею, почему это происходит, но я на 100% уверен, что мастера COM в VS2010 глючат (генерируют частичный код, если есть ...), возможно, код, который генерируют эти мастера, вызывает проблемы с регистрацией.

Чтобы решить эту проблему, я вручную удалил все соответствующие разделы реестра сервера ATL, отменил автоматическую регистрацию COM в проекте VS и сам зарегистрировал EXE (на x64 с помощью% WINDIR% \ SysWOW64 \ cmd.exe консоль, а не родная x64 одна).

После ручной регистрации сервера все работало нормально (как и ожидалось, один процесс, общий для нескольких клиентов), и в утилите конфигурации dcomcnfg не было серых флажков.

Я уверен, что это решение имеет много необъяснимых пробелов, но оно работает для меня (пока ...).

Приветствия; -)