IIS部署.Net站点重启IIS/服务器后仍挂起无响应问题咨询

结合给出的日志特征，故障本质是SignalR长连接与Forms认证机制的冲突，触发IIS工作进程僵死，具体触发链路如下：

• E2E测试通常会并发执行多用户登录、身份切换、高频接口请求、长连接重连操作，当测试运行时长超过Forms认证票据默认有效期时，大量携带过期票据的请求会打到服务端，触发Forms authentication failed for the request. Reason: The ticket supplied has expired报错。
• 此时已经建立的SignalR长连接持有的是旧的有效身份上下文，新请求携带的过期/刷新后新的身份上下文和连接绑定的身份不匹配，就会抛出The user identity cannot change during an active SignalR connection异常；如果这个异常没有被业务代码捕获处理，会直接阻塞ASP.NET管线的身份认证模块，导致对应请求既不返回也不释放线程。
• 阻塞的请求会持续占住HTTP监听通道的句柄，当IIS触发应用程序池回收/重启逻辑时，无法在默认超时时间内释放HTTP监听资源，就会出现Failed to stop a listening channel for protocol 'http' at allotted time from worker process serving application pool和A process serving application pool exceeded time limits during shut down的报错，此时w3wp工作进程进入半僵死状态：既不处理新请求，也无法被正常终止。
• 内核态HTTP.sys组件发现请求队列里的连接长期得不到工作进程处理，就会主动丢弃连接，对应HTTPERR日志里的Connection_Abandoned_By_ReqQueue和Connection_Dropped记录；这部分请求根本没有走完完整的IIS用户态处理流程，所以inetpub站点日志里只会记录正常处理完成的请求，抓不到异常痕迹。
• 重启站点、应用池、IIS甚至整机都无法恢复的表现，本质不是重启操作失效，是重启后第一波E2E测试请求会立刻复现上述冲突逻辑，故障马上重现，给人“重启没用”的错觉。

• 故障复现时第一时间抓取对应应用程序池的w3wp.exe进程转储，不要先重启：打开任务管理器找到对应PID的w3wp进程，右键选择“创建转储文件”，用WinDbg加载转储后查看所有线程的调用栈，90%以上场景能看到大量线程卡在FormsAuthenticationModule的认证校验逻辑、或者SignalR连接身份检查的等待逻辑上，可以直接定位死锁点。
• 打开性能监视器，添加两个核心计数器监控：HTTP Service Request Queues\CurrentQueueSize（选择对应应用池的实例）、W3SVC_W3WP\Active Requests，故障触发时如果队列长度持续上涨、活跃请求数只增不减，即可确认是请求处理管线被阻塞。
• 开启IIS失败请求跟踪，针对503状态码、请求耗时超过10s的请求创建跟踪规则，复现故障后查看跟踪日志，确认请求卡在管线的哪个具体模块。
• 核查应用程序池配置：确认是否开启了固定间隔回收、空闲超时回收，这类自动回收逻辑如果在E2E测试运行过程中触发，会大幅提升长连接身份冲突的复现概率。

• 补全SignalR连接的异常处理逻辑：在SignalR管道中增加身份校验环节，一旦检测到当前请求的身份上下文与连接建立时绑定的身份不一致，主动调用API断开当前连接，不要抛出未处理异常阻塞请求管线，从根源解决身份变更导致的锁死问题。
• 适配E2E测试场景的认证配置：测试环境下适当延长Forms认证票据的有效期，开启滑动过期逻辑，避免测试执行过程中大量票据集中过期；也可以给测试环境配置跳过认证的白名单规则，减少异常认证请求的冲击。
• 调整应用程序池参数：将应用程序池的“关闭时间限制”从默认的90秒下调到30秒，开启孤儿进程收容配置，确保僵死的w3wp进程能被强制终止，避免出现进程无法正常退出导致池重启失败的问题；测试运行期间临时关闭固定间隔回收、空闲超时回收策略，避免测试过程中触发不必要的进程回收。
• 调整HTTP.sys请求队列参数：将应用程序池的请求队列长度限制从默认的1000下调到合理阈值（比如200），避免大量阻塞请求占满队列导致所有新请求被直接拒绝。

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