出问题的程序还是那个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 上面的人认为是[……]
微软家的东西大多是基于消息（Message）和上下文（Context）实现的。所以总会有一个Manager的调度器存在负责传递消息和上下文。本文主要目的是通过编程实现获取接口调用时的参数，在前文中是通过 RequestContext 实现的，在这里则对WCF功能进行扩展。
参考文档：
最重要的架构图
这个架构图非常清晰的描述了这个 rpc 消息在 WCF 内部是怎么被调度的。（然而实际上我在写扩展的时候还是靠看 .net 源代码的
项目代码Demo：https://github.com/HDRorz/WcfServiceDemo
翻阅了[……]
所以为什么不用ASP.NET WebApi呢（这样就不需要IIS了（
流程上是先建一个WCF服务项目，然后用WCF配置工具打开App.config。在高级-终结点行为中新建一个配置，比如说起名为restfulBehavior，然后点下面的添加，选中webHttp，添加（当然也可以修改这个子节点的属性配置，比如说修改DefaultOutgoingResponseFormat为Json）。在服务-终结点里把Binging设置从原来默认的basicHttpBing改为webHttpBing，修改BehaviorConfiguration为刚才的restfulBehavior。
这样就完成[……]
WCF全称Windows Communication Foundation， 是微软爸爸开发出的用于构建面向服务的应用程序的统一编程模型。用于替代和统一.net remoting和web service。
WCF大致是以web service那个基于xml的soap为基础，又除http/https外同时支持tcp（net.tcp）、udp（net.udp）、msmq、named pipe这些通讯方式。也提供了json格式对象序列化方式（好像默认仅限web？）。当然实际上还支持扩展（比较麻烦），比如说把序列化协议改成protobuff。
Deep♂Dark♂Fan[……]
其实这个问题我在17年10、11月份的时候就遇到了，当时没有解决。当时我在AWS上折腾docker，我有一个php的docker想要访问宿主机的mysql，两个机器网络不一样（docker的傻逼网络？还是我tmd从aws处又拿了一个内网ip？），宿主机是172.31.x.x，docker是172.32.x.x，需求就是如何在docker里访问宿主机的mysql。（讲道理可以直接访问啊，但最后还是没搞定，具体情况记不清了，后来那台ubuntu好像sshd挂了，又开了一台amz linux ami，就没复现这个问题）
现在这个问题在我配置mysql innodb cluster时遇到的。我原[……]
不知道mysql5.7从什么时候加入了innodb cluster，于是mysql就有了2种集群路线，一个是使用NDB的mysql cluster，一个是用innodb 的mysql innodb cluster。
NDB意思是Network DataBase，是mysql cluster（非mysql）专用引擎，离开集群无法工作。NDB是一个shared nothing的内存数据库，不过官网说他会存储部分数据在硬盘上（猜测是blob类型，可能还有text类型）。NDB数据与mysqld进程分离，存储在专门的数据节点中，名为ndbd或ndbmtd（ndbd的多线[……]
项目地址：https://github.com/HDRorz/WriteFileHook
我这个项目是用VS2015 Community创建的。项目里设置的编译目标平台是Win8.1，底层库设置的VS2015，估计低版本的VS打开项目里的C++项目应该会有问题，而且因为我系统是Win7（还没装Win7 SDK）（拿到电脑就是Win7 sp1了，懒得处理了），在调试和编译时有很多麻烦，VS2015在编译C++时还会添加很多私货，在注册COM组件时还需要dcomp.dll、IEShims.dll、ucrtbased.dll（Win10 SDK）这3个dll。
dcomp.dll（网上下的）[......]
项目地址：https://github.com/HDRorz/WriteFileHook
起因是各系统日志太多，机器也太多，查日志和监控都非常痛苦，所以有意做一套日志收集系统。其实各大公司都有这种东西，现成的也有Elasticsearch + Logstash + Kibana这套解决方案。然而上头就有点推进困难，也畏首畏尾。其实日志系统的demo也做了3、4版了，各种方案都有。
我接到开发任务的时候大概是16年10月份，那时方案设计是直接在日志中间件里埋点，异步调用一个webapi统一存储，同时还实现了服务存活检测（
当然当时我还有另一个脑洞，就是无需修改原系统，直接hoo[……]
某日被告知文件没有生成，发现文件生成服务（WCF寄宿windows服务）异常阵亡。（服务监控没到位啊→ →）还好那个服务器的设置了发生异常dump内存镜像，收集了当时的尸体，同时Windows事件提示发生了堆栈溢出。
虽然（宇宙第一IDE）VS可以调试dump文件，但是还是有一些问题，比如说
64位调试器花费的时间比预期的要长
通过百度谷歌了一些解决方案，但是都没有作用，因为他就是花费时间长，晾旁边过了几个小时，切过去的时候竟然发现dump文件读取完成了。
然而接下来的操作依旧令人痛苦，切换一个线程也要等上几十分钟，还有就是日常符号加载问题。
这种时候只能寻求别的工具的帮[……]
