Крашится 1с на веб IIS, после обновления платформы

(1)
1. Сообщить версию платформы до и после, для начала
2. Откатить платформу на ту, где работало или поднять релиз еще выше.

Если вылет каждые 10-15 минут, то сначала проверьте статус использования конфигурации:



насколько помню после обновления до ЦЗО пытается достучаться как-раз с периодичностью каждые 10-15 мин.
Но что бы не гадать надо бы ТЖ настроить и там смотреть.

(1) см (4).
в сопоставлении обработчиков, в IIS путь к wsisapi.dll переопределили ?

(8) ну так сделай.
Нужно указать правильный путь в сопоставлении обработчиков к библиотеке из нового каталога bin новой платформы.

(10) ну а рестарт то iis сделали после этого ?

(8) эээ.. так у тебя тонкий крашится, или вэбка ?

Если первое, настраивай ТЖ, смотри, чего там за ошибки

Идентичная картина, но только на связке 8.3.22.1672 + ЗУП КОРП 3.1.24.25 (со всеми актуальными патчами), база файловая.
Ранее также была установлена 8.3.22.1603, возможно на ней также наблюдалась проблема, точно не могу сказать.
Смотрю, 1603 уже не доступна для скачивания.

Остальные исходные: Windows Server 2019 + IIS (со всеми установленными обновлениями по 29.10.2022)
Все клиенты работают через веб (Google Chrome), поэтому не сразу обратил внимание, а после того, как на одном ПК через тонкий клиент настроил доступ.
Но у меня несколько по-другому воспроизводилось. На ровном месте ни с того ни с всего тонкий клиент аварийно начал завершать работу, поначалу предположил, что это из-за того, что базу слишком много "лопатили" когда переносили данные из 2.5. В общем, сделал тестирование и исправление - ошибка ушла, но частично - сейчас где-то через несколько часов простоя (специально оставлял запущенным сеанс) падает, в ТЖ пусто, подключаюсь к веб-серверу по локальном IP-адресу, т.е. обрыв инета исключен.
Также предполагал, что причина может быть в таймауте простоя в настройках базы, по умолчанию 24 часа, после которых происходит завершение сеанса, но вроде бы в этом случае ошибка другая - типа нарушена связь с базой.
Также грешу на обновления ОС, я когда ставил (1603) 1672, то за последние 3 месяца заодно и обновы накатил на WS.

А так порядок обновления платформы абсолютно одинаковый как у топикстартера:
Отменяю публикацию баз, устанавливаю новую платформу, удаляю старую, перезагружаю ОС, повторно публикую базы. В IIS все настройки автоматом всегда прописываются.
Но, как видно, по ходу проблема не с веб-сервером, а с тонким клиентом, возможно что-то поломалось в 22-й платформе.
Да, кстати ещё у меня перестала работать ЭП в ЗУП в связке с КриптоПро, при доступе через веб клиент, поддержка ошибку подтвердила, сказали исправят начиная с версии 8.3.22.1690 и выше, но это уже другая история.
По текущей проблеме - удалось установить причину? В суппорт пока ещё не писал.

P.S.с сопоставлением обработчика и проверкой подлинности у меня всё ок.

(17) входит в инсталляцию платформы 1С; Найди на своем сервере (где установлена 1С) ibsrv и попробуй

Оно?
https://v8.1c.ru/news/kritichno-srochno-segodnya-obnovite-platformu-1s-predpriyatie-8.htm

Напишу здесь как удалось исправить ошибку вылета (файловый вариант базы 1С) через 15 мин. после запуска web клиента http: с таким-же сообщением "К сожалению, возникла непредвиденная ошибка или сеанс был завершен администратором". Причем в тонком клиенте эта же база 1С не вылетает. Проблема решается увеличением времени завершения спящего сеанса. Если там цифры у вас маленькие (у меня было 3 мин) то база вылетает в web клиенте.

Всех приветствую.
Может мой опыт будет кому-то полезен. Моё рабочее окружение постом выше.
Проблему наблюдал как минимум с середины 2022 года, но возможно началось и раньше, просто не придавал особого значения.

База файловая. Аварийное завершение воспроизводилось как на веб-клиенте, так и на тонком.
Временной закономерности никакой не наблюдалось. Могло вылететь через 20 минут, могло через несколько часов.
С помощью поддержки 1С (сбор логов технологического журнала + дампы веб-сервера) удалось установить, что присутствует ошибка в программной лицензии. Была изменена конфигурация оборудования виртуального сервера (Hyper-V), а именно - BIOS.
Хотя, я такого не помню, чтобы менял BIOS. Виртуалка была создана в 2019 году и с тех пор её конфигурация и не менялась.

Причём, что интересно, на файловых базах на обычных формах, в нашем случае это БП 2.0 и ЗУП 2.5 проблема "якобы с лицензией" не проявлялась, Правда, доступ к базам был организован через терминальный сервер - протокол RDP (RemoteAPP).

Ну да ладно. Допустив, что всё же такое случилось, выполнил запрос новой лицензию c использованием дополнительного PIN-кода, после чего получил обновлённый файл lic под актуальную конфигурацию. Затем стал наблюдать - падения прекратились......как-будто прекратились.....т.е. стали происходить гораздо реже.

Продолжил взаимодействие с поддержкой.....
В итоге выяснилось следующее:
В дополнительных настройках пула приложений веб-сервера, отвечающего за публикацию, есть параметр "Постоянный временной интервал" и по умолчанию его значение установлено 1740 минут. Т.е. каждые 29 часов (интервал выбран специально, чтобы было смещение по времени) происходит перезагрузка пула с целью (как я понял) предотвращения утечек памяти.
И вот как раз в этот момент, если активно подключение к базе, цитата специалиста поддержки:
"проблема появляется не из-за самого факта перезапуска процессов веб-сервера, а только в том случае если этот перезапуск влечёт за собой обновление временного файла ИБ 1С"
От себя поясню, речь идёт о файлах в папке 1Cv8Temp в каталоге с базой и, со слов поддержки, это является штатным поведением.

На этот счёт в оф. документации нет ни слова. Всё, что удалось найти, это инструкция по основным настройкам пула приложений для веб-сервера IIS, в которой для корректной работы рекомендовано установить следующие параметры (скриншот во вложении). Собственно, изначально так у меня и было настроено. Касаемо же параметров самой базы, у меня также всегда были выставлены настройки по умолчанию, скриншот также прилагаю.


По существу: после выставления данного параметра в значение "0" - падения прекратились окончательно.
Но....я не сторонник менять значения по умолчанию. Не спроста же сделали механизм перезагрузки пула по расписанию.
Пока не могу сказать как оно будет при длительной публикации без перезагрузки, будет ли бесконтрольно увеличиваться память, занимаемая этим процессом, или нет. Поэтому пока оставил как есть.
В принципе, как вариант, чтобы исключить "вылет" в рабочее время, можно (штатным механизмом через оснастку IIS) задать явное время перезагрузки пула, например, глубокой ночью, раз в несколько дней. Но пользователи всё равно могут столкнуться с аварийным завершением, потому что после окончания рабочего дня не всегда выключают компьютер и оставляют открытым веб-клиент.


Обсуждаемая проблема, если она имеет место быть, на стороне платформы.
Поэтому передал пожелание разработчикам оптимизировать механизм кеширования временных файлов, исключив таким образом это "штатное" поведение.

Добрый день. возникла такая же проблема.
имеется серверный ПК, используемый только для 1С. Несколько баз на нем (УТ и БП).
Развернут веб-сервер на IIS.
Решила обновить конфигурацию на 1 базе торговли. В конфигурация все обновилось. Начала на сервере запускать программу. Обновление останавливается и вылетает. Решилось установкой 64 версии Платформы 1с. Обновление встало.
Перепубликовала еще раз базу через конфигурацию 32 версии.
Что в итоге.
На клиентском ПК идет запуск и вход в 1с. но при попытке что-то открыть - ошибка "Неспецифицированная ошибка работы с ресурсом
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: