В процессе эксплуатации клиент-серверных версий «1С:Предприятие 8.3» технические специалисты часто сталкиваются с ситуацией, когда штатное уведомление о блокировке объекта (например, документа или элемента справочника) превращается в критическую ошибку, закрывающую сеанс пользователя. Особенно остро эта проблема проявляется при работе через RemoteApp или терминальные службы Windows. Рассмотрим подробно причины возникновения таких «вылетов» и разберем по шагам методы их устранения.
Типичная ситуация выглядит следующим образом: пользователь пытается записать или провести документ, который в этот момент уже открыт другим сотрудником. Вместо стандартного сообщения «Объект заблокирован», система выдает окно с предложением завершить работу или перезапустить программу. Проанализируем ключевые факторы среды, в которой чаще всего воспроизводится ошибка:
Важным наблюдением является разница в поведении клиента: на локальных машинах при той же ошибке может появляться окно с кнопкой «ОК», после которой работа продолжается, а в терминальной сессии происходит мгновенный крэш процесса 1cv8.exe.
Практика показывает, что наиболее эффективным и быстрым решением является полное обновление или переустановка компонентов платформы 1С на сервере терминалов. Разберем этот процесс по шагам:
C:\Program Files\1cv8\srvinfo\reg_1541\snccntx). Это поможет исключить влияние «битых» данных сеансовых данных.Выясним причину, по которой RemoteApp реагирует на блокировку вылетом. В платформе 8.3.12 существовал известный баг, связанный с попыткой системы отрисовать предупреждение о блокировке. Когда 1С пытается вызвать модальное окно поверх интерфейса RemoteApp, происходит ошибка обращения к памяти (Access Violation). Система не может корректно обработать это исключение и аварийно завершает процесс.
Для борьбы с этим явлением на уровне ОС рекомендуется настроить DEP (Data Execution Prevention). Проанализируем алгоритм настройки:
1cv8.exe) в список исключений, если выбран режим защиты всех программ.Если проблема носит массовый характер и связана именно с моментом записи, следует обратить внимание на настройки СУБД. При использовании старых версий SQL Server критически важен параметр параллелизма. Если СУБД слишком долго обрабатывает транзакцию или создает избыточные блокировки, клиент 1С может «отвалиться» по таймауту.
Проанализируем настройку MAXDOP (Max Degree of Parallelism):
-- Проверка текущего значения MAXDOP
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism';
-- Рекомендуемое значение для 1С (обычно 1 или 4)
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;
Установка значения 1 заставляет SQL Server обрабатывать запрос в одном потоке, что зачастую исключает возникновение взаимных блокировок (deadlocks) на уровне СУБД, которые платформа 1С иногда не может корректно транслировать пользователю в терминальной сессии.
Рассмотрим ситуацию, когда внезапные вылеты начались без видимых изменений конфигурации. Одной из скрытых причин может быть нестабильная работа протокола IPv6. Если сервер 1С пытается связаться с сервером SQL по IPv6, и в этот момент происходит задержка ответа о блокировке, сетевой интерфейс клиента может разорвать соединение.
Мы рекомендуем отключить IPv6 в свойствах сетевого адаптера на стороне серверов 1С и SQL. Это стабилизирует передачу пакетов и исключит «дребезг» соединения при возникновении штатных ожиданий на блокировках.
На терминальных серверах антивирусы часто сканируют временные файлы пользователей в момент их создания. Когда 1С пытается записать объект, она создает временную копию данных. Если антивирус заблокировал этот файл для проверки, 1С не может завершить транзакцию и вылетает с ошибкой доступа.
Необходимо добавить в исключения антивируса:
C:\Program Files\1cv8\).srvinfo).%AppData%\Local\1C\1cv8 и %AppData%\Roaming\1C\1cv8.*.1сl, *.1сd, *.log, *.pfl.Если вышеперечисленные методы не помогли, необходимо проанализировать ситуацию с помощью Технологического журнала (ТЖ). Создайте файл logcfg.xml в каталоге conf установленной платформы со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/config">
<log location="C:\LOGS\1C" history="24">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
Событие EXCP зафиксирует исключение в момент вылета, а PROC покажет информацию о завершении процесса. Это позволит точно определить модуль или системную библиотеку, на которой происходит сбой.