Как устранить ошибку несовпадения версий при COM-соединении в 1С x64 и x86?

← На главную

При обновлении платформы «1С:Предприятие» системные администраторы и разработчики нередко сталкиваются с ситуацией, когда регламентный или ручной обмен между базами данных завершается критической ошибкой несоответствия версий. Типичный сценарий: на сервере развернута 64-битная версия платформы, однако при попытке установить соединение через COMОбъект система сообщает о конфликте версий библиотек, пока принудительно не будет установлена 32-разрядная версия коннектора. Проанализируем, почему возникает эта неполадка, как устроена работа COM-компонентов в операционной системе Windows и какими способами можно навсегда решить проблему взаимодействия разноразрядных приложений.

Выясним причину конфликта версий и разрядностей

Для понимания корня проблемы разберем механизм вызова COM-объекта в программном коде 1С. Когда выполняется типовая инициализация соединения:


Попытка
    COMСоединитель = Новый COMОбъект("V83.COMConnector");
    УстановленноеСоединение = COMСоединитель.Connect(СтрокаПодключения);
Исключение
    ЗаписьЖурналаРегистрации("ОшибкаCOM", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
КонецПопытки;

операционная система обращается к системному реестру Windows, чтобы отыскать зарегистрированный класс с идентификатором V83.COMConnector и загрузить соответствующую динамическую библиотеку comcntr.dll. Разрядность загружаемой библиотеки строго диктуется разрядностью процесса, инициирующего вызов, а не форматом информационной базы (файловая она или клиент-серверная):

64-разрядный вызывающий процесс: Если код выполняется на стороне сервера 1С в контексте рабочего процесса rphost.exe (например, внутри фонового задания) или в 64-битном клиенте, Windows обращается к основной 64-разрядной ветке реестра и требует загрузки 64-битного файла comcntr.dll.
32-разрядный вызывающий процесс: Если соединение создается из 32-битного тонкого или толстого клиента, стороннего 32-битного скрипта или приложения, 32-битный процесс физически не способен подгрузить 64-битную библиотеку в собственное адресное пространство. Windows перенаправляет запрос в раздел реестра WOW6432Node, где ищет 32-битную версию коннектора.

Ошибка различия версий возникает в двух случаях: либо в соответствующей ветке реестра осталась ссылка на старый номер релиза платформы после незавершенного обновления, либо номер сборки используемой библиотеки comcntr.dll не совпадает до последней цифры с версией запущенного кластера серверов 1С.

Способ 1. Точная ручная перерегистрация библиотек нужной разрядности

Рассмотрим порядок ручной регистрации COM-компонентов. Стандартная утилита регистрации regsvr32 ведет себя по-разному в зависимости от того, из какого системного каталога она запущена. Если выполнить команду без указания полного пути, на 64-битной системе будет задействована 64-битная утилита, что не обновит записи для 32-битных клиентов.

Разберем по шагам регистрацию библиотек через командную строку, запущенную с правами администратора:

Для корректной регистрации 64-разрядного коннектора выполним команду:
```
C:\Windows\System32\regsvr32.exe "C:\Program Files\1cv8\8.3.XX.XXXX\bin\comcntr.dll"
```
Для регистрации 32-разрядного коннектора (если на сервере параллельно используются 32-битные клиенты или сторонний софт) выполним команду из системного каталога SysWOW64:
```
C:\Windows\SysWOW64\regsvr32.exe "C:\Program Files (x86)\1cv8\8.3.XX.XXXX\bin\comcntr.dll"
```

Важно: При установке новой платформы через стандартный инсталлятор флаг установки компонента COM-соединение по умолчанию может быть выключен. Проверьте через «Панель управления» -> «Программы и компоненты» -> «Изменить», установлен ли соответствующий модуль в составе дистрибутива нужной версии платформы.

Способ 2. Настройка суррогатного процесса COM+ для кросс-разрядного вызова

Посмотрим на более универсальное и надежное архитектурное решение. Чтобы не устанавливать две платформы (x86 и x64) одновременно и исключить конфликты разрядностей, настроим специальное приложение COM+ на сервере. В этом случае библиотека comcntr.dll будет запускаться в изолированном суррогатном процессе Windows dllhost.exe, к которому смогут беспрепятственно обращаться процессы любой битности.

Разберем пошаговый процесс настройки приложения в оснастке Windows:

Нажмите комбинацию клавиш Win + R, введите команду dcomcnfg и нажмите Enter для запуска консоли «Службы компонентов».
В дереве консоли перейдите по пути: Службы компонентов -> Компьютеры -> Мой компьютер -> Приложения COM+.
Нажмите правой кнопкой мыши по узлу «Приложения COM+», выберите Создать -> Приложение.
В мастере создания выберите Установить новое приложение вручную, задайте имя (например, 1CV8_COMConnector) и укажите тип активации Серверное приложение (Server application).
На шаге выбора удостоверения укажите учетную запись с достаточными правами (рекомендуется указать того же пользователя, от имени которого стартует служба ragent сервера 1С).
Откройте созданное приложение, перейдите в папку Компоненты, нажмите правой кнопкой мыши и выберите Создать -> Компонент.
Выберите пункт Установка новых компонентов и укажите путь к файлу comcntr.dll из подкаталога bin установленной 64-битной платформы 1С: C:\Program Files\1cv8\8.3.XX.XXXX\bin\comcntr.dll
Откройте свойства добавленного компонента V83.COMConnector, перейдите на вкладку Транзакции и убедитесь, что переключатель установлен в положение Не поддерживаются.

При такой конфигурации любые запросы на создание COM-соединения перенаправляются в отдельный процесс dllhost.exe, что полностью снимает зависимость от разрядности клиента и защищает рабочий процесс сервера 1С от случайных сбоев внешнего модуля.

Ограничения COM и современные альтернативы для интеграции

Проанализируем эксплуатационные особенности COM-коннектора. Несмотря на привычность, механизм COM накладывает жесткие инфраструктурные ограничения:

Зависимость от Windows: Механизм невозможно использовать на операционных системах семейства Linux, что делает архитектуру несовместимой с кроссплатформенными кластерами серверов 1С.
Проблемы с освобождением памяти: При частых и объемных обменах COM-соединения склонны накапливать неутилизированную память внутри процесса, что требует регулярного перезапуска рабочих процессов rphost.
Сложность сопровождения: Каждое регламентное обновление платформы требует синхронных действий по обновлению DLL-библиотек на всех серверах интеграции.

В современной корпоративной разработке рекомендуется заменять COM-соединения на протоколы сетевого обмена:

HTTP-сервисы и Web-сервисы (SOAP): Работают поверх стандартизированных сетевых стеков HTTP/HTTPS, полностью платформонезависимы, работают на любых ОС и не зависят от номера сборки или разрядности установленной платформы.
Автоматический REST-интерфейс (OData): Предоставляет прямой доступ к справочникам, документам и регистрам через структурированные HTTP-запросы без необходимости конфигурирования дополнительного кода в целевой базе данных.
Асинхронные очереди сообщений: Использование брокеров сообщений (RabbitMQ, Apache Kafka) в связке с форматами сериализации JSON или XML позволяет полностью разделить жизненные циклы информационных систем и избавиться от блокировок при передаче данных.