最近發布在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 看看這個線程再干嘛 執行那些方法
步驟十四：
將圖中紅框列出來的方法去項目中查找下，發現了問題：
重載方法的時候參數傳遞不正確，出現了死循環，至此問題得到了解決。
原文出處:http://www.mamingbo.com/page/yunwei/109/index.htm