久違的又是分享 Dump 如何分析的文章，可想而知這又是最近在工作上受盡苦難，經歷無數個被客戶追殺的日子後，所集成的嘔心瀝血之作。預計分成兩篇，本篇是當你很確定問題出在哪個 driver 時可以使用的方式，下篇則是當你不知道問題出在哪個 driver 時的分析方式。
這兩篇內容滿滿乾貨完全不摻一滴水 (就算有摻到，那也是我的淚水 😢)，希望能幫助到同樣正在受 BSOD 折磨的工程師。
首先， analyze -v永遠是分析 dump 的第一步:
BSOD 的 error code 是 0xcb ，首先先去查詢微軟提供的官方文件關於 0xcb 的描述，從文件中可以得知當驅動程式或 i/o 管理員無法釋放鎖定頁面所導致的，此外也提供了帶的參數可能代表的意義，以便做後續分析。
看到上面的描述，通常直覺會想到先 unassemble Arg1 去看一下這個位址裡面放的資料是什麼
不幸地，這個例子似乎一點幫助都沒有，檢查了 rax, al 也都是空的
繼續往下滑到 stack text 的欄位，看到一堆跟 windows delete 或是 dereference 相關的 API，目前只能猜測問題應該是發生在系統 terminate process 打算清理資源時發現有一塊記憶體被 lock 住無法被釋放而導致的。
那我們要怎麼找出是哪個 driver 忘記去 unlock page 呢 ?
開頭有提到本篇是針對你很確定這個問題來自於哪個 driver 的分析方式，如果這符合你的情況就繼續看下去吧！
接下來的步驟可以幫助你快速找出 driver 有 import 的 API，並從中挑出潛在有可能造成 lock 的部分，當有了目標後你就可以去 driver code 搜尋這些可疑的 API 是否有某些情境可能導致資源並沒有獲得釋放。
Step1. 倒出 driver 的 PE Header
Step2. 找到 IAT (Import Addres Table) 的記憶體位址
Import Address Table 放的是從外部 import 進來的函式位址，簡單來說如果你的程式內有使用到 Windows DLL 提供的 API，那些 API 的 address 就會被放入 IAT 內。
在 OPTIONAL HEADER VALUES 的欄位內，你可以在開頭附近找到 image 的 base address ，再往下滑一點點可以找到 Import Address Table Directory的 virtual address。
下圖中的 10000 代表的是 IAT 相對於 base address 的 offset，而 3d0 則是 IAT 的大小。
Step3. 倒出 IAT 的完整內容
透過 IAT 的內容可以知道當前 driver import 過什麼 API，藉由 function name 與關鍵字 ( e.g lock ) 去做搜尋比對，推測出哪些 API 比較有可能跟目前碰到的 lock page 相關，幫助縮小後續的搜尋範圍。
當你鎖定了幾個特定的 API ，例如 MmProbeAndLockPages ( 看名稱就有滿大機率跟 lock page 有關 )，接下來就是土法煉鋼的進去 trace code 檢查看看使用這些 API 的地方會不會哪邊沒處理好導致資源沒釋放最終造成 BSOD。
下一篇的方式則是針對不知道造成問題的人是誰時使用的方式，預計一周內可以完成，有興趣的人等發布後再回來看吧 ! 😃
[2022/12/28 更新] 下篇已出 😃 😃 😃
