Мы сталкиваемся с распространенной, но достаточно сложной проблемой, когда после обновления платформы 1С или при изменении конфигурации серверного кластера, код, ранее работавший безупречно, вдруг перестает создавать COM-объект на сервере. В частности, речь идет о попытке создания объекта V83.COMConnector, которая на сервере вызывает ошибку "Отказано в доступе" (код 0x80070005). При этом, аналогичный код, запущенный на клиенте, может прекрасно работать и создавать объект без каких-либо затруднений. Давайте вместе разберем эту ситуацию, выясним ее причины и найдем эффективные решения.
Наш сценарий выглядит так: после обновления платформы 1С и добавления второго сервера в кластер 1С, следующий код, выполняемый на сервере, завершается ошибкой:
&НаСервере
Процедура ТестНаСервере()
ComОбъект = Новый COMОбъект("V83.COMConnector"); // Здесь возникает ошибка
КонецПроцедуры
Ошибка, которую мы видим: "Ошибка при вызове конструктора (COMОбъект): -2147024891(0x80070005): Отказано в доступе."
При этом, если мы перенесем этот же код на клиент, он будет работать без проблем:
&НаКлиенте
Процедура ТестНаКлиенте(Команда)
ComОбъект = Новый COMОбъект("V83.COMConnector"); // Работает корректно на клиенте
КонецПроцедуры
Это явно указывает на то, что проблема кроется в конфигурации серверной части или в правах доступа на сервере, а не в самом коде или наличии компонента на клиенте.
Когда мы сталкиваемся с ошибками типа "Отказано в доступе" при создании COM-объектов на сервере 1С, одной из первых гипотез становится некорректная работа или наличие лишних COM+ приложений, которые управляют V83.COMConnector. Для детальной диагностики мы рекомендуем использовать специализированный инструмент.
V83.COMConnector (или любого другого COM-компонента 1С) создано COM+ приложение, это может быть источником проблемы. Иногда эти приложения создаются автоматически или вручную, но в некоторых сценариях (например, когда кластер содержит несколько серверов или после специфических обновлений) они могут вызывать конфликты доступа.Если в ходе диагностики на предыдущем шаге мы обнаружили COM+ приложение для V83.COMConnector, следующим шагом будет его удаление, поскольку оно может быть причиной конфликта прав доступа. Как показывает практика, иногда такое приложение не требуется и только вредит работе.
1CV8 или V82_COMConnector, или любое другое, связанное с 1С COM-коннектором).После удаления COM+ приложения попробуем повторно запустить наш код на сервере. Вероятно, ошибка "Отказано в доступе" исчезнет, но могут появиться новые.
После удаления COM+ приложения, мы можем столкнуться с новыми ошибками, такими как:
Эти ошибки явно указывают на то, что система теперь не может найти или загрузить соответствующий COM-компонент, а именно библиотеку comcntr.dll. Это происходит потому, что после удаления COM+ приложения могли нарушиться записи о регистрации класса в реестре или сама библиотека оказалась неверно зарегистрированной.
Для исправления этой ситуации нам необходимо перерегистрировать библиотеку comcntr.dll.
comcntr.dll. Обычно он расположен в папке с установленной платформой 1С, например, C:\Program Files\1cv8\8.3.X.XXX\bin\ (где 8.3.X.XXX — это номер вашей платформы).
regsvr32 comcntr.dll
regsvr32 из определенного системного каталога.
C:\Windows\SysWOW64\regsvr32.exe C:\Path\To\comcntr.dllC:\Windows\System32\regsvr32.exe C:\Path\To\comcntr.dllУбедитесь, что путь к comcntr.dll указан корректно для вашей установленной версии платформы 1С.
Как ни парадоксально, но после перерегистрации comcntr.dll, в некоторых случаях, особенно на 64-битных серверах 1С, для корректной работы COM-соединения может потребоваться повторное создание COM+ приложения. Это связано с тем, что COM+ обеспечивает дополнительный уровень изоляции и управления для COM-компонентов.
V83.COMConnector или соответствующего класса 1С, установим флажок в колонке "Создать/удалить". Это приведет к повторному созданию COM+ приложения.rphost) или, если возможно, весь сервер приложений 1С. Иногда даже требуется перезагрузка всего компьютера для полного применения изменений в DCOM и COM+ подсистемах Windows.После выполнения этих шагов мы снова попробуем запустить наш серверный код. В большинстве случаев, это должно привести к успешному созданию COMОбъект("V83.COMConnector").
Если после выполнения всех вышеописанных шагов проблема все еще не решена, или вы хотите более глубоко понять причины возникновения таких ошибок, рассмотрим дополнительные аспекты и методы диагностики.
Ошибка "Отказано в доступе" (0x80070005) чаще всего указывает на проблемы с разрешениями. Нам необходимо убедиться, что пользователь, под которым запущена служба агента сервера 1С (процесс rphost), обладает необходимыми правами:
comcntr.dll, и временных каталогов.HKEY_CLASSES_ROOT\CLSID\).Мы можем настроить разрешения DCOM с помощью системной утилиты "Службы компонентов" (dcomcnfg):
dcomcnfg из командной строки).SELF.V83.COMConnector, в разделе "Службы компонентов" -> "Компьютеры" -> "Мой компьютер" -> "Настройка DCOM". Оно может иметь имя, похожее на "1C:Enterprise 8.3 COMConnector".В некоторых случаях, если мы все же используем COM+ приложение для 1С (например, оно называется "1CV8" или "V82_COMConnector"), снятие одной галочки может решить проблему "Отказано в доступе":
Мы должны учитывать, что иногда брандмауэр Windows или стороннее антивирусное программное обеспечение могут блокировать создание COM-объектов или межпроцессное взаимодействие, особенно если COM-объект запускается в отдельном процессе или требует сетевого взаимодействия (что характерно для COMConnector при работе с удаленной базой).
Временно отключим брандмауэр и антивирус для проверки, но это не является долгосрочным решением. Если проблема исчезнет, нам потребуется настроить соответствующие исключения в этих программах.
Если наш сервер 1С 64-разрядный, а COM-компонент comcntr.dll является 32-разрядным (что возможно, если установлена 32-битная платформа 1С на 64-битной ОС), это может вызвать ошибки регистрации или загрузки класса. В таком случае мы можем:
comcntr.dll.При возникновении любых ошибок мы всегда должны проверять Журнал событий Windows (eventvwr.msc). В разделах "Система" и "Приложение" мы часто можем найти более подробную информацию об ошибках DCOM или COM, включая точные коды ошибок и имена процессов, которые их вызвали. Это может дать ценные указания на корневую причину проблемы.
Для самой глубокой диагностики мы можем использовать утилиты, такие как Process Monitor от Sysinternals. Запустим ее и отфильтруем события по процессам 1С-сервера (rphost.exe) в момент попытки создания COM-объекта. Это позволит нам отследить все обращения к файловой системе, реестру и сетевые запросы, выявляя, где именно происходит "отказано в доступе" или "файл не найден".
В завершение, мы подчеркнем, что после любых серьезных изменений в конфигурации COM, DCOM или после перерегистрации системных компонентов, крайне рекомендуется перезагрузить сервер. Это гарантирует, что все изменения вступят в силу и все системные кэши будут обновлены.
Таким образом, мы видим, что проблема создания COMОбъект("V83.COMConnector") на сервере 1С может иметь множество причин, от неправильной регистрации DLL до сложных настроек безопасности DCOM и COM+. Комплексный подход, включающий диагностику, корректную перерегистрацию компонентов и тщательную проверку прав доступа, позволяет успешно решить эту задачу.