Столкнулись с этой ошибкой у одного клиента. Казалось бы — откуда ей взяться? Ведь серьезных изменений на сервере никаких не было.
Единственный момент, на который указали бухгалтеры — сбои начались приблизительно с ноября 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С. С тем самым сообщением о непредвиденной ошибке. Если кратко.
~~~
В версиях платформы «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
mdsched3. В Диспетчере служб IIS в свойствах пула приложений, который связан с опубликованными базами, поставьте «Режим управляемого контейнера» = «Классический».
В некоторых системах рекомендуется поставить «Версия среды CLR.NET» в версию 2.0. Либо наоборот — «Без управляемого кода».
4. При проблемах, связанных с правами на каталоги или файлы — протестируйте в настройках пула приложений параметр «Удостоверение». Измените удостоверение пула приложений (ApplicationPoolIdentity) на учетную запись конкретного пользователя.
__________
Не получается? Зовите на помощь ИТ-специалиста или обратитесь с нашим джедаям техподдержки → +7-911-500-10-11
