如何排查部署在IIS上的ASP .NET Web API无响应故障

• BigIP健康检查配置不合理：默认仅配置了端口存活检测，故障时IIS端口仍处于监听状态，且可以正常返回401鉴权响应，导致健康检查判定节点状态正常，不会自动摘除故障节点。若健康检查周期设置过长、重试阈值过高，也会延迟节点摘除动作。
• 会话保持规则影响：若开启了源IP、Cookie等维度的会话保持，已有会话会持续绑定到故障节点，直到会话过期或节点被健康检查摘除。

当前给出的CrashHangAnalysis报告无法直接判定为死锁。报告仅显示4个线程处于SRW锁等待状态，未出现死锁必备的循环持有等待特征，也没有全量线程阻塞的表现。但存在明显的锁竞争异常征兆，需要结合故障现场的全内存转储做进一步分析。

• 系统原生工具：
  • 性能监视器（PerfMon）：可采集ASP.NET请求队列长度、请求处理耗时、工作进程线程数、IIS连接数等全维度指标，无额外成本。
  • IIS失败请求跟踪（FRT）：可自定义规则捕获慢请求、异常请求的完整管道处理流程，定位请求卡住的具体环节。
  • 事件查看器：可查看系统、应用、IIS相关的错误日志。
• 微软官方免费工具：
  • DebugDiag：可配置自动捕获进程崩溃、挂死、内存泄漏场景的内存转储，自带基础分析能力。
  • Process Explorer/Process Monitor：可查看进程的资源占用、句柄持有、文件/网络调用记录。
• 开源工具：
  • Prometheus + windows_exporter + Grafana：可实现多节点指标统一可视化采集、告警，无软件授权成本。

1. 先修复负载均衡切流逻辑：将BigIP的健康检查调整为应用层检测，新增无鉴权的健康检查接口，验证Web API可正常连接数据库、执行业务逻辑后返回200状态码，将健康检查间隔调整为10s，连续2次检测失败立即摘除节点，关闭非必要的会话保持规则，降低故障影响面。
2. 捕获故障现场：在低级别环境配置DebugDiag hang规则，当w3wp进程请求处理耗时超过30s时自动抓取全内存转储；开启PerfMon长期日志采集，记录故障前后的性能指标变化；开启IIS失败请求跟踪，捕获所有耗时超过10s的请求。
3. 修复监控基础问题：执行lodctr /r重建系统性能计数器库，再执行C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i重新注册ASP.NET 2.0组件，解决性能计数器加载失败的问题，确保监控数据完整。
4. 根因定位：拿到故障内存转储后用WinDbg加载SOS调试扩展，执行!syncblk查看托管锁持有情况，执行!dlk检测死锁，追踪持有SRW锁的线程调用栈，定位未释放锁的业务逻辑。重点排查鉴权环节后的代码，是否存在同步等待异步方法、数据库连接泄漏、非托管资源未释放的问题。

注：Cortana激活失败、BITS性能计数器错误、加密服务单次报错均和当前IIS Web API故障无关联，无需优先排查。

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