最近发布在windows server2012 IIS8.0上的一个WebAPI项目，才几十个人在线，CPU就会出现过百情况，并且CPU一旦过百应用程序池就自动暂停掉，看到这个问题我感觉应该是程序哪个地方出了问题， 8盒16G 应该配置还是可以的。打算使用windbg找到这个问题。
为了快速定位问题我就直接在生产环境安装了windbg，为了采集dump文件，我选择Procdump。Procdump无需安装，下载下来直接放到一个目录下即可。以下是解决问题的过程+截图：
步骤一：
安装windbg,注意32和64，要安装相应的版本,直接点击下一步即可。
步骤二：
Copy Procdump 文件到服务器上的一个目录下,目录没有限制
如图：C:softwareProcdump，这里的dbghelp.dll是从windbg安装目录下copy过来的，是我为了解决下面这个坑：调试High CPU问题的时候经常用到的一个命令是!runaway，但是有些时候!runway在ProcDump抓取的dump中提取不出来。解决的方法是将Debug Tools for Windows (windbg)安装目录下的dbghelp.dll拷贝到procdump目录下，然后再运行命令抓取dump。
0:000> !runaway ERROR: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"
步骤三：
在doc窗口下执行procdump命令，cd /d c:SoftwareProcdump
步骤四：
执行procdum命令，执行 procdump -c 50 -s 4 -ma -n 3 w3wp 命令含义为:当w3wp.exe cpu超过50%,并且持续4秒，抓取3个dump文件存储起来，存储位置默认为procdump文件所在的目录。
如图：
出现如图结果证明已经进入监控状态。接下来就是等着CPU超过50%了。
没过一会就看到效果了
dump文件已经抓取到，我们来看下dump文件存储位置：
那么接下来就是开始分析了。
步骤五：
启动已经安装好的Windbg，开始分析采集的dump文件
步骤六：
为了不影响正在运行的项目，我将发布的项目文件单独从copy了一份出来，如图所示：我是web api项目
步骤七：
设置系列目录：
Windbg->file->Symbol File Path
Windbg->file->Source File Path
步骤八：
加载dump文件
Windbg->file->open Crash Dump
先选择第一个dump文件。
步骤九：
载入sos.dll 执行.load C:WindowsMicrosoft.NETFramework64v4.0.30319SOS.DLL
我是4.0 的 注意版本 64位
步骤十：
!threadpool 查看当前CPU状况 线程数等等
步骤十一：
执行 !runaway 命令 查看那几个线程使用的高
步骤十二：
~线程IDs 跳转到那个线程
步骤十三：
!clrstack 看看这个线程再干嘛 执行那些方法
步骤十四：
将图中红框列出来的方法去项目中查找下，发现了问题：
重载方法的时候参数传递不正确，出现了死循环，至此问题得到了解决。
参考文档 ：http://blog.csdn.net/qyee16/article/details/19069883
https://ss64.com/nt/procdump.html
http://www.cnblogs.com/junchu25/p/3785790.html
http://www.cnblogs.com/cuiweifu/p/3786461.html