一个应用程序池的 aspx 应用程序中的异常是否也可能导致其他应用程序池出现问题？
我遇到过 IIS v7.5 的问题，整个 IIS 因某个应用程序错误而无响应，并且所有 http 请求都超时。但是，日志文件在停机期间没有显示有关此类问题的太多信息。
如果是，那么在什么情况下会发生这种情况？
答案1
通常不是，但这取决于异常的原因，以及根本原因是否在（或是否破坏）共享资源。
在典型的、无共享的默认网站世界中，每个 W3WP 都有自己的内存空间、句柄表和相关资源，这些对于该进程而言都是独一无二的。一个崩溃了，没人在乎。（旁白：实际上，如果它真的是默认网站，即只有静态内容，崩溃将是令人震惊地很奇怪，并且很好地表明了某事真的错了正在盒子上发生）。
如果 Web 应用程序选择使用资源（例如，数据库表或磁盘上某处的文件），并且多个 Web 应用程序使用相同的资源，那么一个应用程序中的问题可能会间接导致其他应用程序中的问题。
例如：那极其昂贵您在进程 A 中启动的 SQL 查询没有捕获到超时异常，但仍在占用进程 BC 和 D 使用的同一个可怜的数据库服务器，而这两个进程也即将超时……
或者，如果 Web 应用程序对同一机器上的另一个应用程序池进行 HTTP 调用，那么，是的，这是一个明显的依赖关系，也是一个明显存在问题的情况！
但一般来说，如果您运行多个 Web 应用程序，则所有问题都同时出错，而这些错误不太可能是导致问题的原因......更可能是其他软件导致的，90％ 的情况下，这些软件都带有内核模式组件，在机器上运行。
主要示例为：依赖于 SMB 共享的内容（即 \server\share 上的内容），特别是当目标是非 Windows SMB 模拟器（因此不兼容错误）或正在使用另一个有趣的 IO 过滤驱动程序时……这巧妙地将我们带到了这种性质的防病毒和过滤驱动程序... K 模式驱动程序获取文件访问权限，通过 u 模式进程重新路由请求，该进程变得繁忙或交叉，导致 k 模式 IO 延迟，造成无尽的乐趣）。（特别提到由于身份验证基础设施中断而导致的身份验证困难）。
尽管如此，这一切都只是在没有任何数据的猜测，所以最好的第一步是获取内存转储（DebugDiag 或任务管理器），将它们提供给 DebugDiag 或友好的支持 Windbg 的 frolleague，并让它们尝试识别是否存在导致延迟的用户模式原因。
如果没有，那么您将转到 k 模式故障排除，事情会变得有点混乱（最常见的是，在出现怪异情况时对盒子进行蓝屏以获取 k 模式崩溃转储）。