Почему 1С 8.3 завершает работу при блокировке документа и как это исправить

В процессе эксплуатации серверных версий 1С:Предприятие системные администраторы и разработчики иногда сталкиваются с аномальным поведением системы: вместо стандартного уведомления о том, что объект редактируется другим пользователем, программа аварийно завершает сеанс. Особенно часто эта проблема проявлялась на платформе ветки 8.3.13. В данной статье мы подробно разберем причины возникновения этой «пессимистичной» блокировки и шаги, которые помогут вернуть систему в стабильное состояние.

Анализ проблемы: почему происходит вылет?

Рассмотрим ситуацию: серверная база работает на платформе 8.3.13.1926, используется MS SQL Server 2016, а в качестве операционной системы выступает Windows 10, настроенная для многопользовательской работы через RDP. При попытке двух пользователей открыть один и тот же документ система генерирует критическую ошибку. Вместо привычного диалогового окна «Объект заблокирован» происходит закрытие приложения 1cv8.exe.

Проанализируем основные факторы, провоцирующие такое поведение:

1. Ошибки релиза 8.3.13: Данная ветка платформы имела ряд недоработок в механизме Managed Lock Manager (менеджер управляемых блокировок). При возникновении конфликта блокировок рабочий процесс rphost мог некорректно обрабатывать исключение, что приводило к падению всего потока.
2. Специфика Windows 10 как сервера: Использование клиентской ОС в качестве сервера накладывает ограничения на количество сокетов и работу с памятью (Desktop Heap). При высокой нагрузке лимиты исчерпываются, и сетевое взаимодействие между компонентами 1С и SQL разрывается в момент ожидания блокировки.
3. Динамические обновления: Так называемые «демонические» обновления часто приводят к рассинхронизации кэша конфигурации. Если база обновлялась динамически, таблицы конфигурации в СУБД могут содержать противоречивые данные, что вызывает крах при попытке заблокировать объект.

Решение №1: Смена версии платформы 1С

Как показывает практика, наиболее эффективным решением является отказ от проблемного релиза. Разберем, на какую версию лучше перейти. Платформа 8.3.13.1926 оказалась нестабильной во многих аспектах, поэтому рассмотрим два пути:

Вариант А: Откат на проверенную версию. Переход на ветку 8.3.12 (например, последние релизы этой ветки) часто решает проблему мгновенно, так как механизмы управления сеансами там работают по классической схеме без экспериментальных изменений 13-й ветки.

Вариант Б: Обновление до актуальных релизов. Рекомендуется переход на 8.3.14 или 8.3.15. В этих версиях ошибки менеджера блокировок были исправлены, а алгоритмы обработки таймаутов пересмотрены. Стоит избегать промежуточных нестабильных сборок и выбирать релизы с пометкой «финальный».

Решение №2: Комплексная очистка кэша

Простая переустановка платформы может не помочь, если в системе остались «битые» файлы кэша. Рассмотрим процедуру полной очистки по шагам:

Шаг 1. Очистка кэша пользователей на RDP-сервере.
Необходимо удалить содержимое папок, где 1С хранит временные данные для каждой информационной базы. Эти папки находятся по путям:

• %AppData%\1C\1cv8\
• %LocalAppData%\1C\1cv8\

Важно помнить, что при работе в терминальном режиме (RDP) эти действия нужно выполнить для профиля каждого пользователя.

Шаг 2. Очистка серверного кэша.
Для серверных баз критически важно очистить данные кластера. Остановите службу 1C:Enterprise 8.3 Server Agent. Перейдите в каталог реестра кластера (по умолчанию это C:\Program Files\1cv8\srvinfo). Найдите там папку snccntx — именно здесь хранятся данные менеджера управляемых блокировок. Удалите содержимое этой папки. Также стоит очистить папку reg_1541 (или другой порт вашего кластера), за исключением файла 1cv8wsrv.lst, который содержит список баз.

Решение №3: Переподключение базы в консоли администрирования

Иногда требуется «перезагрузить» связь между сервером 1С и SQL. Разберем, как правильно перерегистрировать базу:

1. Откройте «Администрирование серверов 1С Предприятия».
2. Найдите вашу информационную базу.
3. Удалите её из списка (выберите вариант «Оставить без изменений», чтобы сама база на SQL-сервере не была удалена).
4. Создайте новую запись информационной базы в консоли, указав те же параметры подключения к SQL-серверу.

Этот процесс гарантированно очищает серверные идентификаторы сеансов и позволяет платформе начать работу «с чистого листа».

Рекомендации по настройке MS SQL Server 2016

Чтобы минимизировать вероятность конфликтов блокировок на уровне СУБД, проанализируем настройки вашего SQL-сервера. Для 1С рекомендуется использовать режим READ_COMMITTED_SNAPSHOT. Выясним, включен ли он, и при необходимости активируем его. Это позволит пользователям, читающим данные, не блокироваться пишущими пользователями.

Пример скрипта для проверки и включения режима:

-- Проверка текущего режима
SELECT name, is_read_committed_snapshot_on FROM sys.databases WHERE name = 'Имя_Вашей_Базы';

-- Включение режима (требуется монопольный доступ)
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;

Также проверьте параметр Compatibility Level (Уровень совместимости). Для SQL 2016 он должен соответствовать значению 130. Если база была перенесена со старого сервера, уровень совместимости мог остаться низким, что мешает оптимизатору запросов работать корректно.

Проблема динамических обновлений

Если вы часто применяете изменения в конфигураторе через «Обновить конфигурацию базы данных» при активных пользователях, это неизбежно ведет к накоплению ошибок в таблице Config. Рассмотрим, как исправить последствия таких обновлений. Если база начала «вылетать», рекомендуется выполнить процедуру полного (не динамического) обновления:

1. Попросите всех пользователей выйти из системы.
2. В конфигураторе внесите незначительное изменение (например, добавьте пробел в комментарий любого общего модуля).
3. Выполните сохранение и обновление конфигурации базы данных (клавиша F7).
4. Запустите «Типизацию и тестирование» с выбранным пунктом «Реиндексация таблиц» и «Сжатие таблиц».

Подведем итог: Аварийное завершение работы при блокировке в версии 8.3.13.1926 — это результат совокупности багов платформы и нестабильности окружения. Наилучшим выходом является переход на платформу 8.3.14 или возврат к 8.3.12 в сочетании с полной очисткой кэша srvinfo и пользовательских настроек.