Почему базы 1С на веб-сервере IIS периодически падают с ошибкой 500 и как это исправить?

При эксплуатации информационных баз 1С:Предприятие, опубликованных на веб-сервере Microsoft IIS, системные администраторы нередко сталкиваются с ситуацией, когда после некоторого времени стабильной работы веб-клиенты и веб-сервисы перестают отвечать, возвращая ошибку HTTP Error 500 (Internal Server Error). При этом перезапуск пула приложений или самого IIS временно восстанавливает работоспособность. Разберем по шагам, где искать диагностические данные и как устранить первопричины такого поведения.

Шаг 1. Диагностика и сбор системных журналов

Ошибка 500 является обобщенным ответом веб-сервера, означающим внутренний сбой при обработке запроса. Чтобы точно понять, на чьей стороне произошла ошибка — в самом IIS, модуле расширения веб-сервисов wsisapi.dll или на уровне сервера 1С:Предприятие, выполним комплексную диагностику.

1. Анализ журнала событий Windows (Event Viewer). Откроем eventvwr.msc и проанализируем две ветки:

   В журнале Application найдем события с источниками Application Error и IIS-W3SVC-WP. Они фиксируют аварийные падения рабочего процесса w3wp.exe с указанием сбойного модуля (например, wsisapi.dll, ntdll.dll или компонентов Visual C++ Runtime).

   В журнале System проверим записи службы WAS (Windows Process Activation Service). Если пул приложений падал неоднократно, там будут зафиксированы события автоматической остановки пула из-за срабатывания механизма защиты от сбоев.

2. Включение подробных кодов ошибок в IIS. Перейдем в консоль диспетчера служб IIS, выберем нужный сайт или приложение и перейдем в раздел Страницы ошибок (Error Pages). В действиях выберем Изменить параметры функций и переключим режим на Подробные ошибки (Detailed Errors). Это позволит увидеть точный подкод ошибки (например, 500.0, 500.19, 500.21), что существенно сузит круг поиска проблемы.
3. Настройка трассировки сбоев (Failed Request Tracing / FREB). В диспетчере IIS включим трассировку неудачных запросов для кода состояния 500. Это сформирует подробный XML-отчет по каждому упавшему запросу, где пошагово видно, на каком именно этапе конвейера IIS (аутентификация, сопоставление обработчика или выполнение ISAPI-расширения) произошел сбой.
4. Сбор технологического журнала 1С. Создадим или отредактируем файл logcfg.xml, настроив сбор событий исключительных ситуаций и веб-сервисов с фильтрацией по рабочему процессу веб-сервера:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <dump location="C:\dumps" create="1" type="2"/>
    <log location="C:\LOGS\IIS_1C" history="72">
        <event>
            <eq property="name" value="EXCP"/>
            <eq property="p:processName" value="w3wp"/>
        </event>
        <event>
            <eq property="name" value="WEBS"/>
            <eq property="p:processName" value="w3wp"/>
        </event>
        <property name="all"/>
    </log>
</config>

Шаг 2. Разделение баз по отдельным пулам приложений

Частая ошибка архитектуры — публикация нескольких информационных баз внутри одного пула приложений IIS. Если несколько баз 1С работают в рамках одного рабочего процесса w3wp.exe, критическая ошибка, зависание сессии или утечка памяти в одной базе приводит к аварийному завершению всего процесса. В результате перестают отвечать все остальные базы этого пула.

Для решения проблемы изолируем базы:

1. В диспетчере IIS создадим отдельный пул приложений для каждой опубликованной информационной базы 1С.
2. В свойствах каждого приложения 1С назначим его индивидуальный пул.
3. Это локализует возможные проблемы: сбой в одной базе больше не затронет соседние системы.

Шаг 3. Проверка разрядности пула и модуля веб-расширения

Проанализируем соответствие разрядности установленной платформы 1С и настроек IIS:

1. Если используется 64-разрядный модуль расширения веб-сервера 1С (устанавливается вместе с 64-битной платформой или сервером 1С), в дополнительных параметрах соответствующего пула приложений IIS параметр Разрешены 32-разрядные приложения (Enable 32-Bit Applications) должен иметь значение False.
2. Если используется 32-разрядный модуль расширения, параметр Разрешены 32-разрядные приложения обязан быть включен в значение True. Однако 32-битный рабочий процесс ограничен адресным пространством в 2-3 ГБ, что при интенсивных запросах или формировании тяжелых отчетов через веб быстро приводит к ошибке переполнения памяти и падению процесса. Для продуктивных систем рекомендуется использовать 64-битную платформу и модуль расширения.

Шаг 4. Настройка автоматической переработки пулов (Recycling)

Поскольку при непрерывной обработке сложных веб-запросов и HTTP-сервисов в процессе w3wp.exe могут постепенно накапливаться дескрипторы и неосвобожденная память, настроим регулярную утилизацию процесса:

1. В диспетчере IIS откроем параметры пула приложений и выберем Переработка... (Recycling).
2. Отключим стандартный интервал Регулярный интервал времени (1740 минут) и зададим Фиксированное время (Specific time), например, в 03:00 ночи, когда нагрузка на базу минимальна.
3. При необходимости ограничим Максимальный объем частной памяти (Private Memory Limit), чтобы предотвратить чрезмерное разрастание процесса при утечках.
4. Проверим параметры Защиты от частых сбоев (Rapid-Fail Protection). По умолчанию пул отключается, если за 5 минут произошло 5 сбоев. Если пул переходит в остановленное состояние, причину следует искать в аварийных завершениях wsisapi.dll по системным журналам.

Шаг 5. Настройка прав доступа к служебным каталогам

Ошибка 500 может возникать из-за отказа в доступе учетной записи пула приложений к файловой системе при попытке платформы создать временные файлы или прочитать параметры публикации. Выясним права учетной записи (по умолчанию это IIS_IUSRS или applicationPoolIdentity):

1. Предоставим права на чтение и выполнение в каталог физической публикации базы, где расположен файл default.vrd.
2. Предоставим полные права на чтение, запись и изменение в системный временный каталог C:\Windows\Temp.
3. Предоставим права на чтение и запись в каталог общих настроек и кэша платформы C:\ProgramData\1C\1cv8.

Шаг 6. Оптимизация параметров подключения в default.vrd

Если веб-сервер используется для высоконагруженных интеграций через HTTP-сервисы или Web-сервисы, нехватка соединений в пуле приводит к таймаутам и падениям с кодом 500. Проанализируем файл default.vrd в каталоге публикации базы. Для оптимизации работы пула соединений зададим явные параметры пула в корневом элементе point:

<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/base_name"
       ib="Srvr="app-server";Ref="base_name";"
       enableStandardOData="true">
    <ws enable="true" pointEnableCommon="true"/>
    <httpServices publishByDefault="true"/>
    <pool size="10"
          timeout="60"
          reuse="true"/>
</point>

Параметр size определяет максимальное количество удерживаемых сессий к серверу 1С, а timeout — время в секундах, в течение которого неактивное соединение сохраняется в пуле. Это снижает накладные расходы на постоянную авторизацию и предотвращает лавинообразные ошибки при наплыве входящих запросов.