我在IIS7中创build了一个新的站点，在该站点下面添加了一个新的应用程序。 当尝试使用位于此新应用程序下方的ASP.NET Web服务时，出现HTTP 500内部服务器错误。
我查看了事件日志，IIS日志，并试图设置“失败的请求跟踪”，但似乎没有任何跟踪。 我有它设置来检查所有内容，详细的错误logging和HTTP错误范围从400-600。 但是在FailedReqLogFiles文件夹下没有任何logging。 在这个IISconfiguration中的其他网站似乎跟踪失败的请求就好了。
我可以看到在这个站点的IIS日志中logging了HTTP GET请求，但是它们显然不是非常有用，因为它们只是显示返回500错误的请求。
我已经检查了资源pipe理器中网站文件夹的权限，并且确保匿名访问已启用，并且应用程序池标识也可以访问文件夹的内容。
有任何想法吗？ 我给了关于这个问题的足够的信息吗？ 预先感谢您提供的任何帮助或build议。
您是否运行进程监视器来查看IIS是否具有写入FRT日志的适当权限？
使用失败的请求追踪，您需要设置规则，但作为一个单独的步骤，您必须打开它。 在失败的请求跟踪中，检查右侧的操作窗格，该窗格将有一个选项来启用它。 这是我的猜测，为什么跟踪不起作用。
对于每个应用程序池有1个站点的IIS7中的任何configuration，或者当所有站点彼此信任并且站点稳定时，我的build议是将匿名身份validation设置为使用应用程序池的标识。 这样可以减less用户处理的次数。 然后确保应用程序池标识被授予磁盘上的权限。
你提到它不能在子文件夹中工作。 可以为子应用程序使用不同的权限或不同的应用程序池。 仔细检查正在使用的应用程序池，以及匿名身份validation设置。
最后，Colinbuild议使用Process Monitor。 从www.sysinternals.com得到它。 它是免费的，可以安全地在生产服务器上运行，并在10分钟内完成。 这将告诉你到底哪个用户被拒绝访问哪个文件夹（或registry项）。
检查你的web.config，你有impersonate = true？
在这种情况下，在IIS中使用匿名访问，它将是尝试读取web.config而不是应用程序池用户的IIS匿名用户。
您的web.config必须位于您的Web应用程序文件夹的根目录下。 否则，你会得到各种各样的错误。
除了所有的build议，你也可以尝试Chrome开发工具[按F12]，看看你是否有任何线索。 同样，你也可以在IE上试试这个[按F12]，如果你不能有chrome的话。
https://developer.chrome.com/devtools了解更多详细信息，针对您的情况，请查看networking和控制台区域