К сожалению возникла непредвиденная ошибка 1с после обновления

Столкнулись с этой ошибкой у одного клиента. Казалось бы — откуда ей взяться? Ведь серьезных изменений на сервере никаких не было.

Единственный момент, на который указали бухгалтеры — сбои начались приблизительно с ноября 2022 года. Как раз после предупреждений 1С по обязательному переходу на новые релизы технологической платформы.

Справочно:
«14.11.2022 Фирма «1С» сообщила о необходимости срочного обновления платформы. Обнаружена критическая ошибка, которая может привести к проблеме с запуском программы».

Опишем путь, через который прошли сами. Возможно, он поможет вам в поиске решений для подобного рода случаев.

Условия пользовательской среды

Тип ИБ: файловая база, опубликованная на веб-сервере.
Лицензирование: программные клиентские лицензии на сервере.
Режим доступа: тонкий клиент 1С, локальная офисная сеть.
Версия платформы: 8.3.20.2180 x64.

Программное обеспечение сервера:

• ОС Microsoft Windows Server 2012 R2 (Версия 6.2, сборка 9200);
• Веб-сервер IIS версия 8.5.9600.16384 x64.

Важно отметить, ошибка возникала только при работе с 1С на клиентских ПК; при запуске 1С в терминальном режиме на сервере — ничего подобного, без «вылетов», все работало безупречно.

Суть в следующем: в ряде платформ обнаружена критическая ошибка, которая может приводить к закрытию приложения 1С. С тем самым сообщением о непредвиденной ошибке. Если кратко.

~~~
В версиях платформы «1С» 8.3.22.1672, 8.3.22.1603, 8.3.21.1607, 8.3.21.1508, 8.3.21.1484, 8.3.20.2076, 8.3.20.2039, 8.3.19.1665, 8.3.19.1659, 8.3.18.1902, 8.3.18.1894, 8.3.17.2733, 8.3.17.2665 обнаружена критическая проблема, которая может привести к закрытию приложения в начале работы с программой.

Возможный вариант ошибки: «К сожалению возникла непредвиденная ошибка или сеанс был завершен администратором».
~~~

Выход или предлагаемое решение: в связи с этим необходимо провести обновление платформы на всех рабочих местах.

«Проблемная версия» → «Обновить на »:

• 8.3.17.2665, 8.3.17.2733, 8.3.17.2757 → 8.3.17.2760 или выше;
• 8.3.18.1894, 8.3.18.1902, 8.3.18.1957 → 8.3.18.1959 или выше;
• 8.3.19.1659, 8.3.19.1665, 8.3.19.1723 → 8.3.19.1726 или выше;
• 8.3.20.2039, 8.3.20.2076, 8.3.20.2180 → 8.3.20.2184 или выше;
• 8.3.21.1484, 8.3.21.1508, 8.3.21.1607, 8.3.21.1622 → 8.3.21.1624 или выше;
• 8.3.22.1603, 8.3.22.1672, 8.3.22.1704 → 8.3.22.1709 или выше.

Мы, конечно же, обновились. Помогло? Нет. Перепробовали актуальные релизы из разных веток. Прыгали до 8.3.22.1750, откатывались на 8.3.18.1959 по рекомендациям техподдержки 1С. Ни-че-го. Ошибка досаждала нам и дальше.

Решение #2 — проведите исследование ошибки по логам

Здесь вы можете проверить события в журнале регистрации 1С (ЖР) и системных журналах ОС. Даже подключить технологический журнал (ТЖ). Чтобы посмотреть, что происходит в момент возникновения ошибки.

Что показало наше расследование:

• в ЖР событий с типом «ошибка» ближе ко времени вылета 1С нет; присутствуют, в основном, события «Регламентное задание. Отправка серверных оповещений клиентам»;
• в ТЖ фиксируется «Ошибка работы сеанса. Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call: Сеанс отсутствует или удален»;
• вылет программы сопровождается также перезапуском запущенных ИБ у других пользователей, которые в это время работают с веб-сервером;
• в журнале «Приложение» Windows-сервера фиксируется ошибка w3wp.exe (Application Error).

Общая причина одна: происходит падение рабочего процесса IIS.

Рекомендация: подключайте своих ИТ-специалистов для решения задачи или регистрируйте обращение в техническую поддержку 1С.

Решение #3 (частное) — проверка настроек веб-сервера IIS

Перекрутили множество настроек — режим конвейера, версия среды CLR.NET, сопоставления обработчиков —

практически все без результата.

Кроме одного решения: выделить каждой публикации отдельный пул. До этого IIS работает по умолчанию под одним DefaultAppPool.

Пулы веб-сервера работают при следующих параметрах
Версия среды CLR.NET: Среда CLR.NET версии v2.0.50727
Режим управляемого конвейера: Классический

Дополнительные плюсы по запуску множества пулов:

• если будет ошибка в одной базе, то пользователей в других ИБ не затронет;
• для обновления ИБ на сервере можно точечно останавливать процесс, чтобы получить монопольный доступ;
• в процессах сервера по наименованию пулов видно, в какие базы выполнен вход через веб-публикацию (например, по сути «имя пользователя = имя базы»).

Решение: выполнить настройку отдельных пулов для каждой базы (публикации).

Дополнительные общие рекомендации

1. Поставьте режим «Автоматически выбирать объем файла подкачки» в параметрах виртуальной памяти.

2. Выполните общие проверки дисков, целостности системных файлов, хранилища компонентов и диагностику ОЗУ.

chkdsk c:
sfc /scannow
dism /online /cleanup-image /checkhealth
dism /online /cleanup-image /scanhealth
mdsched

4. При проблемах, связанных с правами на каталоги или файлы — протестируйте в настройках пула приложений параметр «Удостоверение». Измените удостоверение пула приложений (ApplicationPoolIdentity) на учетную запись конкретного пользователя.

__________
Не получается? Зовите на помощь ИТ-специалиста или обратитесь с нашим джедаям техподдержки → +7-911-500-10-11