中小研發團隊架構實踐之生產環境診斷工具WinDbg

生產環境偶爾會出現一些異常問題，WinDbg或GDB是解決此類問題的利器。調試工具WinDbg如同醫生的聽診器，是系統生病時做問題診斷的逆向分析工具，Dump文件類似於飛機的黑匣子，記錄著生產環境程序運行的狀態。本文主要介紹了調試工具WinDbg和抓包工具ProcDump的使用，並分享一個真實的案例。N年前不知誰寫的代碼，導致每一兩個月偶爾出現CPU飆高的現象。我們先使用ProcDump在生產環境中抓取異常進程的Dump文件，然後在不瞭解代碼的情況下通過WinDbg命令進行分析，最終定位到有問題的那行代碼。

<strong>一、診斷工具簡介

<strong>1.1 WinDbg

WinDbg是在Windows平臺下的、強大的用戶態和內核態調試工具。相比較於Visual Studio，它是一個輕量級的調試工具，所謂輕量級指的是它的安裝文件大小較小，但是其調試功能，卻比VS更為強大。它的另外一個用途是可以用來分析Dump數據。WinDbg是Microsoft公司免費調試器調試集合中的GUI的調試器，支持Source和Assembly兩種模式的調試。WinDbg不僅可以調試應用程序，還可以進行Kernel Debug。結合Microsoft的Symbol Server，可以獲取系統符號文件，便於應用程序和內核的調試。WinDbg支持的平臺包括x86、IA64、AMD64。雖然WinDbg也提供圖形界面操作，但它最強大的地方還是有著強大的調試命令，一般情況會結合GUI和命令行進行操作，常用的視圖有：局部變量、全局變量、調用棧、線程、命令、寄存器、白板等。其中“命令”視圖是默認打開的。

<strong>1.2 DebugDiag

DebugDiag最初是為了幫助分析IIS的性能問題而開發的，它同樣可以用於任何其他的進程。DebugDiag工具主要用於幫助解決如掛起、 速度慢、 內存洩漏或內存碎片，和任何用戶模式進程崩潰等問題。該工具包括附加調試腳本，側重於互聯網信息服務（IIS）應用程序、 Web數據訪問組件、 COM+和相關Microsoft技術、SharePoint和.NET。它提供可擴展對象模型中的COM對象的形式，並具有一個內置的報告框架提供的腳本主機。它由3 部分組成，包括調試服務、 調試器主機和用戶界面。

<strong>1.3 ProcDump

ProcDump是System Internal提供的一個專門用來監測程序CPU高使用率從而生成進程Dump文件的工具。ProcDump可以根據系統的CPU使用率或者指定的性能計數器來針對特定進程生成一系列的Dump文件，以便調試者對事故原因進行分析。

<strong>二、診斷工具下載

• <strong>WinDbg x86位版本下載：【http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi】
• <strong>WinDbg x64位版本下載：【http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools_amd64/dbg_amd64.msi】
• <strong>DebugDiag v2下載：【https://www.microsoft.com/en-us/download/details.aspx?id=49924】
• <strong>ProcDump v9.0下載：【https://download.sysinternals.com/files/Procdump.zip】

<strong>三、獲取異常進程的Dump文件

有以下四種方式獲取Dump文件，具體如下：

<strong>3.1 通過【任務管理器】獲取Dump文件，這樣獲取的是MinDump

<strong>3.2 利用WinDbg的adplus獲取Dump文件，這樣獲取的是FullDump

<strong>3.3 通過DebugDiag創建.NET異常轉儲Dump文件

<strong>3.4 通過ProcDump抓取異常線程Dump文件

現在重點介紹通過ProcDump抓取異常線程Dump文件，使用方法如下：

<strong>a. 命令行：

procdump [-a] [[-c|-cl CPU usage] [-u] [-s seconds]] [-n exceeds] [-e [1 [-b]] [-f <filter>] [-g] [-h] [-l] [-m|-ml commit usage] [-ma | -mp] [-o] [-p|-pl counter threshold] [-r] [-t] [-d ] [-64]  [dump file] | -i  | -u | -x   [arguments] >] [-? [ -e]

b. 實例：

<strong>procdump -c 70 -s 5 -ma -n 3 w3wp

當系統CPU使用率持續5秒超過70%時，連續抓3個Full Dump。

<strong>procdump outlook -p "\Processor(_Total)\% Processor Time" 80

當系統CPU使用率超過80%，抓取Outlook進程的Mini Dump。

<strong>procdump -ma outlook -p "\Process(Outlook)\Handle Count" 10000

當Outlook進程Handle數超過10000時抓取Full Dump

<strong>procdump -ma 4572

直接生成進程號為4572的Full Dump。

<strong>

下圖是在WindgbHighCpu進程中造成High CPU時運行ProcDump命令的運行效果，可以看到在CPU每次持續5秒達到5%後就會生成相應的Dump文件，共生成了3份Full Dump文件：

<strong>c. 注意：

• ProcDump需要進程已經啟動，並且中途不能停止。比如需要抓取IIS Worker Process的High CPU Dump，由於IIS Worker Process默認會配置Idle Timeout = 20 min，即該進程在20分鐘內沒有任何請求的話就會自動結束，這種情況下ProcDump也會自動結束。需要重新運行命令。因此如果目標程序存在這樣的配置，需要暫時將該配置取消。
• 有些系統管理員希望能夠運行該工具後退出用戶session，ProcDump是做不到的，如果有這種需求可以考慮使用DebugDiag。
• 在調試High CPU問題的時候經常用到的一個命令是!runaway，但是有些時候!runway在ProcDump抓取Dump文件的過程中運行不出來，報錯信息如下：

0:000> !runaway ERROR: !runaway: extension exception 0x80004002. "Unable to get thread times - dumps may not have time information"

解決的方法是將Debugging Tools for Windows (WinDbg)安裝目錄下的dbghelp.dll拷貝到procdump.exe所在目錄下，然後再運行命令抓取Dump。

<strong>四、WinDbg使用方法

操作步驟如下：

<strong>4.1 抓取異常程序的Dump文件

<strong>4.2 設置符號表

符號表是WinDbg關鍵的“數據庫”，如果沒有它，WinDbg基本上就是個廢物，無法分析更多問題。所以使用WinDbg設置符號表，是必須要走的一步。

a、運行WinDbg軟件，然後按【Ctrl+S】彈出符號表設置窗。

b、將符號表地址：<strong>SRV*C:\Symbols*

注：紅色字表示符號表本地存儲路徑，建議固定路徑，可避免符號表重複下載。

<strong>4.3 學會打開第一個Dump文件

當你拿到一個Dump文件後，可使用<strong>【Ctrl+D】快捷鍵來打開一個Dump文件，或者點擊WinDbg界面上的<strong>【File=>Open Crash Dump...】按鈕，來打開一個Dump文件。第一次打開Dump文件時，可能會收到如下提示，出現這個提示時，勾選“Don't ask again in this WinDbg session”，然後點否即可。

當你想打開第二個Dump文件時，可能因為上一個分析記錄未清除，導致無法直接分析下一個Dump文件，此時你可以使用快捷鍵【<strong>Shift+F5】來關閉上一個對Dump文件的分析記錄。

<strong>4.4 通過簡單的幾個命令學會分析Dump文件

<strong>分享一個數據庫連接超時的Dump案例的分析過程：

當你打開一個Dump文件後，可能因為太多信息，讓你無所適從，不過沒關係，我們只需要關注幾個關鍵信息就可以了。

<strong>a. 加載SOS擴展命令

加載SOS之前，先確定SOS的位置和版本，確定方法如下：

如果安裝了Visual Studio，那麼先按照如下步驟打開VS的命令行：

然後，在打開的VS命令行中輸入【where sos.dll】，使獲得SOS的位置和版本：

確定完SOS位置和版本號後，開始加載SOS擴展命令：

.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

如下圖所示：

<strong>b. 使用!clrstack命令來查看當前的調用堆棧信息

如下圖所示：

<strong>c. 使用!dso命令來查看堆棧上的所有對象詳細信息

如下圖所示：

綜合以上分析可以大膽地猜測Common.cs 中第16行“Data Source=***;Initial Catalog=***;Persist Security Info=True;User ID=sa;Password=***”的這個數據庫連接字符串應該有問題，然後到代碼中相應的地方進一步確認和修改就可以了。

<strong>五、一個真實案例

分享筆者工作過的一家公司某業務系統CPU飆高90%以上的Dump分析過程案例，步驟如下：

<strong>5.1 使用ProcDump抓包

<strong>5.2 加載SOS擴展命令

.load C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll

<strong>5.3 分析

執行!runaway命令，查看線程使用CPU時間情況，如下圖所示。著重分析前面幾個線程。

執行~22s命令，進入到線程22，如下圖所示：

執行!clrstack命令查看當前線程堆棧變量值的信息，從圖中可以猜出大概是ExecuteNonQuery()這方法有點問題，如下圖所示：

再執行!dso命令可以查看堆棧上的所有對象詳細信息，如下圖所示：

從圖中看，造成CPU飆高的罪魁禍首多半由SQL Server執行

INSERT INTO [dbo].[tbl_Interface_ProcessLog] (IKey,Username,ClientIP,Module,OrderNo,LogType,Content) VALUES (@IKey,@Username,@ClientIP,@Module,@OrderNo,@LogType,@Content)

這條語句時產生異常引起，然後到源代碼中找出相應的語句，經過進一步的確認、修改和重新發布後就解決了CPU飆高的問題。

至此，掌握幾個簡單的WinDbg命令之後，基本上絕大多數Dump大家都可以獨立分析了。當然WinDbg是個強大的工具，同時產生CPU飆高和內存洩漏的原因也有很多。如果想分析得足夠準確，那麼就只有多學多練，多去分析。因為掌握WinDbg分析除了需要懂得幾個命令之外，經驗更加重要，最後再補充兩點：

1. WinDbg不是專門用於調試.NET程序的工具，它更偏向於底層，可用於內核和驅動調試，特別是對於某些相當疑難的問題調試有所幫助，例如內存洩漏等問題。進行普通的.NET程序調試還是使用微軟專為.NET開發所提供的調試工具更方便一些。
2. SOS擴展命令中最有用的命令是<strong>!help，使用該命令可以列出所有可用的SOS擴展命令列表，使用<strong>!help [SOSCommandName]可以查看每一個具體擴展命令的詳細使用說明。例如!help dumpheap就可以查看!dumpheap這個擴展命令的具體使用方法。多多利用!help命令可以很快上手SOS。

閱讀更多 IT人張飛洪 的文章

關鍵字: 程序運行 診斷 腳本語言