https://www.qcloud.com/community/article/511817
轉者注：讓我感覺以前看藍屏都白看了~~~原來藍屏也可以分析具體原因。
適用場景：Windows 系列系統異常宕機（藍屏）且存在Dump文件（*.dmp）
相關背景解釋：眾所周知，Windows歷史上BUG比較多，無故宕機、程序卡死的例子較多，為了避免無跡象可循的情況，Microsoft 推出 Dump機制在宕機時先進行藍屏收集宕機前狀態，並且可以捕獲到導致異常的關鍵錯誤，當Windows出現異常Crash時Windows會調用Dump系統來形成一個轉儲文件（*.dmp），通過特殊工具可以進行分析。
如何確保有Dump文件？
1、 要清楚，Dump文件是Windows啟動的一個保險機制，而藍屏主要是用做給系統爭取時間進行收集Dump文件所用，所以一個邏輯是必然會有的，那就是如果藍屏必然觸發Dump機制，Dump機制會根據系統設置進行Mini或Full的收集。
2、 關於Dump文件的大小，如果Dump設置的存放位置不滿足Dump文件大小也是不會產生Dump文件：
a) MiniDump文件大小：取決於Windows 運行時內存頁大小，比如當前CVM跑的是數據庫，那么產生的Dump文件大小就是數據庫交換內存的概要信息，比如說16G內存有20%被使用，宕機時所產生的Dump文件就是3.2g的概要信息（即涉及到的進程的大概地址）
b) FullDump文件大小：取決於Windows物理內存大小，FullDump即完整收集模式，將整個系統在宕機時的整個內存運行態進行記錄，通常該文件的大小是物理大小的1.0 ~ 1.5倍左右（倍數的浮動取決於虛擬內存交換設置的大小）
3、 所以，要確保有Dump文件，最低條件是：
a) 開啟Windows系統的Dump
b) 確保設置的位置剩余空間是物理內存1.5倍以上
c) 若要完整的Dump日志進行分析，請選擇完整收集模式
注1：QCloud Windows Server 2008R2為避免磁盤風險，默認不開啟FullDump模式，所以如果需要詳細Debug文件，則手動開啟即可：
如果您想要啟用完全內存轉儲選項，手動設置為 0x1 以下注冊表子項下的CrashDumpEnabled注冊表項並重新啟動 Windows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
注2：也可以使用Memory Dump Configuration工具進行設置
藍屏文件俗稱BSOD（Blue Screen Of Death），一般出現后處理方式就只有重啟，藍屏的產生原因是：
BSOD有三大規則會觸發：
- 保護規則：當低級特權的代碼直接訪問高級特權代碼與數據時（如某些安全防護軟件通過用戶態進行驅動修改）就會觸發BSOD；
- 異常處理：程序異常時程序本身沒有寫好完整的異常處理回路，系統接收到異常則啟動先行中斷機制，所以程序設計存在問題時也有可能觸發藍屏（比如之前0Day漏洞黑客所用的工具導致藍屏，明顯就是沒有寫好異常處理回路）
- SDK、DDK中調用了只有在特定IRQL調用的內核參數，即只有特定CPU中斷請求的時候才可以使用DDK調用的內核參數在未到中斷請求時被發起調用（一般出現於.Net Winform應用中）
在騰訊雲主機上，一般第一、二規則導致的BSOD Case比較多。
附藍屏產生過程：
轉儲原理：
一、 BSOD分析：
雖然BSOD必然會輸出Dump文件，但是BSOD也會帶來相關有用的信息，一般BSOD呈現方式為：
- 淺藍框：序言、錯誤的信息描述
- 中間部分：建議的措施
- 紅色框：相關中斷的代碼及其參數
關於 淺藍框 跟 中間部分 基本可以忽略，作為排錯需要關注的下面紅色框的參數，下面具體舉個例子：
*STOP：0x0000007F（0xc0000005，0x808945CF，0xF78A6A88，0XF78A6784）
0x0000007F：7F，即導致BSOD的關鍵代碼，通常可以在https://support.microsoft.com/zh-cn/search 可以搜索到
0xc0000005：5，涉及的進程對象（Process Object）
0x808945CF：對應對象的指針（指向位置）
0xF78A6A88：進程涉及的映像名
0XF78A6784：備注解析信息等
二、Dump文件分析
1、 WinDbg工具環境准備，配置好symbol 路徑，使其用相關Debug命令時可以自動加載對應module（Minidump可能信息提供較少）：
2、 設置Path路徑為SRVD:\sysmbolshttp://msdl.microsoft.com/download/symbols 使其在加載相關module（最常見就是NT）時自動從mircosoft 進行下載
Eg：Open Crash Dump時自動加載涉及到的Module：
對應文件夾出現相關Modeule：
3、 打開*.dmp文件：
4、 初始界面如下：
5、 點擊！analyze –v 可以進行自動分析，可以看到這個Dump是因為底層調用netkvm.sys導致crash：
6、 但是大部分Crash並不是如例子所示就可以明確看出涉及的驅動進程，所以可以使用!process [0,0]查看crash時hang住的進程：
7、 通過!thread 可以到進程中涉及的線程信息（可以看到這里是Idel時系統Crash掉）：
8、 如果是系統組件導致的問題的，可以通過lm kv 導出加載的內核模塊：
9、 !vm 可以看出crash時內存狀態（可以看到用戶的 175ptServer.exe 進程占用較高）：
10、 當然也可以通過memory視圖來定位thread hang在什么位置：
11、 WinDbg提供大量其他視圖可以輔助定位原因，可以根據實際case進行靈活使用（比如Disassembly視圖也是很好用的一個功能）：
后言
Windows系統方面的 MiniDump提供信息較少，FullDump在Memory這塊信息會比較多，具體使用方法需要根據具體Case來靈活調整使用。
附常見命令：
（1）進程： !process [0 0]；dt nt!_eprocess；dt nt!_kprocess；
（2）線程： !thread；dt nt!_ethread；dt nt!_kthread；
（3）I/O請求包： dt nt!_irp；!irpfind；
（4）常見同步對象：lkd> dt nt!_kevent；lkd> dt nt!_kmutant；lkd> dt nt!_ksemaphore；
（5）作業：lkd> !job；會話（lkd> !session）；內存管理（lkd> !vm）的命令等。
附件是WinDbg使用指南（English版）