← На главную

Часто при организации обмена данными между несколькими базами 1С средствами прямого COM-соединения системные администраторы и программисты сталкиваются с неприятной проблемой: компонента comcntr.dll периодически «слетает». Вы можете зарегистрировать ее утилитой regsvr32, обмен начинает работать, но спустя полдня или после перезагрузки сервера снова начинают сыпаться ошибки инициализации COM-объекта. В этой статье мы подробно проанализируем ситуацию, разберем причины такого поведения и по шагам настроим стабильную работу компоненты.

Архитектурная альтернатива: отказ от COM в пользу веб-сервисов

Прежде чем углубляться в системные настройки, рассмотрим концептуальный подход, который рекомендует сама фирма «1С». Использование V83.COMConnector считается устаревшим и нестабильным методом интеграции, особенно в высоконагруженных серверных средах. Если у вас регулярно возникают сбои обмена, первым делом проанализируем возможность перехода на современные протоколы.

Рассмотрим переход на следующие технологии:

1. HTTP-сервисы и Web-сервисы: Позволяют обмениваться данными по стандартным веб-протоколам. Они независимы от разрядности платформы, не требуют регистрации DLL на уровне системы и работают намного стабильнее.
2. Протокол OData: Стандартный REST-интерфейс, который 1С умеет генерировать автоматически для объектов метаданных (справочников, документов и т.д.).

Однако, если переписать готовый нетиповой обмен прямо сейчас нет времени, нам нужно стабилизировать работу существующего COM-соединения. Давайте выясним причины, по которым регистрация компоненты может теряться.

Шаг 1. Решение конфликта разрядности через Службы компонентов (COM+)

Самая частая причина, из-за которой «слетает» comcntr.dll — это конфликт разрядности между вызывающим процессом и самой библиотекой. Например, 64-битный сервер 1С (процесс rphost.exe) пытается инициализировать COM-объект, но в системе корректно зарегистрирована только 32-битная библиотека (или наоборот). Регистрация через стандартную командную строку часто привязывается к интерактивной сессии пользователя (например, по RDP) и при закрытии сессии «исчезает».

Разберем по шагам, как навсегда решить эту проблему изоляцией компоненты в отдельном приложении COM+:

1. Откройте панель управления Windows, перейдите в «Администрирование» и запустите Службы компонентов (Component Services).
2. В дереве консоли разверните: Службы компонентов -> Компьютеры -> Мой компьютер -> Приложения COM+.
3. Создайте новое приложение: кликните правой кнопкой мыши, выберите «Создать» -> «Приложение».
4. В мастере выберите «Создать пустое приложение». Назовите его, например, 1C_COM_Connector.
5. Укажите тип активации: Приложение сервера (Server application). Это позволит компоненте работать в собственном изолированном процессе dllhost.exe.
6. На вкладке Удостоверение (Identity) критически важно указать конкретного системного пользователя. Выберите опцию «Указанный пользователь» и введите логин и пароль учетной записи, от имени которой работает служба Агента сервера 1С (ragent.exe). Никогда не оставляйте «Интерактивный пользователь», иначе служба упадет при выходе администратора из системы.
7. Откройте созданное приложение 1C_COM_Connector, перейдите в папку «Компоненты». Кликните правой кнопкой мыши -> «Создать» -> «Компонент».
8. Выберите «Установка новых компонентов» и укажите путь к файлу comcntr.dll в папке bin нужной версии платформы (например, C:\Program Files\1cv8\8.3.19.1467\bin\comcntr.dll).
9. Перейдите в свойства установленного компонента на вкладку «Безопасность» и убедитесь, что стоит галочка Разрешить динамическую проверку доступа. Настройте права для пользователей, которые будут инициировать обмен.

Этот метод создает надежный мост (surrogate) между архитектурами и гарантирует, что компонента всегда будет доступна серверу 1С.

Шаг 2. Устранение путаницы при нескольких версиях платформы 1С

Проанализируем ситуацию: на сервере может быть установлено несколько версий платформы (например, 8.3.18.xxx и 8.3.19.1467). Операционная система Windows хранит пути к COM-классам в системном реестре. При запуске любого фонового процесса, инсталлятора или другой службы иной версии платформы, ветка реестра может автоматически «перезаписаться» на путь к другой версии comcntr.dll.

Посмотрим, как очистить реестр и зафиксировать нужную версию:

1. Откройте редактор реестра (regedit).
2. Перейдите в ветку HKEY_CLASSES_ROOT\CLSID\ и выполните поиск по ключу V83.COMConnector.
3. Удалите все найденные старые ветки, которые ссылаются на неактуальные версии платформы 1С.
4. Убедитесь, что у пользователя, под которым запускается служба 1С, есть полные права на раздел HKEY_LOCAL_MACHINE\SOFTWARE\Classes\V83.COMConnector.
5. Зарегистрируйте библиотеку вручную с явным указанием пути через командную строку (запущенную от имени Администратора): regsvr32 "C:\Program Files\1cv8\8.3.19.1467\bin\comcntr.dll"

Шаг 3. Влияние антивирусов и службы DEP

Иногда настройки безопасности Windows откатывают изменения реестра «на лету» или блокируют выполнение кода из DLL. Обратим внимание на технологию DEP (Data Execution Prevention).

Если система защиты сочтет действия COM-объекта подозрительными, она молча завершит процесс, что со стороны 1С будет выглядеть как внезапно слетевшая регистрация. Чтобы исключить эту причину:

1. Добавьте исполняемые файлы сервера 1С (ragent.exe, rmngr.exe, rphost.exe) в список исключений DEP.
2. Временно отключите DEP для проверки.
3. В настройках корпоративного антивируса (например, Kaspersky или Windows Defender) обязательно добавьте всю папку C:\Program Files\1cv8\ в исключения из сканирования файлов и защиты системного реестра.

Шаг 4. Особенности релиза 1С 8.3.19.1467 и падение конфигуратора

В ходе анализа логов и сообщений администраторов выясняется, что релизы ветки 8.3.19 (в частности 8.3.19.1467) имеют ряд внутренних ошибок, связанных с утечками памяти и нестабильностью интерфейса. Это может проявляться не только в работе COM, но и в виде странных вылетов платформы.

Например, при попытке добавить элемент «Группа - обычная» на форму внутри расширения конфигурации, Конфигуратор может полностью закрываться без сохранения изменений, причем только в одной конкретной базе.

Разберем способы решения проблемы с вылетом Конфигуратора:

1. Отключение аппаратного ускорения: Во многих случаях на релизах 8.3.19 падения при отрисовке форм в расширениях лечатся банальным отключением аппаратного ускорения видеокарты на сервере.
2. Обновление платформы: Данные ошибки метаданных исправлены в более новых релизах (например, начиная с 8.3.19.1522). Настоятельно рекомендуем обновить платформу.
3. Исправление кэша базы: Так как конфигуратор вылетает только в одной базе из десяти, это явный признак повреждения внутреннего кэша. Сделайте выгрузку расширения в файл (.cfe), полностью удалите расширение из базы, выполните процедуру «Тестирование и исправление» (ТиИ) с очисткой кэша, после чего загрузите расширение обратно. Убедитесь, что в расширении нет зацикленных заимствованных элементов формы.

Диагностика: как найти точную причину падения

Если после настройки COM+ проблема все еще проявляется, нам необходимо собрать больше технических данных. Включите Технологический журнал (ТЖ) 1С. Для этого создайте или отредактируйте файл logcfg.xml в папке conf.

Настройте сбор событий EXCP (исключительные ситуации) и PROC (процессы). Параллельно с этим отслеживайте системный журнал Windows («Просмотр событий» -> «Журналы Windows» -> «Приложение» и «Система»). Ищите события категории Error от источника Application Error или COM+ в те моменты, когда по расписанию запускаются регламентные задания обмена.

Комплексный подход: перенос COM-компоненты в изолированное приложение COM+, настройка прав реестра, исключения антивируса и обновление платформы на более стабильный релиз, позволяет полностью искоренить проблему с постоянной потерей регистрации comcntr.dll.