面向.Net程式員的dump分析

標籤：style   blog   http   color   使用   os   strong   檔案   

背景

　　Dump檔案是進程的記憶體鏡像。可以把程式的執行狀態通過調試器儲存到dump檔案中。在 Windows 系統上， dump 檔案分為核心 dump 和使用者態 dump 兩種。前者一般用來分析核心相關的問題，比如驅動程式；後者一般用來分析使用者態程式的問題。

　　一般的程式員可能接觸不到dump檔案，反而是營運會用的多一些。不過如果你抗戰在第一線，學會dump的分析無疑是掌握一柄利器。因為很多情境下，線上下的單元測試或者效能測試中由於測試案例的不充分或者生產於測試環境的硬體以及pv量級的不同等等情況導致問題暴露不出，而在生產環境中又沒有足夠的日誌或者堆棧資訊來指向問題產生的原因。這個時候dump檔案的分析就顯得很有作用。

　　本文分3節 抓取dump以及dump的手動和自動分析。對於初學者自動分析dump是很方便的一種渠道。

一. 抓取dump

　　1. 最簡單的方法 通過工作管理員

　　

　　

　　2. 通過debugdiag

　　debugdiag是一個微軟提供的dump抓取和分析工具。可以建立各種規則在不同的條件下抓取dump，同時具有強大的dump分析功能。

　　：http://www.microsoft.com/en-us/download/details.aspx?id=26798

　　

　　

　　3. Adplus方式

　　運行 cmd ，進入 adplus.exe 檔所在目錄，運行如下命令：
　　單個進程： adplus .exe – hang – p <PID> – o d: ¥
　　多個進程： adplus .exe – hang – p <PID1> -p <PID2> – o d: ¥
　　Mini Dump ： adplus .exe - MiniOnSecond – hang – p <PID> – o d: ¥　

　　抓取方式的選擇：

　　工作管理員的抓取適合dump檔案不大，對應系統硬碟預設存放路徑的空間完全足夠的情況。

　　debugdiag的抓取可以適應多種情況，通過工具的配置來完成。

　　Adplus解決了工作管理員抓取方式的限制，可以處理對應多個進程大檔案的情況。

 二. dump的手動分析

　　工具： winbdg

　　WinDBG不是專門用於調試.Net程式的工具，它更偏向於底層，可用於核心和驅動調試。進行普通的.Net程式調試還是使用微軟專為.Net開發的調試工具MDBG更方便一些。但是WinDBG能看到更多的底層資訊，對於某些特別疑難的問題調試有所協助，例如記憶體流失等問題。

　　測試代碼下載 ： MyDumpTest.7z

　　首先添加設定符號檔案路徑（Symbol Path）,當你使用Visual Studio編譯器時，是否有留意到在bin/Debug檔案夾下會有.pdb尾碼的檔案？這些檔案包含有dll程式集的偵錯符號，pdb檔案並不包含有執行代碼，只是使調試工具能把代碼執行指令翻譯為正確的可識別字元。微軟提供了包含大量pdb檔案的公用伺服器，地址如下：http://msdl.microsoft.com/download/symbols。開啟windbg程式，選擇“File->Symbol File Path…“，把下面的內容複寫進去儲存。srv*d:\debug\symbols*http://msdl.microsoft.com/download/symbols。

　　

　　下面這行命令 如果你發現出現Unable to verify checksum...或者的訊息 那是因為你沒有添加.net的sos擴充或者sos的版本沒有對應上。.Net1.1時代的SOS擴充已經內建於下載安裝的WinDBG中，從.Net2.0以後，SOS擴充已經內建到.Net架構中：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS.dll，為了不至於引起混淆，最好的方法就是使用前面的loadby調試器元命令來讓WinDBG自己決定載入什麼版本的SOS。

　　添加sos：.load C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\sos.dll。

　　載入SOS後，使用命令.chain來查看調試鏈中是否已經成功包含SOS擴充。

　　

　　通過!eeversion查看sos的版本號碼。

　　

　　實戰命令： ~ 查看線程

　　

　　這表明當前dump裡記錄的線程數。如果要切換線程，用波浪線+序號+s來切換，如切換到線程2，那麼用～2s即可。

　　lm 查看你載入的模組

　　

　　kb 查看native code調用棧

　　用~現在只有線程資訊，對於每個線程，在被抓的那一刻，在執行什麼，我們有命令：kb。

　　

　　看到clr大家應該很眼熟吧。這裡已經可以看到較詳細的調試資訊了。

　　!runaway    (查看線程對應 CPU 已耗用時間)

　　

　　因為我們的測試程式是測試的是線程阻塞所以我們選一個已耗用時間為0的，例如415

　　

　　!dso 查看這個堆棧中的對象

　　

　　!clrstack 查看這個線程的Managed 程式碼調用棧

　　

　　通過上面我們已經可以看出這個線程一直都是處於阻塞狀態。

　　到這裡基本上一個小的測試程式可以告一段落了，當然windbg的功能遠遠不止如此，這裡分享一些資源給大家。

　　資源下載 ： WinDbg入門.rar  Windbg用法詳解.7z

 三. dump的自動分析

　　1. debugdiag

　　

　　

　　這裡有幾種規則類型的選擇，一般我們常用的用crash來查看鎖和堵塞的情況，performance來檢查效能的問題。

　　選擇完成後直接點擊開始分析

　　

　　產生報表

　　

　　查看描述

　　

　　點擊詳細

　　

　　這樣，紅色字型就是問題的所在。然後根據具體問題下發到對應開發部門解決。

　　2. Hang自動化分析

　　在WinDbg輸入如下命令

　　.shell -ci "~* kb;.echo MANAGED THREADS;!threads;.echo MANAGED CALLSTACKS;~* e !clrstack;" D:\xx.exe

　　本篇先到此 希望對大家有協助