IIS Windows Authentication模块在AuthenticationRequest状态拖慢全站问题咨询

初步结论 #

首先可以排除IIS Windows认证机制的通用缺陷：相同代码在同一服务器的其他应用池中运行无异常，说明问题和当前出故障的应用池的专属配置、以及代码中与Windows认证上下文相关的资源泄漏强相关，并非Windows Server 2012或IIS的通用Bug。
你观察到的重启应用池即可恢复的现象，也符合资源泄漏的典型特征：重启会销毁当前工作进程，所有未释放的资源（句柄、内存、认证令牌缓存）全部被系统回收，服务恢复正常。

具体排查方向 #

1. 对比故障应用池与正常应用池的配置差异 #

重点核对以下配置项：

• 应用池高级设置：检查最大工作进程数是否大于1、加载用户配置文件开关状态、托管管道模式（集成/经典）是否和正常池一致，Windows认证的令牌缓存逻辑和上述配置强关联，配置不当会导致令牌无法正常回收
• 站点认证配置：检查故障站点的Windows认证下的内核模式认证开关是否关闭：内核模式下认证逻辑由IIS内核模块处理，资源回收由系统管控；如果手动关闭了内核模式，认证逻辑转移到工作进程的用户态执行，很容易因为代码问题出现资源堆积

2. 排查代码侧的认证相关资源泄漏 #

你描述的请求卡在WindowsAuthentication模块的AuthenticateRequest阶段，是典型的认证资源耗尽的表现，优先排查以下代码问题：

• 检查代码中是否存在手动操作WindowsIdentity、WindowsPrincipal对象的逻辑：这类对象关联了非托管的Windows令牌句柄，如果没有主动调用Dispose()释放，会导致工作进程的句柄数持续上涨，新的认证请求无法申请到可用句柄就会进入阻塞状态
• 故障发生时可以通过任务管理器查看对应w3wp.exe进程的句柄数、用户对象数：如果数值远高于正常运行的同应用工作进程，即可实锤是资源泄漏，后续可以用DebugDiag抓进程转储分析未释放的对象堆栈定位具体代码位置

3. 临时规避方案 #

如果短时间无法定位具体代码问题，可以先配置故障应用池的定期回收策略：设置固定时间间隔/请求数阈值自动回收应用池，在不影响业务的前提下先规避卡顿问题，同时并行排查根因。

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