Многие технические специалисты сталкивались с неприятной ситуацией после обновления платформы 1С:Предприятие до ветки 8.3.11 (например, релиз 8.3.11.2954 или 8.3.11.3034). Суть проблемы заключается в следующем: если один документ открыт у нескольких пользователей одновременно, и один из них вносит изменения, то при попытке второго пользователя произвести любое действие система не просто выдает стандартное предупреждение о блокировке, а аварийно завершает работу с предложением "Завершить" или "Перезапустить".
В этой статье мы подробно разберем, почему штатный механизм блокировок превращается в критическую ошибку, и проанализируем все доступные методы решения этой проблемы — от простых административных манипуляций до глубокой настройки сетевых протоколов.
Для начала проанализируем ситуацию с точки зрения архитектуры платформы. В нормальных условиях, когда два пользователя пытаются изменить один и тот же объект, 1С должна сгенерировать исключение ОбъектЗаблокирован. В старых релизах (линейка 8.2 или начало 8.3) пользователь видел окно с кнопкой "ОК" и мог продолжить работу после закрытия диалога.
В релизах ветки 8.3.11 был изменен механизм взаимодействия клиентского приложения и сервера при возникновении транзакционных ожиданий. Вместо того чтобы корректно обработать конфликт доступа, платформа ошибочно интерпретирует состояние блокировки как Runtime Error (критический сбой в памяти или разрыв сессии). Ситуация усугубляется, если конфигурация работает в режиме совместимости с версией 8.2.13, так как в этом режиме используются автоматические блокировки, создающие большую нагрузку на менеджер блокировок платформы.
Как показывает практика и обсуждения специалистов, самым быстрым и надежным способом решения является использование более стабильной ветки платформы. Рассмотрим, на какие версии стоит ориентироваться:
8.3.10.2580 считается одним из самых стабильных для конфигураций, использующих старые режимы совместимости. На этой версии механизм блокировок работает корректно, выдавая пользователю информационное сообщение без вылета программы.8.3.12.1622. В ней логика обработки конфликтов доступа была пересмотрена и исправлена.Выясним причину, по которой ошибка часто проявляется именно при подключении по сети, но отсутствует на локальных машинах. Проблема может быть связана с тем, как платформа 1С обрабатывает сетевые пакеты через протокол IPv6. Часто сервер и клиент пытаются установить соединение по IPv6, но из-за особенностей маршрутизации или настроек брандмауэра транзакция прерывается в момент ожидания ответа от менеджера блокировок.
Разберем по шагам, как отключить IPv6 для стабилизации работы 1С:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\ParametersDisabledComponents типа DWORD со значением 0xFFFFFFFF.Проанализируем ситуацию, когда сессия пользователя "отваливается" при длительном простое открытого документа. Если пользователь открыл форму и ушел на обед, а в это время другой внес изменения, сетевое соединение первого пользователя может перейти в состояние полураспада. При попытке записи платформа 1С пытается восстановить контекст, но натыкается на блокировку и падает.
Чтобы этого избежать, настроим параметры поддержания активности TCP-соединений. Рассмотрим пример настройки через реестр:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"KeepAliveTime"=dword:0000ea60
"KeepAliveInterval"=dword:000003e8
"TcpMaxDataRetransmissions"=dword:00000005
Установка KeepAliveTime в значение 60 000 (в миллисекундах) заставит систему проверять активность соединения каждую минуту, что предотвратит преждевременный разрыв сессии сервером 1С или сетевым оборудованием.
Иногда причина "вылетов" кроется в накопленных ошибках внутри служебных файлов сервера 1С. Даже после перезагрузки сервера проблема может сохраняться, так как данные о блокировках кэшируются в папке snccntxt.
Выполним процедуру полной очистки:
C:\Program Files\1cv8\srvinfo).reg_1541) и внутри нее удалите содержимое папки snccntxt. Внимание: это приведет к завершению всех активных сеансов.%AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8.Если ваша база работает в кластере из нескольких серверов, проанализируем распределение ролей. Ошибка часто возникает, когда сервис блокировок работает на одном физическом сервере, а сеанс пользователя — на другом. При возникновении конфликта передача данных между серверами кластера может не уложиться в отведенный тайм-аут.
Попробуйте временно ограничить кластер одним рабочим сервером или явно назначьте роль "Сервис блокировок объектов" на конкретный сервер, чтобы исключить лишние сетевые пересылки внутри кластера.
Для этого в консоли администрирования серверов 1С:
Как ни странно, иногда окно "Завершить/Перезапустить" появляется из-за невозможности корректно отрисовать стандартный диалог 1С при возникновении ошибки, если включено аппаратное ускорение графики. Это специфический баг платформы 8.3.11.
Попробуйте запустить клиентское приложение с ключом /NoAccel. Это можно сделать в настройках списка баз (кнопка "Изменить", далее на последней вкладке в поле "Дополнительные параметры запуска" впишите данный ключ).
Подводя итог, можно сказать, что наиболее эффективным решением остается отказ от использования ветки 8.3.11 в пользу более стабильных релизов 8.3.10 или 8.3.12+. Если же обновление невозможно в кратчайшие сроки, используйте комплекс мер по настройке KeepAlive и отключению IPv6 для минимизации вероятности падения системы.