IIS托管WCF服务突发400错误 回收应用程序池可恢复故障排查

这类回收应用池即可恢复、请求能进入服务方法入口但执行中途报错、全接口同时异常的问题，本质都是IIS工作进程（w3wp.exe）内的WCF运行时状态或全局共享资源损坏，不是单个接口的业务逻辑bug，可按以下方向逐一排查：

一、先修正现有排查手段的配置缺陷 #

你之前开的WCF跟踪级别不足以定位这类问题，先调整配置：

• 故障复现前临时将WCF跟踪的捕获级别从当前的Critical/Error/Warning调整为Information级，同时开启WCF消息日志功能，将logEntireMessage、logMalformedMessages、logMessagesAtServiceLevel三个配置项设为true。大部分WCF管道层、序列化层的异常默认不会打到Error级别，之前没查到有效线索基本是跟踪级别开得太低。

注意：全量跟踪会占用大量磁盘空间，抓到故障日志后立刻调回原配置，避免影响服务正常运行。

• 给服务加全局IErrorHandler实现，把所有被WCF管道捕获、甚至默认会被吞掉的异常全量记录日志，要包含完整异常堆栈、所有内部异常、触发异常的请求参数、当前线程ID。你之前只打了方法入口日志，没有覆盖方法执行全链路的异常出口，很多被WCF包装成400的错误根本不会走到你业务代码的异常分支。

二、核心排查方向 #

1. 全局静态资源/线程绑定状态污染 #

这是这类故障最高发的原因：

• 全局检索服务代码、所有依赖类库中用static修饰的共享变量，重点关注标记了[ThreadStatic]的变量、非线程安全的静态实例（比如静态字典、静态DataContractSerializer实例、静态数据库连接、静态缓存的WCF客户端代理）。
• 重点检查这些静态变量有没有在异常分支下被赋值为null、被提前Dispose、被写入非法格式值的情况：一旦某个请求触发了这种错误赋值，后续所有请求访问这个静态变量时都会触发异常，且这种进程内的状态污染只有回收进程才能重置。
• 给所有静态变量的赋值逻辑加埋点，记录赋值时间、触发赋值的请求ID、赋值时的调用栈、写入的值内容，故障发生后直接查最后一次修改对应静态变量的日志，就能定位污染源。

2. WCF限流配额耗尽/会话泄漏 #

• 检查服务配置中的serviceThrottling节点配置，默认的maxConcurrentCalls（16）、maxConcurrentSessions（100）、maxConcurrentInstances（26）阈值非常低，如果有调用方没有正确关闭WCF代理、或者使用了会话模式的接口没有及时释放实例，会把配额占满，部分配置下会直接返回400错误。
• 故障发生时不要立刻回收应用池，先打开Windows性能监视器，查看ServiceModelService 4.0.0.0分类下的Calls Outstanding、Instances、Sessions三个计数器数值，如果数值和你配置的限流阈值持平，就可以确定是实例/会话泄漏，对应排查设置了SessionMode=Required、InstanceContextMode为PerSession/Single的接口，确认资源释放逻辑是否正确。

3. 序列化缓存损坏 #

WCF默认使用的DataContractSerializer会在运行时动态生成序列化程序集做缓存，如果遇到特殊结构的入参/出参、动态加载的类型、泛型嵌套过深的场景，可能触发序列化缓存内部损坏，后续所有序列化/反序列化请求都会失败，这类错误只会在Information级别的WCF跟踪中留下SerializationException记录。

4. 非托管资源泄漏 #

虽然你观测到CPU、内存占用无异常，但还是要在故障发生时检查对应w3wp.exe进程的GDI句柄、线程句柄、网络套接字句柄数：如果句柄数超过1万、线程数持续上涨超过100，说明依赖的某个组件存在非托管资源泄漏，进程级资源耗尽后WCF在写入响应的阶段会抛出未捕获异常，返回400错误，这类问题同样只能通过回收进程恢复。

三、故障发生时的固定操作流程 #

下次故障复现时，不要第一时间回收应用池，先按顺序做以下操作保留现场：

1. 打开任务管理器，找到对应w3wp.exe进程，右键选择「创建转储文件」，把全量进程dump存到非服务目录，后续可以用DebugDiag或WinDbg分析dump内的托管异常、阻塞线程、静态变量值，哪怕暂时不会分析，先保留现场就有定位根因的可能。
2. 发一个最简单的心跳测试请求（入参出参都是string/int这类基础类型，无复杂逻辑），确认故障是否复现，同时查看IIS日志、HTTPERR日志中400错误对应的子状态码，不同子状态码对应明确的故障方向：比如400.9是请求格式被拦截、400.6是动词不被允许、400.1是请求头无效。
3. 打开Windows事件查看器，检查「应用程序」「系统」日志下WCF、IIS、.NET Runtime来源的错误，很多进程级、管道级的错误不会打到WCF跟踪文件，只会记录在系统事件日志里。

临时规避方案 #

根因定位完成前，可以给对应应用池配置自动回收规则：比如设置每8小时固定时间回收、或者设置请求数/私有内存阈值触发回收，大幅降低故障发生的概率。

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