dump解析入門-用VS解析dump文件進行排障

忽然有一天部署在服務器的一個應用掛掉了，沒辦法只能進入服務器打開

 

 

【事件查看器】查看下，好不容易找到了打開後一臉懵逼

 

 

 

事件查看器查到的內容根本對咱們排障沒有任何做用。

在這個時候若是有對應的dump文件就能派上用場了，

只要有dump文件就能查到應用掛掉那刻的一手情報，可能有人認爲分析dump文件是很是難的事情，

可是最近不斷有新的dump分析工具出來，例如用vs2017就可以很簡單的分析dump文件。

接下來咱們用幾個實際的例子來看看如何用vs2017來分析dump文件吧

 

dump文件的收集

應用掛是一瞬間的事情，掛了以後就沒辦法生成dump文件了。因此首先要設置一下自動生成dump文件。

打開註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting

 

 

 

在Windows Error Reporting下新建一個 LocalDumps文件夾

而後在這項裏面新增 DumpCount DumpFolder DumpType 這三項

 

 

 

演示stackoverflow錯誤致使的crash

咱們有建立一個簡單的console程序

class Program

    {

        static void HogeHoge(string s)

        {

            HogeHoge(s);

        }

        static void Main(string[] args)

        {

            HogeHoge("hoge-");

        }

 }

 

編譯成exe 後運行 毫無疑問會出現以下錯誤

 

 

查看下dump文件果真生成了

 

 

那咱們分析下這個dump文件，用VS2017打開它，會出現它的概要信息

 

 

你會發現異常信息處寫了 【該線程已用完其堆棧】就能夠很明顯看出來是stackoverflow。

並且看右側【操做】處 有[使用 僅限託管 進行調試] 和 [使用 混合 進行調試] 和 [使用 僅限本機 進行調試]

這裏牽扯出3個名詞

託管  ======> 適用於在公共語言運行時下運行的代碼 所謂託管是指內存管理由系統而不是由程序員管理  你們都知道c#有關內存都是CLR來管理的

混合  ======>對託管代碼和非託管代碼都調用調試器

本機  ======>適用於非託管代碼

若是你的代碼裏面沒有調用非託管代碼的話 點擊 前面2個按鈕均可以的

 

點擊後會直接進入

 

 

這樣錯誤源碼級別看的很是清楚了。由於是咱們本機建立的工程 pdb 和 源碼都有。因此才能直接定位到。可是實際上crash都是發生在服務器上，把服務器上的dump文件打開的話還會是這樣嗎

下面咱們來作一個模擬

用Relase編譯 而後把 Program.cs文件也給刪除掉。而後從新執行crash生成dump文件

而後用一樣的步驟vs打開點擊調試就會提示找不到 Program.cs

 

 

這樣一來可供咱們排障的情報就少了不少。在這種狀況下 咱們能夠利用vs 提供的幾個窗口來觀察

分別是如下三個

 

 

第一個窗口：線程窗口

 

 

實際的程序每每有不少線程在運行，每一個線程的切換等重要信息能夠在這個窗口進行觀察。

 

第二個窗口：調用堆棧窗口

 

 

調用堆棧窗口是和線程窗口聯動的。

 

第三個窗口也是最重要的窗口：並行堆棧

 

 

如圖所示，每一個線程和它的堆棧內容展現的很清楚。只不過本例子是比較簡單的，即便不看這個看前2個窗口就能知道緣由了。

可是實際的應用若超過運行上百個線程的話，將這些線程用圖形可視化出來對於咱們排查複雜問題是很是有用的！

 

CPU100和死鎖致使的crash解析

因爲系統能夠配置crash自動生成dump文件。可是有些狀況好比部署在iis上web服務cpu飆到100%下不來致使爲web中止服務。這個時候就須要咱們手動提取dump文件了。

下面咱們來模擬一下這種場景：

新建一個asp.net mvc程序

public class HomeController : Controller
{
    async Task<string> GetAsync()
    {
        var str = await new HttpClient().GetStringAsync("http://www.baidu.com/");
        return str;
    }

    public ActionResult Index()
    {
        var s = GetAsync().Result;
        return View();
    }
}

 

 

以上代碼 async/await會形成死鎖

咱們用iis來啓動這個web應用後頁面圈圈一直在轉網頁空白一片

打開Windows任務管理器找到w3wp

 

 

 

 

 

用vs打開這個dump文件 點擊調試後後

打開並行堆棧這個窗口

 

 

你們看會有不少分支，該從哪一個開始分析呢，教你們一個小技巧，不知道如何下手的時候就選分支越長的！

 

 

從HomeController.Index進來，中止在ManualResetEventSlim.Wait

死鎖緣由：

 

 

 

總結：

說到dump你們立馬可能想到的是windbg

可是windbg的各類命令對於新手們仍是比較困難的，Vs工具也能幫助咱們分析dump，可以解決的問題也有不少

下一篇文章我將介紹內存泄露dump分析的例子

 

出處：https://www.cnblogs.com/yudongdong/p/9687320.html

========================================================================

DebugDiag

獲取dump文件

打開debugdiag後，點擊add Rule，選擇Crash 點擊下一步，而後選擇A specific process 點擊下一步，找到要監聽的進程，點擊下一步；在Action type for unconfigured first chance一欄，選擇Log Stack Trace，而後下面的maximum number...意思是最多建立多少個dump文件，默認10個就好，太多了也分析不過來呀。而後點擊下一步，上面的rule name默認就好，下面的dump文件輸出位置，能夠本身找個位置放好。 再點擊下一步，這裏默認第一個選擇就能夠了，點擊完成就好了。

按上面的步驟，等到程序發生崩潰的時候，就會有dump文件生成了。

分析dump文件

其實我用debugdiag都沒分析出什麼能看懂的結果，仍是用Visual Studio比較直接。

注意

使用工具時，一打開這個軟件個人電腦就會彈出警告，（error collection COM+ infomation.依賴服務或組沒法啓動）， 各類查找後發現是電腦裏COM+ System Application 這個服務未能啓動，並且沒法手動啓動，此時點擊該服務->屬性->依存關係，能夠看到此服務依賴三個服務，挨個在服務裏查找，發現是System Event Notification Service服務設置的禁用，改狀態爲手動，而後啓動它，而後再去啓動COM+ System Application服務，啓動成功，DebugDiag就不會再報錯了。

---

Visual Studio

咱們能夠很方便的利用VS分析dump文件，若是有生成dump文件時對應的.pdb文件，就能夠直接定位到出錯的代碼行。

步驟

一、將.exe和.pdb文件與dump文件放在一個文件夾中，而後在VS中，點擊 文件->打開->文件，選擇dump文件，打開。

二、在解決方案資源管理器右鍵單擊解決方案'Solution0'（這個0會隨着你打開的dump文件而增長，不重要），而後選擇屬性，點擊調試源文件，將項目的源代碼對應的文件路徑添加進去，而後肯定。

三、在工具->選項->調試->常規中，找到「要求源文件與原始版本徹底匹配」這一欄，取消掉勾選，這是由於可能你已經修改過某些地方的代碼了，會致使找不到位置，而只顯示彙編文件的狀況。

四、最後，點擊右側的操做那裏，有個使用 僅限本機 進行調試，就能出結果啦。

水平有限，有什麼不對的但願有大佬指教下，我會改正的。

做者：那些雲
連接：https://www.jianshu.com/p/bfd4a6a3a6d9
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。 

 

出處：https://www.jianshu.com/p/bfd4a6a3a6d9