Вопрос: Ошибка HTTP 500 не отслеживается в «Исправленном запросе запроса IIS»


Я создал новый сайт в IIS7, добавив новое приложение под этим сайтом. При попытке использовать веб-службу ASP.NET, размещенную под этим новым приложением, я получаю ошибку внутреннего сервера HTTP 500.

Я просмотрел журналы событий, журналы IIS и попытался настроить «Сбой запроса», но, похоже, ничего не отслеживается. У меня есть настройка для проверки всего содержимого, ведомой регистрации ошибок и ошибок HTTP от 400 до 600. Но ничто никогда не регистрируется под папкой FailedReqLogFiles. Другие сайты в этой конфигурации IIS, похоже, просто отслеживают неудачные запросы.

Я вижу, что HTTP-запросы GET регистрируются в журналах IIS для этого сайта, но они явно не очень полезны, так как они просто показывают, что запрос получил 500 ошибок.

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

Есть идеи? Я дал достаточно информации о проблеме? Заранее благодарим за любую помощь или предложения, которые вы можете дать.


5
2018-06-19 13:27


Источник


Я получил немного дальше, понимаете, я не сервер, я просто разработчик. Я настраиваю файл хоста на одном из серверов, чтобы указать на свой собственный IP-адрес для внешнего URL-адреса, чтобы я мог видеть, что ошибка была выбрана. Это HTTP 500.19 «Не удается прочитать файл конфигурации из-за недостаточных разрешений». И, по внешнему виду, это проблема web.config, с которой возникают проблемы. Я проверил разрешения, и ничего не похоже на ошибку.
Теперь представляется, что, если я переведу службу из своей подпапки под приложением, в корень приложения, никаких проблем нет. И все же я не могу сказать разницу в разрешении между корневой папкой и ее вложенной папкой. Так странно. Если я найду окончательный ответ, я отправлю его здесь.


Ответы:


Вы запустили Монитор процессов чтобы узнать, есть ли у IIS соответствующие разрешения для записи журналов FRT?


1
2017-09-11 20:12





С помощью Failed Request Tracing вам необходимо настроить правило, но в качестве отдельного шага вы должны включить его. В Трассировке неудавшегося запроса установите флажок «Действие» справа, у которого будет возможность включить его. Это мое предположение, почему трассировка не работает.

Моя рекомендация по любой конфигурации в IIS7, где у вас есть 1 сайт на один пул приложений или когда все сайты доверяют друг другу и сайты стабильны, заключается в том, чтобы установить анонимную аутентификацию для использования идентификатора пула приложений. Это дает вам меньше пользователей. Затем убедитесь, что идентификатор пула приложений предоставлен на диске.

Вы отмечаете, что он не работает во вложенной папке. Возможно иметь разные разрешения или другой пул приложений, используемый для под-приложения. Двойная проверка используемого пула приложений и анонимные настройки авторизации.

Наконец, используйте Process Monitor, как предложил Колин. Получите его от www.sysinternals.com. Он бесплатный, безопасный для работы на производственном сервере, и вы выясните его менее чем за 10 минут. Это точно скажет, кому запрещен доступ к какой папке (или к ключу реестра).


1
2017-09-14 10:18





Проверьте свой web.config, у вас есть impersonate = true?

В этом случае с анонимным доступом в IIS это будет анонимный пользователь IIS, который пытается прочитать web.config не пользователь пула приложений.


0
2017-07-21 18:35





Ваш файл web.config должен находиться в корне вашей папки веб-приложений. В противном случае вы получите всевозможные ошибки.


0
2018-02-03 03:57





Помимо всего предложения, вы также можете попробовать Chrome Dev Tool [Нажмите F12], чтобы узнать, есть ли у вас какие-либо подсказки. Аналогично, вы можете попробовать это в IE [Нажмите F12], если у вас не может быть хром.

https://developer.chrome.com/devtools для более подробной информации. Для вашего случая посмотрите в сети и области консоли


0
2018-03-17 04:46