IIS 10中ASP.NET应用池随机停止处理请求，寻求排查方案

核心现象确认 #

• 进程无响应触发IIS健康检查警告：A process serving application pool 'XYZ' failed to respond to a ping.
• 高CPU负载、线程空转，不处理新请求，内部日志停止输出
• 应用池回收后旧进程无法自动退出，需手动终止

排查步骤 #

1. 捕获现场线程转储 #

当问题再次出现时，立即对异常w3wp进程生成内存转储：

• 用任务管理器：右键进程 → 创建转储文件
• 用Procdump命令：procdump -ma <进程PID> -o high_cpu_dump.dmp（-ma生成完整内存转储，-o覆盖已有文件）

分析转储文件：

• 用Visual Studio或WinDbg打开，查看所有线程的调用栈
• 重点排查：是否有大量线程卡在AsyncStateMachine.MoveNext()方法，或存在重复循环的调用链——这是异步无限循环的典型特征
• 检查线程池线程的状态，确认是否所有可用线程都被占用

2. 监控线程池与异步操作指标 #

在应用中添加实时监控，提前捕获异常征兆：

• 定期记录线程池状态：每30秒调用ThreadPool.GetAvailableThreads(out int worker, out int io)，记录可用工作线程、IO线程数及队列长度
• 跟踪异步任务生命周期：自定义日志记录异步任务的创建、完成、等待事件，重点关注是否有任务重复触发却无法完成
• 启用.NET ETW事件：跟踪System.Threading.Tasks.TplEventSource，捕获异步任务的调度细节，排查循环触发的任务流

3. 排查异步代码的循环逻辑 #

针对潜在的异步无限循环场景，重点检查：

• 带循环的异步方法：比如while(condition) await SomeAsyncMethod()，确认循环条件是否可能永久为真（如状态变量未在异步操作后正确更新）
• 异步回调链式调用：检查是否存在“处理完任务后再次触发相同任务”的逻辑（如消息队列处理完消息后重新入队）
• 未正确处理的异步状态：比如TaskCompletionSource未完成，导致异步代码一直等待，进而触发重复重试逻辑

4. 解决旧进程无法自动退出问题 #

• 检查IIS应用池设置：调整“关闭超时时间”（默认90秒），缩短超时时间让IIS强制终止无响应的旧进程；开启“立即回收”选项，避免旧进程残留
• 检查应用内线程：确认所有后台线程都设置为IsBackground = true，前台线程会阻止进程自动退出

5. 临时缓解措施 #

• 调整IIS健康检查参数：将ping间隔从默认30秒改为10秒，加快异常进程的检测与回收速度
• 脚本自动监控：编写批处理/PowerShell脚本，定期检查w3wp进程CPU使用率，若持续超过90%达1分钟，自动生成转储并终止进程

内容的提问来源于stack exchange，提问作者aoven