面向.Net程序員的dump分析

背景

　　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能看到更多的底層信息，對於某些特別疑難的問題調試有所幫助，例如內存泄漏等問題。

　　工具下載： WinBdgTool.zip

　　測試代碼下載 ： MyDumpTest.7z

　　首先添加設定符號文件路徑（Symbol Path）,當你使用Visual Studio編譯程序時，是否有留意到在bin/Debug文件夾下會有.pdb後綴的文件？這些文件包含有dll程序集的調試符號，pdb文件並不包含有執行代碼，只是使調試工具能把代碼執行指令翻譯爲正確的可識別字符。微軟提供了包含大量pdb文件的公共服務器，地址以下：http://msdl.microsoft.com/download/symbols。打開windbg程序，選擇「File->Symbol File Path…「，把下面的內容複製進去保存。srv*c:\temp*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 查看這個線程的託管代碼調用棧

　　

　　經過上面咱們已經能夠看出這個線程一直都是處於阻塞狀態。

　　到這裏基本上一個小的測試程序能夠告一段落了，固然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

---

　　本篇先到此 但願對你們有幫助