出问题的程序还是那个CPU100%的程序（就你事情多）。反正就是在查CPU占用率100%时顺带发现的，在进程垃圾回收期间，服务停止响应，没有接口调用，没有调用日志，没有错误日志，在事件管理器的安全子类下出现大量 Event 5152 的审核失败日志，如图。

其中这个 Event 5152 是 Windows 筛选平台（WFP）的一个事件ID。

这个问题我还提问了Stack Overflow：
Windows Event-5152 happens during WCF program is GC and the WCF stops serving

so 上面的人认为是因为没有开启防火墙导致 WFP 的工作，然而经过实验，这并没有效果。只能得出垃圾回收导致进程 stop the world，然后 WFP工作了。大致上是服务接受到1个请求，然后发生了垃圾回收，其他请求没有被进程相应，WFP 判断这些请求超时后就写入了 windows 日志。

问题在 WFP 上卡死后，只能把研究对象转向到垃圾回收上。查阅相关资料：
垃圾回收的基础
<gcServer>配置
后发现.net 默认垃圾回收模式是工作站模式（Workstation GC），这个模式下的后台垃圾回收是 Stop The World 的，而且是单线程的。而假如启用服务器模式（Server GC）则默认是多线程的（每个核一个线程），这会大大减少 Stop The World 的时间。

相关设置如下。

在APP.confg 文件中configuration节点下增加
  <runtime>  
    <gcServer enabled="true"/>  
  </runtime>  

测试结果：

这里的测试用的是本机调用的方式，每隔1秒并发调用4次接口，可见这个并发量级对这个服务已经产生了比较大的压力，垃圾回收非常频繁，而切换到服务器模式的并发回收后，% Time in GC（GC 所占时间百分比）几乎无法察觉，可见对其对性能的提升。接口测试更是显示了10倍的平均提升，2倍的最差性能提升。

然而大概是因为本机调用走的 localhost 本地环回地址，WFP 并没有产生任何 Event 5152 的日志。当然我的测试已经到此为止了。

（领导也拒绝了相关的配置修改）

关于 so 上我做比较的那个服务没有出现类似现象的原因应该是那个服务的客户端是长链接的，虽然调用密度大很多倍（每秒1000次），但整个通道的上下文对象却没有什么变动，见前文中 WCF 复杂的内部调度器。

当你认为微软粑粑已经把所以事都做了的时候，你会发现微软粑粑确实都做了，然而他把所有东西都锁了起来，并给了你一个九连环，里面套住了所有的钥匙。