最近发布在windows  server2012  IIS8.0上的一个WebAPI项目，才几十个人在线，CPU就会出现过百情况，并且CPU一旦过百应用程序池就自动暂停掉，看到这个问题我感觉应该是程序哪个地方出了问题， 8盒16G 应该配置还是可以的。打算使用windbg找到这个问题。

 

为了快速定位问题我就直接在生产环境安装了windbg，为了采集dump文件，我选择Procdump。Procdump无需安装，下载下来直接放到一个目录下即可。以下是解决问题的过程+截图：

 

 

步骤一：

安装windbg,注意32和64，要安装相应的版本,直接点击下一步即可。

 

步骤二：

Copy Procdump 文件到服务器上的一个目录下,目录没有限制

如图：C:\software\Procdump，这里的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:\Software\Procdump

 

 

步骤四：

执行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:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.DLL

我是4.0 的 注意版本 64位

 

步骤十：

!threadpool  查看当前CPU状况 线程数等等 

 

 

步骤十一：

执行 !runaway 命令  查看那几个线程使用的高

 

 

步骤十二：

~线程IDs 跳转到那个线程

 

步骤十三：

!clrstack 看看这个线程再干嘛 执行那些方法

 

步骤十四：

将图中红框列出来的方法去项目中查找下，发现了问题：

 

 

重载方法的时候参数传递不正确，出现了死循环，至此问题得到了解决。

原文出处: