Я создал новый сайт в IIS7, добавил новое приложение под этим сайтом. При попытке затем использовать веб-службу ASP.NET, расположенную под этим новым приложением, я получаю внутреннюю ошибку сервера HTTP 500.
Я просмотрел журналы событий, журналы IIS и попытался настроить «отслеживание неудачных запросов», но, похоже, ничего не отслеживается. У меня есть настройки для проверки всего содержимого, подробного журнала ошибок и ошибок HTTP в диапазоне от 400 до 600. Но в папке FailedReqLogFiles ничего не регистрируется. Другие сайты в этой конфигурации IIS, похоже, отлично отслеживают неудачные запросы.
Я вижу, что HTTP-запросы GET регистрируются в журналах IIS для этого сайта, но они, очевидно, не очень полезны, поскольку они просто показывают, что запрос возвращается с ошибкой 500.
Я проверил разрешения для папок сайта в проводнике и убедился, что анонимный доступ включен и удостоверение пула приложений также имеет доступ к содержимому папки.
Любые идеи? Достаточно ли я сообщил о проблеме? Заранее благодарим за любую помощь или предложения, которые вы можете дать.
При отслеживании неудачных запросов вам необходимо настроить правило, но в качестве отдельного шага вы должны включить его. В отслеживании невыполненных запросов проверьте панель действий справа, в которой будет возможность включить ее. Я предполагаю, почему трассировка не работает.
Моя рекомендация для любой конфигурации в IIS7, где у вас есть 1 сайт на пул приложений или когда все сайты доверяют друг другу и сайты стабильны, - установить анонимную аутентификацию для использования удостоверения пула приложений. Это дает вам на одного пользователя меньше. Затем убедитесь, что удостоверению пула приложений предоставлено разрешение на диск.
Вы упомянули, что это не работает в подпапке. Для субприложения могут использоваться разные разрешения или другой пул приложений. Дважды проверьте используемый пул приложений и настройки анонимной аутентификации.
Наконец, используйте Process Monitor, как предложил Колин. Получите его на сайте www.sysinternals.com. Это бесплатно, безопасно для работы на рабочем сервере, и вы разберетесь в этом менее чем за 10 минут. Это скажет вам, какой именно пользователь не имеет доступа к какой папке (или разделу реестра).
Ты бежишь Монитор процесса чтобы узнать, есть ли у IIS соответствующие разрешения для записи журналов FRT?
Ваш web.config должен находиться в корне папки вашего веб-приложения. В противном случае вы получите всевозможные ошибки.
Проверьте свой web.config, есть ли у вас impersonate = true?
В этом случае с анонимным доступом в IIS это будет анонимный пользователь IIS, который попытается прочитать web.config, а не пользователь пула приложений.
Помимо всех предложений, вы также можете попробовать Chrome Dev Tool [нажмите F12], чтобы узнать, есть ли у вас подсказки. Точно так же вы можете попробовать это в IE [нажмите F12], если у вас нет хрома.
https://developer.chrome.com/devtools для получения дополнительной информации, для вашего случая посмотрите в области сети и консоли