Как исправить ошибку «Класс не зарегистрирован» при создании COMОбъект("ADODB.Connection") в 1С?

← На главную

При переносе внешних обработок, выгрузок или модулей интеграции с одного компьютера на другой (особенно часто это происходит при переезде на операционные системы Windows Server 2008 / 2012 / 2016 / 2019 / 2022) разработчики и системные администраторы часто сталкиваются с неприятной ошибкой. При попытке инициализировать соединение с базой данных через ADO система выдает критический сбой: «Ошибка при создании COMОбъект("ADODB.Connection"). Класс не зарегистрирован».

Ситуация осложняется тем, что простые попытки зарегистрировать целевую библиотеку через утилиту regsvr32 не дают никакого результата, а другие COM-объекты (например, Excel.Application или V83.ComConnector) могут создаваться абсолютно штатно. В этой статье мы подробно разберем, почему возникает эта проблема, как провести точечную диагностику разрядности и какие шаги необходимо предпринять для полного восстановления работоспособности механизмов ADO в среде 1С:Предприятие.

Выясняем главную причину: конфликт разрядности (32-бит против 64-бит)

Для начала проанализируем архитектуру операционной системы и платформы 1С. Современные серверные операционные системы Windows являются 64-разрядными (x64). При этом платформа 1С:Предприятие (как клиентское приложение, так и серверная служба) очень часто устанавливается в 32-разрядном варианте (x86). Это ключевой момент.

В Windows x64 существуют два параллельных пространства для COM-объектов:

64-битное пространство: библиотеки хранятся в каталоге C:\Program Files, а их регистрация в реестре находится в стандартных ветках.
32-битное пространство (подсистема WOW64): библиотеки находятся в каталоге C:\Program Files (x86), а их регистрационные данные изолированы в ветке реестра HKEY_CLASSES_ROOT\Wow6432Node.

Когда 32-битный процесс 1С запрашивает создание объекта COMОбъект("ADODB.Connection"), операционная система обращается исключительно к 32-битному реестру. Если в нем отсутствует нужная запись или 32-битная библиотека ядра ADO повреждена, Windows возвращает ошибку «Класс не зарегистрирован», даже если 64-битная версия ADO в системе работает безупречно.

Шаг 1. Изолированная диагностика разрядности с помощью VBScript

Прежде чем изменять настройки операционной системы, нам необходимо точно определить, в каком именно окружении (32 или 64 бита) повреждена регистрация ADO. Для этого мы выполним простой и эффективный тест, исключив влияние самой платформы 1С.

Создадим на сервере обычный текстовый файл с именем test_ado.vbs и поместим в него следующий код:


Set connection = CreateObject("ADODB.Connection")
WScript.Echo "Компонент ADODB успешно создан!"

Теперь поочередно запустим этот скрипт через 64-битную и 32-битную версии системного интерпретатора Windows Script Host.

Для проверки 64-битного окружения откроем командную строку и выполним команду:

C:\Windows\System32\wscript.exe C:\ПутьКФайлу\test_ado.vbs

Для проверки 32-битного окружения (WOW64) выполним команду:

C:\Windows\SysWOW64\wscript.exe C:\ПутьКФайлу\test_ado.vbs

Проанализируем результаты выполнения:

Если при запуске из System32 ошибок нет, а из SysWOW64 появляется сообщение «Невозможно создание объекта контейнером ActiveX», это подтверждает нашу гипотезу: 32-битное окружение ADO на сервере не функционирует, что и блокирует работу 1С.
Если ошибки возникают в обоих случаях, значит, системные библиотеки ADO повреждены глобально.

Шаг 2. Принудительная регистрация библиотек OLE DB

Объект ADODB.Connection является высокоуровневой надстройкой над технологией OLE DB. Часто системные администраторы пытаются зарегистрировать только файл msado15.dll, забывая о том, что без работоспособного низкоуровневого ядра OLE DB вся цепочка вызовов рушится.

Выполним последовательную регистрацию всех необходимых 32-битных компонентов. Для этого откроем командную строку строго от имени Администратора и выполним следующий пакет команд:


cd C:\Windows\SysWOW64
regsvr32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll"
regsvr32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32r.dll"
regsvr32.exe "C:\Program Files (x86)\Common Files\System\ado\msado15.dll"

После выполнения каждой команды должно появиться диалоговое окно RegSvr32 с сообщением об успешном завершении операции. Перезапустим наш диагностический VBS-скрипт через SysWOW64 для проверки изменений.

Шаг 3. Решение проблемы совместимости интерфейсов (Windows Server 2008 R2 / Win 7 SP1)

Если регистрация библиотек прошла успешно, но ошибка в 1С сохраняется, мы можем иметь дело с известной проблемой нарушения обратной совместимости интерфейсов ADO, которую корпорация Microsoft допустила при выпуске пакетов обновления Service Pack 1 для Windows 7 и Windows Server 2008 R2. Изменения в GUID интерфейсов привели к тому, что программы, скомпилированные в средах без SP1, теряют связь с ADO на обновленных серверах.

Для решения этой проблемы рассмотрим два пути:

Установка официального исправления: необходимо скачать и установить обновление безопасности KB2517589 (или более позднее накопительное обновление для вашей версии ОС), которое восстанавливает совместимость интерфейсов ADO.
Временная замена библиотеки: в качестве обходного пути допускается замена файла msado15.dll в каталоге C:\Program Files (x86)\Common Files\System\ado\ на аналогичный файл со стабильно работающего компьютера той же разрядности (перед заменой обязательно сделайте резервную копию оригинального файла и остановите все службы, которые могут его использовать).

Шаг 4. Исправление поврежденных веток системного реестра

Иногда при установке стороннего программного обеспечения (например, 64-битных версий Microsoft Office или СУБД) инсталляторы некорректно перезаписывают пути к библиотекам типов (TypeLib) и классам (CLSID), перенаправляя 32-битные вызовы на 64-битные файлы.

Проанализируем состояние системного реестра. Откроем редактор реестра regedit и перейдем по следующим путям:

Проверим регистрацию класса ADODB.Connection для 32-битных приложений:
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}
Внутри этого раздела найдем подраздел InprocServer32. Параметр (По умолчанию) должен содержать строгий путь к 32-битной библиотеке:
C:\Program Files (x86)\Common Files\System\ado\msado15.dll.
Если там указан путь без (x86), вручную скорректируем его.
Проверим библиотеку типов (TypeLib):
HKEY_CLASSES_ROOT\TypeLib\{00000200-0000-0010-8000-00AA006D2EA4}
Внутри подраздела с номером версии (например, 2.8 или 6.0) обязательно должен присутствовать каталог win32, указывающий на путь к 32-битной DLL. Если присутствует только раздел win64, создадим раздел win32 вручную и пропишем корректный путь к файлу в каталоге Program Files (x86).

Шаг 5. Альтернативное решение: Создание COM+ приложения-обертки

Если операционная система сильно повреждена, а переустановка компонентов OLE DB не дает результата, мы можем прибегнуть к архитектурному обходному пути. Мы заставим Windows запускать 32-битную компоненту в специальном изолированном суррогатном процессе dllhost.exe с повышенными правами доступа.

Разберем этот процесс по шагам:

Нажмем сочетание клавиш Win + R, введем команду comexp.msc и нажмите Enter для запуска утилиты «Службы компонентов».
Раскроем дерево консоли: Консоль управления -> Службы компонентов -> Компьютеры -> Мой компьютер.
Нажмем правой кнопкой мыши по разделу Приложения COM+ и выберем Создать -> Приложение.
В открывшемся мастере выберем «Создать новое приложение», укажем понятное имя (например, ADODB_Wrapper) и установим переключатель в положение «Серверное приложение» (это критически важно для запуска в отдельном процессе).
На шаге выбора удостоверения укажем учетную запись с правами Администратора (или выберите «Интерактивный пользователь», если работа ведется в терминальной сессии).
Перейдем в созданное приложение, откроем ветку Компоненты, нажмем правой кнопкой мыши и выберем Создать -> Компонент.
В мастере установки выберем «Установка новых компонентов» и укажем путь к нашей 32-битной библиотеке: C:\Program Files (x86)\Common Files\System\ado\msado15.dll.

После выполнения этой настройки операционная система будет автоматически перенаправлять все запросы 1С на создание ADODB.Connection через настроенное нами COM+ приложение, изолируя его от локальных проблем регистрации DLL в сессии конкретного пользователя.

Шаг 6. Итоговый тест с использованием UDL-файла

Чтобы окончательно убедиться, что стек OLE DB и ADO в 32-битном пространстве функционирует исправно, проведем финальный тест с помощью встроенного инструмента тестирования связей Windows:

Создадим на рабочем столе пустой текстовый файл и переименуем его в test_connect.udl (убедитесь, что расширение файла действительно изменилось, а не осталось .udl.txt).
Поскольку обычный двойной клик откроет этот файл в 64-битной версии конфигуратора, запустим его принудительно в 32-битном режиме через командную строку:
```
C:\Windows\syswow64\rundll32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\ПутьКФайлу\test_connect.udl
```
В открывшемся окне свойств на вкладке «Провайдер» (Provider) мы должны увидеть полный список установленных в системе 32-битных драйверов OLE DB (включая Microsoft Jet, OLE DB Provider for SQL Server и др.).
Выберем нужного провайдера, перейдем на вкладку «Подключение», укажем параметры авторизации и нажмем кнопку «Проверить подключение». Если тест прошел успешно, значит, вся цепочка OLE DB/ADO полностью готова к работе в среде 1С:Предприятие!

Выполнив предложенные шаги, мы гарантированно избавимся от ошибки «Класс не зарегистрирован» и обеспечим стабильный обмен данными между 1С и внешними источниками данных.