一个应用程序池的aspx应用程序中的exception是否也可能导致其他应用程序池出现问题？
我经历了一个IIS v7.5的问题，在一些应用程序错误和所有http请求超时之后，整个IIS都没有响应。 但是，宕机时间日志文件并没有透露关于这个问题的很多信息。
如果是的话，在什么情况下可能会发生？
通常不是，但是这取决于例外的原因，以及根本原因是否在（或正在破坏）共享资源。
在一个典型的，无共享的，默认的网站世界里，每个W3WP都有自己的内存空间，句柄表和相关的资源，这些对于这个过程是独一无二的。 一个崩溃，没人关心。 （另外：实际上，如果它真的是默认的网站，也就是只有静态内容，崩溃会非常奇怪，并且是一个很好的指标，说明框上发生了一些真正的错误 ）。
如果Web应用程序select使用资源（例如数据库表或磁盘上的某个文件），并且多个Web应用程序使用相同的资源，则其中一个问题可能间接导致其他问题。
例如：在stream程A中启动的大量昂贵的 SQL查询（您没有捕获到超时exception）仍在捆绑同样用于进程BC和D的数据库服务器，这些服务器也在等待超时。 。
或者，如果一个networking应用程序在同一个盒子上对另一个应用程序池进行HTTP调用，那么是的，这是一个明确的依赖关系和一个明显的问题！
但一般情况下，如果出现一切都出错的情况，如果你运行多个Web应用程序，他们不太可能是原因…原因更可能是其他软件，90％的时间与一个内核模式组件，在框中运行。
主要的例子是：依赖于SMB共享（即\ server \ share上的内容）的东西，特别是当目标是非Windows SMB模拟器（所以不兼容bug）或其他有趣的IOfilter驱动程序正在使用时整洁地把我们带到了这种性质的杀毒软件和过滤驱动程序… K模式驱动程序拿起文件访问，通过一个u-mode过程重新路由请求，这个过程变得繁忙或者交叉，造成k-mode IO延迟，有趣）。 （值得一提的是authentication基础设施停机导致的authentication困难）。
尽pipe如此，这只是猜测，没有任何数据，所以最好的第一步是抓取内存转储（DebugDiag或任务pipe理器），将它们提供给DebugDiag或一个友好的Windbg能力的滚动，并让他们尝试确定是否有用户模式导致延迟。
如果没有，那么你转到K模式的故障排除，事情会变得有点混乱（最常见的是，bluescreening框获得K模式崩溃转储，而怪异进行中）。