应用池回收后IIS停止响应，咨询可排查的日志方向

阿华AIGC实验室

2026-5-14

排查IIS应用池回收后Connection_Dropped问题的额外方向

基于你遇到的这个应用池回收（23:00整点触发）后出现大量Connection_Dropped错误、仅部分请求能成功的问题，结合Windows Server 2012 + IIS 8.5 + ASP.NET MVC的环境，除了你已经排查的日志外，还可以从以下几个方向深挖：

启用并查看应用池回收的详细事件日志
默认情况下，IIS不会记录应用池回收的全部细节。你可以打开IIS管理器，找到目标应用池→右键→高级设置，找到「生成回收事件日志条目」，把所有回收条件（比如时间间隔、内存限制等）对应的选项都勾选上。之后去事件查看器的「应用程序日志」里找WAS（Windows Process Activation Service）相关的事件（ID通常是5074、5075、5076），这些日志能告诉你回收时旧进程是否正常退出、新进程是否及时启动，有没有出现进程启动超时或者资源加载失败的情况——毕竟重叠回收如果出问题，很可能导致请求在新旧进程切换时被丢弃。
开启失败请求跟踪（Failed Request Tracing）
虽然你提到部分请求没被IIS日志记录，但失败请求跟踪能捕捉到请求从进入IIS到处理的每一个环节。你可以给目标站点添加一条失败请求跟踪规则：选择跟踪所有内容，状态码覆盖400-599（或者临时跟踪所有请求，排查完再关掉）。生成的跟踪日志会详细展示请求经过的IIS模块（比如URL重写、Forms认证、ASP.NET集成模块等），能帮你判断是不是某个模块在处理请求时出现异常，导致连接被主动断开。
深挖系统日志里的HTTP服务和WAS事件
别只盯着应用日志，去事件查看器的「系统日志」里找「Microsoft-Windows-HttpService」和「Microsoft-Windows-WAS」相关的事件。比如ID 10013（HTTP服务无法绑定特定端口，不过你uptime页面能访问，这个可能性低，但还是要确认）、ID 7031（WAS服务意外重启）等，这些日志能暴露系统层面的服务异常，可能是导致连接丢弃的根源。
开启ASP.NET的详细跟踪和CLR日志
在你的ASP.NET MVC应用的web.config里，临时开启详细错误和跟踪：
```
<customErrors mode="Off"/>
<system.web>
  <trace enabled="true" pageOutput="false" requestLimit="100" traceMode="SortByTime"/>
</system.web>
```
同时，去事件查看器的「应用程序和服务日志」→「Microsoft」→「Windows」→「ASP.NET 4.0.30319」里查看CLR相关的异常和加载日志，这能帮你判断是不是应用启动时出现了未捕获的异常，导致新进程无法正常处理请求（毕竟uptime页面可能不需要加载某些核心资源，所以能正常响应）。
网络层面的捕获和分析
既然是Connection_Dropped，TCP层面的问题也不能忽略。你可以用Windows自带的netsh命令捕获网络包：
```
netsh trace start capture=yes tracefile=C:\temp\recycle_issue_trace.etl
```
重现问题后停止捕获：
```
netsh trace stop
```
然后用Windows Performance Toolkit打开生成的.etl文件，分析TCP连接的建立、数据传输和断开过程，看是不是服务器端在收到请求后没有响应，或者主动发送了RST包。另外，也可以检查Windows防火墙的日志，确认有没有规则误拦截了某些路径的请求（虽然uptime页面正常，但不排除特定路由被拦截的可能）。
监控应用池回收时的磁盘IO和文件锁定
应用池回收时，ASP.NET需要重新编译视图、加载程序集和配置文件，如果此时磁盘IO过高，或者某个关键文件（比如web.config、bin目录下的DLL）被其他进程锁定，会导致新进程启动缓慢，这期间的请求就会被丢弃。你可以用Process Monitor（ProcMon）监控w3wp.exe进程的文件操作，过滤出回收时段的事件，看有没有文件访问超时、拒绝访问的情况。
检查应用池的进程模型设置
确认应用池的「进程模型」里的「重叠回收」是否启用（默认是启用的）——如果没启用，旧进程退出后新进程才启动，这期间会出现服务中断，导致请求被丢弃。另外，检查「请求队列限制」是不是设置得太小，回收时请求队列溢出也会导致连接被丢弃。