Архитектура модулей IIS и симптомы сбоя (HTTP 500)

Пользователи открывают корпоративный сайт (например, 1С WEB, OWA или внутренний портал) и видят страницу с ошибкой: «HTTP Error 500.0 - Internal Server Error. The page cannot be displayed because an internal server error has occurred». (Внутренняя ошибка сервера. Страница не может быть отображена).

Суть ошибки 500.0 (General Failure)

В отличие от >500.19 (Ошибка web.config) или >503 (Пул упал), код 500.0 — это классический отказ на уровне приложения (Worker Process) или расширения (ISAPI/CGI). Процесс w3wp.exe жив, файл конфигурации прочитан успешно, но когда IIS попытался выполнить код (PHP, ASP.NET или сторонний DLL модуль), этот модуль вернул фатальную ошибку (Exception), упал с Access Denied (нехватка прав на чтение файла), либо завис.

Пошаговое дерево решений (Отладка и Права)

Сценарий 1: Нехватка прав NTFS (ApplicationPoolIdentity)

В современных IIS (версии 7.5+) пулы приложений работают не от имени NETWORK SERVICE, а от уникальных виртуальных учеток пула (ApplicationPoolIdentity). Если вы скопировали файлы сайта в папку, ядро IIS не сможет их прочитать для выполнения (Access Denied).

1. Откройте папку сайта (например, C:\inetpub\wwwroot\my_site).
2. Свойства -> Безопасность (Security) -> Изменить -> Добавить.
3. В поле имен введите: IIS AppPool\ИМЯ_ВАШЕГО_ПУЛА (например, IIS AppPool\DefaultAppPool). Обратите внимание: расположение (Locations) должно быть установлено на ваш локальный ПК, а не домен!
4. Дайте права Чтение и Выполнение (Read & Execute). Нажмите ОК.

Сценарий 2: Ограничения ISAPI и CGI (ISAPI Restrictions)

Если ваш сайт использует внешние обработчики (например, PHP.exe, Python или модули 1С wsisapi.dll), IIS из соображений безопасности блокирует их выполнение по умолчанию.

1. Откройте Диспетчер IIS (IIS Manager) на уровне СЕРВЕРА (верхний узел).
2. Дважды кликните иконку Ограничения ISAPI и CGI (ISAPI and CGI Restrictions).
3. Если вашего модуля (например, C:\php\php-cgi.exe) там нет — добавьте его.
4. Убедитесь, что статус модуля установлен в Разрешено (Allowed). Если стоит 'Not Allowed', сайт будет выдавать 500.0.

Сценарий 3: Сбор детальной трассировки (FREB Tracing)

Если права в норме, а 500.0 остается — программист написал код с ошибкой. Чтобы доказать это (или найти сбойный модуль IIS), включите трассировку неудачных запросов.

1. В IIS Manager выберите ваш сайт -> Справа в панели Actions нажмите Failed Request Tracing (Трассировка невыполненных запросов) -> Включить (Enable).
2. Нажмите иконку Правила трассировки (Failed Request Tracing Rules) в центре -> Добавить правило.
3. Укажите коды состояния (Status Codes) = 500.
4. Попробуйте открыть сайт в браузере (получите ошибку 500).
5. Зайдите в папку C:\inetpub\logs\FailedReqLogFiles\W3SVC... и откройте сгенерированный XML-файл (fr000001.xml) в Internet Explorer/Edge.
6. Вы увидите потрясающий графический отчет. Красным будет подсвечен точный модуль (например, `RewriteModule` или `ManagedPipelineHandler`) и точная причина сбоя (например, `2147942405` - Отказано в доступе).

Типовые ошибки администраторов

• Поиск причины 500.0 в браузере (RemoteOnly): В целях безопасности IIS не показывает детальный Stack Trace с ошибками кода (желтый экран) внешним пользователям. Чтобы увидеть реальную ошибку, зайдите на сам сервер по RDP, откройте браузер локально и перейдите на http://localhost. Вы увидите настоящую причину сбоя (например, SQL Timeout).