插播--作業系統Blue Screen 也能Debugging
這星期有點小忙~所以只能趁著休假把該還的幾篇TechEd文章寫一寫。當我正要開始寫的時候(本來系列之3要寫IE 訪問由ASP.NET寫的網頁會Crash，這個問題與Flashget有關)，我的桌機就出現BSOD(Blue Screen On Death)，已經很久沒有碰到過Blue Screen了，當然要趁這個機會來debugging一下。我的桌機是四核心加上8GB的RAM. 執行的作業系統是Windows Server 2008 64 bit的版本。
在系統Crash後，在進階系統設定的啟動及修復選項中，預設是會在%Systemroot% 目錄下產生一個名為 MEMORY.DMP的檔案，下圖是我的設定：
在重新開機後，馬上打開我的WinDbg來debug。 之前在TechEd都是示範如何debug user mode的應用程式，但像這種系統crash的狀況，我們要分析的是Kernel mode的dump。坦白說，如果是單純Crash的話，只要透過一個指令，有70%的機會可以找到答案(別問我70%怎麼來，只是機會真的很高)。產生的dump檔約550MB
在這邊有一點要注意，如果作業系統是X64，建議最好同時安裝32bit 及 64bit的Windbg。原因是，如果您要Debug的是32bit的程式, 就要用32bit的Windbg，如果是64bit的程式或者是系統本身，就要用64bit的Windbg。 如果用錯版本，會有相關的錯誤訊息，而且得到的資訊也會不對。由於我的OS是64bit，因此我就打開64bit的WinDbg, 並把dmp檔直接拖到WinDbg視窗裏：
dump一拖進來後，會先上網下載對應的symbol，所以要等個1~2分鐘。再來介紹一下幾個重要的資訊：
1. Windbg的版本
2. 作業系統資訊
3. 產生dump的時間
4. 這是最重要的啦，就是在先前講到的指令(!analyze -v)，常常透過這個指令就能找到答案，待會再說明。
5. 這個位置，如果是debug user mode dump，會顯示thread ID, 如果是Kernel mode dump，則顯示"Kd"。
好的，其實也不用打指令，我就知道答案了，請看"*"的地方，人家有講可能的原因是來自於一個名為"netr7064.sys"的檔案(其實它是driver)。但還是打個指令看看好了(直接點一下畫面中 !analyze -v的連結也可以)
Driver的東西我是不懂的，但從下面的call stack，也可以看到最後呼叫的module就是netr7064.sys (MS的module先排除)：
您可以看到底下的記憶體位址是8位數`8位數 (這是64bit的記憶體位址表示方法，32只有8位數)。
在顯示結果底下有module相關的訊息：
手移過去後，底下狀態列就會顯示Hyper Link會執行的指令是 "lmvm netr7064"，執行結果如下：
知道了出問題的檔案路徑及檔名，我們就可以上網search 一下這個檔案，發現這是一個wireless card driver的檔案。到我的裝置管理員看一下，證實無誤!
像這類由driver所引發的blue screen, 解決的方法當然是看有沒有新版可以更換(有時候可能需要換回舊版才會正常)，像我是拿Vista X64的driver來裝，用了一陣子沒問題以為沒事，誰知還是遇到了，原先的版本是3.00.2，上網找到3.01.0，更新後果然就沒問題了。
如何? 是不是很簡單呢? 要學會分析dump，第一件事就是......要敢打開來看。雖然我不太懂Driver，但打開來看後，還是有機會可以看出問題原因並解決的。但有一點必須說明，不是所有Kernel mode dump都那麼容易分析的。先前有提到，如果是Crash，而且問題出在device driver或防毒軟體，則可能好解決。如果是系統Hang 或kernel resource 不足或跟page pool有關的Kernel dump，恐怕就沒那麼簡單囉~
