Как устранить падение процесса w3wp.exe (модуль ext.dll) и ошибку «Сеанс отсутствует или удален» в 1С на веб-сервере IIS 10.0?

При работе пользователей с файловыми базами 1С:Предприятия, опубликованными на веб-сервере Internet Information Services (IIS) 10.0, системные администраторы часто сталкиваются с внезапным прерыванием работы. В клиентском приложении это выглядит как мгновенное появление предупреждения «Сеанс отсутствует или удален», после чего работа аварийно завершается. При этом в журнале событий Windows (Application Error) регистрируется падение рабочего процесса IIS с кодом события 1000, где виновником сбоя выступает библиотека расширения веб-сервера 1С — ext.dll (код исключения 0xc0000005, указывающий на нарушение прав доступа к памяти — Access Violation).

В этой статье мы подробно проанализируем физические и программные причины этой проблемы, а также рассмотрим комплекс мер по ее полному устранению без необходимости переустановки операционной системы.

Почему происходит падение процесса w3wp.exe?

Код исключения 0xc0000005 означает, что процесс попытался обратиться к защищенному или несуществующему участку оперативной памяти. В контексте связки IIS и 1С:Предприятия к этому приводят три основные системные причины:

1. Конфликт прав виртуального пользователя пула приложений IIS: По умолчанию пулы приложений работают под учетной записью ApplicationPoolIdentity. Это встроенная низкопривилегированная учетная запись Windows, которая не имеет полноценного профиля пользователя. Когда 1С пытается обратиться к системным или временным каталогам для генерации отчетов или записи кэша, она натыкается на блокировку операционной системы, что вызывает моментальный краш библиотеки ext.dll.
2. Проблемы подсистемы печати и рендеринга: Ошибка чаще всего проявляется при формировании «тяжелых» печатных форм (например, Акта сверки взаимных расчетов, ОСВ, сложных реестров). Для отрисовки табличного документа 1С использует Windows GDI и обращается к драйверу принтера по умолчанию. Если служба печати (Spooler) недоступна для процесса IIS или у пула нет доступа к драйверу принтера, происходит критический сбой.
3. Ограничения адресного пространства 32-разрядных процессов: Если веб-сервер настроен в режиме поддержки 32-битных приложений, процесс w3wp.exe ограничен лимитом адресного пространства (около 2-3 Гб). При интенсивной работе нескольких пользователей или формировании объемных отчетов память быстро переполняется, вызывая аварийное завершение процесса.

Давайте разберем по шагам, как решить эту проблему раз и навсегда.

Решение 1. Смена удостоверения пула приложений (Identity)

Это наиболее эффективное и проверенное решение, которое устраняет корневую причину конфликта прав доступа к системным ресурсам Windows. Нам необходимо перевести работу пула приложений с виртуальной учетной записи на специально созданного локального пользователя с достаточными привилегиями.

Выполним настройку по шагам:

1. Создадим в операционной системе нового локального пользователя (например, с именем 1C_IIS_User) и зададим ему надежный, неистекающий пароль.
2. Включим этого пользователя в локальную группу Пользователи журналов производительности (Performance Monitor Users) и предоставим ему полные права на папку с файловой базой данных 1С и папку публикации.
3. Откроем Диспетчер служб IIS (inetmgr).
4. В левом дереве выберем пункт Пулы приложений (Application Pools).
5. Найдем пул, который обслуживает нашу опубликованную базу (по умолчанию это DefaultAppPool, но настоятельно рекомендуется создать для базы персональный пул). Нажмем на него правой кнопкой мыши и выберем Дополнительные параметры (Advanced Settings).
6. В разделе «Модель процесса» найдем пункт Удостоверение (Identity) и нажмем кнопку с троеточием.
7. В появившемся окне выберем вариант Особая учетная запись (Custom account) и нажмем кнопку Установить (Set).
8. Введем имя созданного пользователя в формате .\1C_IIS_User и его пароль. Подтвердим изменения.

Решение 2. Активация загрузки профиля пользователя и настройка Temp-каталогов

Если пул приложений IIS работает без загрузки полноценного пользовательского профиля, у него отсутствуют валидные пути к временным папкам (AppData\Local\Temp). Это гарантированно приводит к падению ext.dll при кэшировании данных 1С.

Выполним следующие действия:

1. В Дополнительных параметрах нашего пула приложений найдем параметр Загрузка профиля пользователя (Load User Profile) и принудительно переведем его в значение True.
2. Предоставим полные права доступа группе IIS_IUSRS и нашему пользователю 1C_IIS_User на системные временные каталоги. Для этого выполним в командной строке (запущенной от имени администратора) следующие команды:

icacls "C:\Windows\System32\config\systemprofile\AppData\Local\Temp" /grant "IIS_IUSRS":(OI)(CI)F /T
icacls "C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Temp" /grant "IIS_IUSRS":(OI)(CI)F /T

После этого перезапустим службу IIS с помощью команды iisreset в командной строке.

Решение 3. Выделение публикации в индивидуальный пул приложений

Если на сервере опубликовано несколько баз 1С, совместное использование одного пула (например, DefaultAppPool) часто приводит к взаимным блокировкам и крашам. Сбой в одной базе будет приводить к падению сеансов во всех остальных базах.

Рассмотрим, как изолировать базы:

1. В Диспетчере IIS перейдем в Пулы приложений и в правой панели выберем Добавить пул приложений.
2. Зададим имя нового пула (например, 1C_Pool_Buh), укажем версию среды .NET как Без управляемого кода (No Managed Code) и выберем режим управления Классический или Интегрированный (рекомендуется Классический для стабильности старых платформ).
3. Перейдем в раздел Подключения -> Сайты -> Default Web Site и найдем наше виртуальное приложение (опубликованную базу).
4. Нажмем на него правой кнопкой мыши, выберем Управление приложением -> Дополнительные параметры.
5. В поле Пул приложений выберем только что созданный нами пул 1C_Pool_Buh.

Решение 4. Перевод IIS на 64-битную платформу 1С:Предприятия

Использование 32-битных рабочих процессов часто является скрытым источником утечек памяти и падений при формировании тяжелых отчетов. Для стабильной работы веб-сервера необходимо использовать 64-разрядные компоненты.

Выполним проверку и настройку:

1. В настройках нашего пула приложений в IIS откроем Дополнительные параметры и убедимся, что параметр Разрешить 32-разрядные приложения (Enable 32-Bit Applications) установлен в значение False.
2. Откроем файл конфигурации публикации default.vrd (он находится в папке, куда была выполнена публикация базы) и проверим, что физический путь указывает на 64-битную версию библиотеки wsisapi.dll, расположенную в каталоге C:\Program Files\1cv8\... (а не в Program Files (x86)).
3. В Диспетчере IIS перейдем в раздел Сопоставление обработчиков (Handler Mappings) для нашей публикации и проверим сопоставление для расширения *.1cws. Оно должно использовать 64-битную dll-библиотеку.

Решение 5. Устранение проблем со службой печати

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

1. Установим на сервере виртуальный локальный принтер (например, Microsoft Print to PDF или Microsoft XPS Document Writer) и назначим его принтером по умолчанию для всей системы.
2. Если на сервере настроены старые сетевые принтеры, которые в данный момент недоступны, полностью удалим их из системы.
3. Убедимся, что у нашего пользователя пула приложений 1C_IIS_User есть доступ к локальной очереди печати.

Почему восстановление системных файлов помогло на виртуальной машине, но не решило проблему на физическом сервере?

В ходе диагностики вы могли заметить интересную аномалию: после переноса ОС на виртуальную машину выполнение команд sfc /scannow и dism решило проблему, а на "боевом" сервере — нет. Это связано с разницей в аппаратном окружении.

При переносе на виртуальную машину ОС избавляется от привязки к физическим драйверам чипсета, видеокарты и, самое главное, сетевых адаптеров и принтеров. Утилита sfc восстановила стандартные системные библиотеки, которые на виртуалке бесконфликтно заработали со стандартными виртуальными драйверами Microsoft. На физическом же сервере продолжали функционировать проприетарные драйверы оборудования, которые интегрируются в стек сетевых протоколов и графическую подсистему Windows, блокируя корректную работу пула приложений IIS с системными API-функциями. Применение описанных выше решений (смена прав и изоляция пулов) полностью нивелирует эти аппаратные различия.

Резюме по обеспечению стабильности файловых баз под IIS

Для предотвращения падения рабочего процесса веб-сервера w3wp.exe придерживайтесь следующих правил администрирования:

• Никогда не используйте стандартный DefaultAppPool под учетной записью ApplicationPoolIdentity для работы с базами 1С.
• Всегда создавайте изолированный пул приложений для каждой базы данных.
• Запускайте пул от имени выделенного локального пользователя с правами на каталоги базы и временные папки.
• Включайте параметр Load User Profile = True в настройках пула.
• При первой возможности рассмотрите миграцию файловой базы в клиент-серверный вариант (на СУБД PostgreSQL или MS SQL Server), либо используйте веб-сервер Apache 2.4, который демонстрирует более высокую отказоустойчивость при работе с файловыми базами 1С в Windows-окружении.