При обновлении платформы 1С:Предприятие до версий 8.3.18, 8.3.19 и выше системные администраторы часто сталкиваются с критической ошибкой при попытке автоматического завершения сеансов. Внешние утилиты, такие как Effector Saver, начинают выдавать сообщение об ошибке: Access violation at address in module 'rtrsrvc.dll'. Это происходит из-за изменений в архитектуре взаимодействия через COM-соединение, которые внедрила компания 1С.
В этой статье мы подробно разберем, как обойти эту проблему, реализовав механизм выгона пользователей программными средствами самой 1С, а также рассмотрим альтернативные способы настройки сервера администрирования для стабильной работы бэкапов.
Проанализируем ситуацию: ошибка обращения к памяти в модуле rtrsrvc.dll (Read of address 00000000) обычно указывает на то, что внешнее приложение пытается обратиться к 32-битному COM-объекту, который не может корректно проинициализировать интерфейсы администрирования в новой версии платформы. Начиная с версии 8.3.18, 1С изменила механизмы защиты и работы с памятью, что сделало классический V83.COMConnector менее стабильным. Если перерегистрация библиотек через regsvr32 не помогает, нам следует рассмотреть переход на встроенные инструменты платформы или современные методы администрирования через RAS.
Рассмотрим самый надежный способ — создание внутреннего механизма в самой конфигурации. Это позволит нам не зависеть от внешних COM-библиотек. Мы можем создать регламентное задание, которое будет выполняться по расписанию перед началом процесса резервного копирования.
Разберем по шагам, как программно установить блокировку сеансов, которая заставит клиентские приложения завершить работу. Для этого используется объект БлокировкаСеансов. Посмотрим на пример кода, который можно разместить в модуле регламентного задания:
Процедура УстановитьБлокировкуДляБэкапа() Экспорт
// Создаем объект блокировки
Блокировка = Новый БлокировкаСеансов;
// Устанавливаем параметры блокировки
// Код разрешения позволяет администратору войти в базу даже при активной блокировке
Блокировка.КодРазрешения = "BackupAdminKey123";
// Определяем временной интервал (например, на 30 минут)
Блокировка.Начало = ТекущаяДата();
Блокировка.Конец = ТекущаяДата() + 1800;
Блокировка.Сообщение = "Внимание! База закрыта для проведения технического обслуживания. Пожалуйста, завершите работу.";
Блокировка.Установлена = Истина;
// Применяем настройки к информационной базе
УстановитьБлокировкуСеансов(Блокировка);
// В типовых конфигурациях (БП 3.0, УТ 11) этого достаточно,
// так как встроенный механизм контроля завершит работу пользователей через несколько минут.
КонецПроцедуры
Проанализируем работу этого кода. Метод УстановитьБлокировкуСеансов() не просто запрещает вход, он выставляет флаг в параметрах информационной базы на сервере 1С. Клиентские приложения (Тонкий и Толстый клиент) периодически опрашивают сервер. Получив информацию о блокировке, они выводят предупреждение пользователю и через некоторое время (обычно 1-5 минут) закрываются автоматически.
Если вы хотите продолжать использовать Effector Saver для управления сеансами, нам необходимо отказаться от использования нестабильного COM-соединения. В современных версиях 1С для этих целей предназначен RAS — сервер администрирования.
Выясним, как это настроить:
ras.exe на сервере 1С. Обычно она запускается командой: ras cluster --port=1545 localhost:1540.Этот метод гораздо надежнее, так как взаимодействие происходит по протоколу TCP/IP, что исключает ошибки разрядности (32/64 бит) и проблемы с регистрацией DLL-библиотек в реестре Windows.
Если регламентное задание внутри 1С не подходит (например, если сеансы "зависли" в состоянии сна и не реагируют на программную блокировку), мы можем использовать внешнюю утилиту rac.exe, которая поставляется вместе с платформой 1С. Мы можем запустить её прямо из кода 1С через команду ЗапуститьПриложение.
Рассмотрим алгоритм действий:
rac session list.rac session terminate --session=[ID].Пример реализации через командную строку (скрипт .bat), который можно вызывать перед бэкапом:
"C:\Program Files\1cv8\8.3.19.1150\bin\rac.exe" session --cluster=[ID_Кластера] terminate --infobase=[ID_Базы]
Этот способ "вышибает" пользователей на уровне кластера сервера 1С, не дожидаясь ответа от клиентского приложения, что гарантирует свободный доступ к базе для создания резервной копии.
Если вы все же решили бороться с ошибкой rtrsrvc.dll в текущей схеме работы, проанализируем необходимые системные настройки. Ошибка Access violation часто возникает из-за того, что 32-битный Effector Saver не может найти нужную версию 64-битных библиотек или наоборот.
Попробуем выполнить следующие шаги:
comcntr.dll. Откройте командную строку от имени администратора и выполните:
regsvr32 "C:\Program Files\1cv8\8.3.19.1150\bin\comcntr.dll". Если используется 32-битная версия Effector Saver, повторите операцию для папки Program Files (x86).HKEY_CLASSES_ROOT\CLSID\, где хранятся данные о COM-объектах 1С. Попробуйте временно запустить службу от имени Local System или администратора домена для проверки.srvinfo (кэш сервера 1С), предварительно остановив службу 1C:Enterprise 8.3 Server Agent. Это поможет, если в реестре кластера остались "хвосты" от старых версий платформы.В процессе обсуждения проблемы многие специалисты отмечают, что использование формата .dt для регулярных бэкапов больших SQL-баз является рискованным. Мы рекомендуем использовать средства СУБД (SQL Server Management Studio) для создания .bak файлов. Это не требует выгона пользователей и работает значительно быстрее. Однако для небольших баз или файловых вариантов использование вышеописанных методов программного завершения сеансов остается актуальным и необходимым инструментом администратора.
Подведем итог: если Effector Saver перестал справляться со своей задачей после обновления платформы, оптимальным решением будет переход на использование RAS/RAC или написание небольшого внутреннего регламентного задания на языке 1С с использованием объекта БлокировкаСеансов. Это обеспечит стабильность процесса резервного копирования вне зависимости от капризов COM-соединений.