我们正在运行一个托pipe几十个网站的IIS7服务器。 这些网站中的几个都是我们开发的同一个遗留应用程序的一部分。 这些网站都运行相同的代码，并在同一个应用程序池中运行。
在过去的几个月大概一个月一次，我们发现这个应用程序池的所有请求开始无限期地挂起。 发生这种情况时，我们会收到警报，并回收应用程序池。 之后，网站再次开始工作。
这只会影响这一个应用程序池 – 从来没有在同一台服务器上的其他人。 几次，在回收池之前，我已经查看了工作进程中当前正在执行的请求。 它们都显示为在WindowsAuthenticationModule内执行。 这很奇怪，因为绝大多数应用程序不需要validation。 有一个小的pipe理部分使用Windows身份validation…但所有其他请求应该是匿名的。
有没有人有任何想法，可能是什么原因造成的？
关于这些网站的build立方式有几个不寻常的事情。 正如我所提到的，它们都运行相同的代码 – 多个站点指向相同的物理目录。 唯一的区别是主机头绑定。 我不知道为什么不是只有一个网站包含所有的主机标题，但是这是如何工作的。
在其中一些站点中，同一个物理目录被映射到两个级别 – 作为站点的根目录，并再次作为站点内的应用程序。 所以如果用户去http://oursite.com/index.aspx ，映射到c：\ files \ oursite \ index.aspx。 如果用户访问http://oursite.com/foo/index.aspx ，也会映射到c：\ files \ oursite \ index.aspx。 我认为有代码查看请求URL并以不同方式处理这两个请求。
这很奇怪，因为相同的web.config最终被解释为一个站点configuration文件，并且也是一个站点内的应用程序configuration文件。 我不知道这是否与authentication问题有关。
如果我们找不到原因，我们正在考虑一些我们可以尝试的解决方法：
将pipe理部分移到单独的站点，并为客户端指定一个新的pipe理员URL。 在自己的应用程序池中运行单独的网站。 然后在所有其他站点共享的web.config中，删除WindowsAuthenticationModule。 那样的话，WindowsAuthenticationModule中就不应该有挂起的可能。
尝试在经典pipe道而不是集成pipe道中运行所有这些站点。 他们在我们的旧IIS6服务器上工作得很好…
（如果我们感到绝望）设置一个监视脚本来监视站点，并在检测到请求被卡住时自动回收应用程序池。
你怎么看？
谢谢你的帮助，
理查德
我会尝试右键单击在挂起的应用程序池下执行的w3wp.exe进程。 右键单击它并select，创build转储文件。
或者：
要么：
使用netsh激活日志logging来查看kerberos令牌请求（我还没有试过这个IRL）：
PS C:\> netsh trace show providers | select-string kerberos PS C:\> netsh trace show providers | select-string kerberos PS C:\> netsh trace show providers | select-string auth PS C:\> netsh trace show providers | select-string auth
…然后是这样的东西：
netsh trace start provider={5BBB6C18-AA45-49B1-A15F-085F7ED0AA90}
要么：