我一直在调查几天前在Windows 2003服务器上发生的问题。 有大约15个应用程序池，并在几分钟内，他们都在系统日志中产生以下错误：
A process serving application pool 'Pool 31x' failed to respond to a ping. The process id was '7144'. 然后池自动重新启动，但在启动过程中超时，将所有站点closures。
我的问题是：什么会导致在同一时间所有的应用程序池“ping超时”，然后他们为什么会启动太慢？
每个池中的应用程序都是使用.NET 1.1框架的WCMS。 它连接到远程数据库，但独立于其他机器。
IIS中的“Ping”不过是W3SVC完成的用于监视工作进程状态的健康检查。 当您看到诸如“应用程序池appPool的进程无法响应ping”的事件时。 意味着进程处于死亡状态。
快速失败保护是一种处理这种问题的回收选项，它可以自行回收appPool，从而保持工作stream程的良好状态。
您需要debugging过程才能find问题的根源。
既然你有.net应用程序加载在工作进程中，检查应用程序事件日志并查看任何.net框架警告或错误不是一个坏主意。 您可以将debugging诊断工具附加到进程并转储以检查导致问题的原因。 请按照文章如何使用debugging诊断工具来解决在IIS中停止响应的进程
你看了全球HTTP错误日志 ？
它被称为httperr.log ，通常位于主W3CSVC1服务下的日志文件目录C:\windows\system32\LogFiles 。
每当我有一个应用程序池的问题，该文件已相当有帮助。