Почему не создается COM-объект на сервере 1С при работе в терминальной сессии?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При разработке на управляемых формах часто возникает ситуация, когда при вызове метода Новый COMObject в процедурах с директивой &НаСервере мы получаем ошибку на терминальном сервере, хотя этот же код идеально работает при локальном выполнении. Давайте разберем, почему это происходит и как это исправить.

Понимание контекста выполнения кода

Первое, что нужно осознать: директива &НаСервере означает, что код исполняется на сервере 1С. Если сервер 1С и терминальный сервер — это разные машины, то код выполняется в контексте пользователя, от имени которого запущена служба сервера 1С, а не в контексте пользователя, работающего в данный момент в терминальной сессии.

Основные причины сбоев:

  1. Изоляция сеансов: Многие COM-объекты (особенно те, что имеют графический интерфейс или привязаны к рабочему столу) не могут инициализироваться в «Сеансе 0», в котором по умолчанию работают системные службы Windows.
  2. Разрядность процесса: Сервер 1С (x64) ищет 64-битную реализацию COM-объекта. Если ваша компонента установлена только как 32-битная, создание объекта завершится ошибкой.
  3. Права доступа DCOM: Служба 1С может не обладать правами на запуск конкретного COM-сервера.

Шаг 1: Проверка прав и настроек доступа

Разберемся с правами доступа. COM-объекты управляются через службу DCOM. Чтобы проверить настройки, воспользуемся оснасткой dcomcnfg:

  1. Откройте «Службы компонентов» (Component Services).
  2. Перейдите в «Компьютеры» -> «Мой компьютер» -> «Настройка DCOM».
  3. Найдите нужный объект в списке, нажмите правой кнопкой мыши и выберите «Свойства».
  4. На вкладке «Безопасность» проверьте параметры «Разрешения на запуск и активацию». Убедитесь, что пользователю, под которым работает Агент сервера 1С, разрешены локальный запуск и активация.

Шаг 2: Проверка разрядности компоненты

Посмотрим на архитектуру системы. Если сервер 1С установлен как 64-битное приложение, он будет обращаться к веткам реестра 64-битных приложений. Если ваша компонента AddIn.MySQL является 32-битной, она должна быть зарегистрирована в ветке WOW6432Node:

Проверьте следующие пути в реестре:

Для x64: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID

Для x86 (WOW6432Node): HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID

Если компонента там отсутствует, сервер 1С её просто «не увидит» при попытке вызвать Новый COMObject.

Шаг 3: Особенности работы в терминале и сеанс пользователя

Если объект требует доступа к профилю пользователя, помните, что у службы 1С профиль пользователя не загружен. Если компонента AddIn.MySQL при инициализации пытается прочитать настройки из HKEY_CURRENT_USER или пользовательских папок AppData, она выдаст ошибку, так как для службы 1С эти пути ведут в системные папки, а не к пользователю терминала.

Пример корректного вызова в модуле:


&НаСервере
Функция ИнициализироватьКомпоненту()
    Попытка
        Сайт = Новый COMObject("AddIn.MySQL");
        Возврат Сайт;
    Исключение
        ЗаписьЖурналаРегистрации("Ошибки COM", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
        Возврат Неопределено;
    КонецПопытки;
КонецФункции

Как проводить диагностику?

Чтобы понять, что именно идет не так, выполним следующие действия:

Резюмируя, при разделении серверов всегда проверяйте, установлена ли компонента именно на сервере 1С, а не только на терминальном сервере, и хватает ли службе сервера 1С прав на её запуск в рамках текущей политики безопасности Windows.

← На главную