我在 IIS7 中创建了一个新网站，并在该网站下添加了一个新应用程序。当我尝试使用位于此新应用程序下的 ASP.NET Web 服务时，我收到 HTTP 500 内部服务器错误。
我查看了事件日志、IIS 日志，并尝试设置“失败请求跟踪”，但似乎什么都没被跟踪到。我已将其设置为检查所有内容、详细错误日志记录和 400-600 范围内的 HTTP 错误。但 FailedReqLogFiles 文件夹下从未记录任何内容。此 IIS 配置中的其他站点似乎可以很好地跟踪失败的请求。
我可以看到该站点的 IIS 日志中记录了 HTTP GET 请求，但它们显然没有什么帮助，因为它们只是显示请求返回了 500 错误。
我已经检查了资源管理器中站点文件夹的权限，并确保已打开匿名访问，并且应用程序池标识也可以访问该文件夹的内容。
有什么想法吗？我是否提供了足够的问题信息？提前感谢您提供的任何帮助或建议。
答案1
使用失败请求跟踪时，您需要设置规则，但必须将其作为单独的步骤打开。在失败请求跟踪中，检查右侧的操作窗格，其中有一个选项可以启用它。这就是我猜测跟踪不起作用的原因。
对于 IIS7 中的任何配置，如果每个应用程序池有 1 个站点，或者所有站点相互信任且站点稳定，我的建议是将匿名身份验证设置为使用应用程序池的身份。这样可以少处理一个用户。然后确保应用程序池身份被授予磁盘权限。
您提到它在子文件夹中不起作用。子应用程序可能具有不同的权限或使用不同的应用程序池。仔细检查正在使用的应用程序池和匿名身份验证设置。
最后，按照 Colin 的建议使用 Process Monitor。可从 www.sysinternals.com 下载。它是免费的，在生产服务器上运行安全，而且 10 分钟内您就能搞清楚。它会准确地告诉您哪个用户被拒绝访问哪个文件夹（或注册表项）。
答案2
你跑过吗进程监控查看 IIS 是否有适当的权限来写入 FRT 日志？
答案3
检查你的 web.config，是否有 impersonate = true？
在这种情况下，在 IIS 中进行匿名访问时，尝试读取 web.config 的是 IIS 匿名用户，而不是应用程序池用户。
答案4
除了上述所有建议之外，您还可以尝试使用 Chrome Dev Tool [按 F12] 来查看是否有任何线索。同样，如果您无法使用 Chrome，也可以在 IE 上尝试此操作 [按 F12]。
https://developer.chrome.com/devtools有关详细信息，请查看网络和控制台区域