В процессе работы с внешними обработками, такими как Диадок, в клиент-серверном варианте развертывания 1С:Предприятие 8.3, специалисты часто сталкиваются с критическими сбоями. Эти ошибки обычно проявляются при попытке обновить файл обработки в справочнике «Дополнительные отчеты и обработки» или непосредственно в момент запуска фоновых заданий. В данной статье мы подробно разберем, почему возникают ошибки вида e1cib/logForm и как восстановить работоспособность системы, если стандартное тестирование и исправление или чистка локального кеша не помогают.
Проанализируем типичную ситуацию. При попытке загрузить новую версию обработки или выполнить команду, система выдает сообщение об ошибке при вызове метода контекста НачатьВыполнениеСервернойКомандыВФоне. Основная причина, указываемая платформой: «Неизвестный идентификатор формы». Параллельно в журнале или всплывающем окне может появиться более детальное техническое описание:
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: по причине: Параметр сеанса отсутствует или удален ID=...
Важно отметить, что в файловом варианте та же самая база и та же самая обработка могут работать без нареканий. Это прямо указывает на то, что корень проблемы кроется в механизмах взаимодействия клиентского приложения с сервером приложений 1С (rphost) и хранением данных сеанса на стороне сервера.
Рассмотрим внутреннее устройство платформы. Начиная с версий 8.3.18, 1С существенно переработала механизм хранения контекста сеансов. Все данные, которые должны сохраняться между вызовами сервера (включая состояние форм и параметры фоновых заданий), записываются в специальные файлы в каталоге snccntx (Session Context Storage), расположенном в профиле службы сервера 1С.
Проблема возникает, когда сервер 1С «теряет» связь между активным сеансом пользователя в оперативной памяти и его физическим представлением на диске в виде .val файлов. Это может произойти из-за:
rphost;snccntx;Поскольку обычная чистка кеша на стороне пользователя не затрагивает серверные данные, нам необходимо выполнить «глубокую» очистку на сервере приложений. Выполним следующие действия:
Агент сервера 1С:Предприятия 8.3 (или 1C:Enterprise 8.3 Server Agent) и выполним команду Остановить.C:\Program Files\1cv8\srvinfo\reg_1541\
snccntx (например, snccntxe283900a...). Нам необходимо полностью удалить эти папки. Именно в них могут содержаться поврежденные индексы и ссылки на несуществующие параметры сеансов.Агент сервера 1С:Предприятия 8.3.После запуска служба автоматически пересоздаст структуру каталогов snccntx. При первом входе пользователей в систему сервер сформирует чистые, корректные контексты сеансов, и ошибка e1cib/logForm должна исчезнуть.
Проанализируем ситуацию, если ошибка повторяется через некоторое время. Это может свидетельствовать о том, что сервер не может корректно записывать данные в новые папки. Проверим права пользователя, от имени которого запущена служба 1С (обычно это USR1CV8 или LocalSystem). При настройке операционной системы и прав доступа может пригодиться справочник по типовым задачам системного администрирования 1С.
Рекомендации по настройке прав:
USR1CV8 есть права «Полный доступ» на всю папку srvinfo и все вложенные объекты.1cv8, перейти на вкладку «Безопасность» -> «Дополнительно» и нажать «Заменить все записи разрешений дочернего объекта наследуемыми от этого объекта».Настройка исключений антивируса:
Антивирусные сканеры часто блокируют временные файлы 1С в момент их создания или модификации. Проанализируем настройки безопасности на сервере и добавим в исключения (White List) следующие расширения и пути:
C:\Program Files\1cv8\srvinfo\ со всеми вложенными файлами.rmngr.exe, rphost.exe, ragent.exe.*.1CD, *.1CL, *.val, *.cln.Рассмотрим, почему именно обработка Диадок так чувствительна к этой ошибке. Данное решение активно использует механизм Длительных операций. Когда вы нажимаете кнопку «Обновить» или «Выполнить», система не просто запускает код, а порождает фоновое задание на сервере.
В релизах платформы 8.3.22.1704 и 8.3.22.1750 был зафиксирован баг, при котором идентификатор формы, инициировавшей фоновое задание, терялся при передаче управления между потоками rphost. Если очистка snccntx помогает лишь временно, настоятельно рекомендуем рассмотреть возможность обновления платформы до исправленных релизов, например, ветки 8.3.22.1921 и выше, либо переход на более современные версии 8.3.23 / 8.3.24.
Если проблема сохраняется, проанализируем ситуацию с помощью Технологического журнала (ТЖ). Это позволит увидеть точный путь к файлу, который система не может найти. Пример настройки logcfg.xml для отлова таких ошибок:
<config xmlns="http://v8.1c.ru/7.4/config/log">
<log location="C:\LOGS\EXT_ERROR" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
В логах ТЖ вы сможете увидеть записи типа Каталог не обнаружен ... \shardes\2\data\1\3\00000013.val. Если вы видите такие сообщения, значит, стратегия с удалением snccntx была верной, но что-то (права или антивирус) мешает серверу корректно работать с дисковой подсистемой. Для удобной расшифровки таких событий можно использовать инструмент для анализа и разбора технологического журнала.
Мы выяснили, что ошибка обновления обработки Диадок в клиент-серверном режиме чаще всего не связана с самой обработкой или данными базы. Это технический сбой кэширования сеансовых данных на стороне сервера приложений. Совместными усилиями по очистке серверных папок snccntx, проверке прав доступа и исключению влияния антивирусов можно полностью устранить данную проблему и обеспечить стабильную работу электронного документооборота.