⚡ 本文重點
- 文章屬性:教學實戰
- 適用系統:WinDbg 需 Windows 11 或 Windows 10 1607 以上;傾印檔需為核心、自動、主動或完整記憶體傾印
- 難易度 / 耗時:★★ / 約 20–40 分鐘
- 核心結論:判讀
!devstack輸出時,依官方範例最後一列是匯流排驅動程式建立的 PDO;依官方範例推論,與ServiceName同名的那一列是功能驅動程式,其餘各列是過濾驅動程式。!irp目前堆疊位置的Device位址對到哪一列,問題就落在那一層。 - 適用對象:手上有核心傾印、想知道是哪一層驅動程式出問題的進階使用者與 IT 人員
📌 快速答案
一句話答案:WinDbg !devstack 依裝置物件位址列出整個裝置堆疊,依官方範例最上面是最後附加的裝置物件、最下面是 PDO;先用
!devnode 0 1在裝置樹找到裝置的 PDO 位址,再執行!devstack <PDO 位址>,對照!irp停住的那一列,就知道問題落在哪一層驅動程式。– 需要核心、自動、主動或完整記憶體傾印;小型傾印檔的官方內容清單沒有整個裝置樹,不適用本文流程
🧰 開始前的準備
- 系統需求:WinDbg 支援 Windows 11 各版本與 Windows 10 1607 以上,處理器架構為 x64 與 ARM64。產生傾印檔的電腦,處理器與 Windows 版本不必和分析用的電腦相同;手邊電腦不符合需求時,把傾印檔複製到符合需求的電腦再分析
- 傾印檔類型(先確認再開始):要用核心記憶體傾印、自動記憶體傾印、主動記憶體傾印或完整記憶體傾印,四者預設都寫入
%SystemRoot%\Memory.dmp。%SystemRoot%\Minidump裡的小型傾印檔,官方列出的內容是當機那條執行緒、當機行程與已載入驅動程式清單等資料,沒有列出裝置樹,不適用本文流程 - 權限需求:
%SystemRoot%底下的傾印檔,建議用系統管理員帳戶複製到工作資料夾;之後的分析只需要讀得到那份副本 - 需要工具:WinDbg(官方安裝頁提供安裝檔、Microsoft Store 與
winget install Microsoft.WinDbg三種方式),以及能連上網路的環境(.symfix需要連網下載符號) - 還沒有核心傾印時:電腦卡死但沒有藍屏時不會自動留下傾印,要事先設定強制當機的方式,做法與注意事項見 WinDbg 進階指令教學:用 !process、!irp、!thread 追出卡死的驅動程式與 I/O 請求;系統還能操作時,可改用文末延伸閱讀的 LiveKd 教學分析執行中的核心。這些做法會改動系統設定,不在本文流程內
- 本文流程的範圍:本文的步驟只讀取傾印檔(以 WinDbg 分析副本),不修改任何系統設定
- 預計耗時:約 20–40 分鐘;第一次下載符號檔時,網路慢會更久
- 難度門檻:會在 WinDbg 指令列輸入指令,看過
!analyze -v報告
🔍 為什麼你需要這個?
藍屏報告指出某個驅動程式,但同一個裝置往往由好幾個驅動程式一起處理。依微軟〈Device Nodes and Device Stacks〉,一個 I/O 請求送到裝置時,通常有數個驅動程式參與,每個驅動程式各對應一個裝置物件,這些裝置物件疊成一疊,稱為裝置堆疊。只知道「USB 出問題」不夠,要知道請求停在匯流排驅動程式、功能驅動程式,還是第三方加進來的過濾驅動程式,才知道該更新哪一支、找哪一家廠商。
WinDbg !devstack 回答「這個裝置由哪幾層驅動程式組成」,!devnode 回答「這個裝置在裝置樹的哪裡」。兩個指令都位於 Kdexts.dll;官方〈Extensions for Debugging Plug and Play Drivers〉把 !devnode、!devobj、!drvobj、!irp 列為偵錯隨插即用(PnP)驅動程式時好用的擴充指令。
本文補上站內既有教學沒有涵蓋的「分層」視角,整理成四個重點。
- 裝置樹和裝置堆疊是兩個方向。裝置樹是節點之間的父子關係(匯流排與接在上面的裝置);裝置堆疊是單一節點內部的分層(同一個裝置由哪些驅動程式依序處理)。
!devnode看前者,!devstack看後者。 - PDO 永遠在最底下。官方說明 PDO 是匯流排驅動程式最先建立的裝置物件,之後的裝置物件都附加在既有堆疊的頂端。
!devstack官方範例也是 PDO 那一列排在最後。 !irp和!devstack要一起看。!irp顯示一個 IRP 在各層的堆疊位置與目前停在哪一層;!devstack告訴你那一層的裝置物件屬於哪一支驅動程式、上下各是誰。微軟對停止碼 0x9F 參數 1 為 0x3 的除錯步驟,就是先用!irp看被擋住的 IRP,再用!devstack看 PDO 所在的堆疊。!devnode的位址參數說法要留意。官方參數說明寫成「device extension 的位址」,但官方範例帶入的都是輸出中DevNode後面的位址;本文一律使用DevNode位址或 0。
📖 裝置樹與裝置堆疊是什麼?
裝置樹是 Windows 用來表示所有裝置的樹狀結構,每個節點稱為裝置節點(device node);每個裝置節點各有一個裝置堆疊,也就是依序排列的(裝置物件,驅動程式)組合。依微軟文件,裝置樹的節點通常代表一個裝置或複合裝置的一個功能,也有節點代表與實體裝置無關的軟體元件;根節點稱為根裝置節點。開機時,PnP 管理員會要求各匯流排驅動程式列舉接在上面的子裝置,這些子裝置就成為該匯流排節點的子節點。
| 裝置物件 | 由誰建立 | 在堆疊中的位置與角色 |
|---|---|---|
| PDO(physical device object) | 匯流排驅動程式,在列舉子裝置時建立 | 永遠在最底下;建立 PDO 的驅動程式稱為這個節點的匯流排驅動程式 |
| FDO(functional device object) | 功能驅動程式 | 每個堆疊有且只有一個功能驅動程式,負責處理讀取、寫入與裝置控制請求 |
| Filter DO(filter device object) | 過濾驅動程式 | 可以沒有,也可以有好幾個;在功能驅動程式上面的稱為上層過濾驅動程式,在下面的稱為下層過濾驅動程式 |
- 堆疊有頂端與底端:最先建立的裝置物件在最下面,最後建立並附加的在最上面。
- 同一支驅動程式可以身兼兩種角色。官方以 Pci.sys 為例,它是 PCI 匯流排節點的功能驅動程式,也是接在 PCI 匯流排上各子裝置的匯流排驅動程式。
- 安裝驅動程式時,安裝程式依 INF 檔決定哪一支是功能驅動程式、哪幾支是過濾驅動程式;安裝完成後,PnP 管理員從登錄找出各裝置的功能與過濾驅動程式。
- 除了核心模式的裝置堆疊,有些裝置另有以 UMDF 驅動程式組成的使用者模式裝置堆疊,其中的裝置物件是實作 IWDFDevice 的 COM 物件;
!devstack的參數是 DEVICE_OBJECT 結構,據此推論它列出的是核心模式那一疊。
I/O 請求從堆疊頂端往下走。依微軟〈I/O Request Packets〉,堆疊處理 IRP 時,IRP 通常先送到最上面的裝置物件,每一層處理後交給下一層;有些 IRP 會一路傳到 PDO,有些在 PDO 之前就被上面某一層完成。
📖 WinDbg !devnode 列裝置樹:語法與參數
WinDbg !devnode 的語法是 !devnode Address [Flags] [Service],Address 填 0 時顯示主裝置樹的根;官方說明用 !devnode 0 1 可以看到整個裝置樹。
!devnode Address [Flags] [Service]| 參數 | 作用(依官方參考頁) |
|---|---|
Address | 要顯示的節點位址;填 0 顯示主裝置樹的根 |
Flags 0x1 | 一併顯示這個節點的所有子節點 |
Flags 0x2 | 顯示使用中的資源(CM_RESOURCE_LIST) |
Flags 0x4 | 顯示需求的資源(IO_RESOURCE_REQUIREMENTS_LIST) |
Flags 0x8 | 顯示轉譯後的已配置資源 |
Flags 0x10 | 只顯示尚未啟動的裝置節點 |
Flags 0x20 | 只顯示有問題的裝置節點(帶有 DNF_HAS_PROBLEM 或 DNF_HAS_PRIVATE_PROBLEM 旗標) |
Service | 只顯示由這個服務驅動的裝置節點;Flags 含 0x1 時連同它們的子節點 |
- Flags 的位元可以任意組合,例如官方〈Determining the Status of a Device〉範例用
!devnode <位址> 6同時看使用中與需求的資源。 Address的官方說明寫成「device extension 的位址」,但官方範例帶入的是DevNode後面的位址;要查某個節點時,用!devnode 0 1輸出或!devobj輸出中標示的DevNode位址。!devnode 1列出所有等待中的裝置物件移除作業,!devnode 2列出所有等待中的退出作業。
每個裝置節點的輸出,第一行是 DevNode <位址> for PDO <位址>,接著是 InstancePath(裝置執行個體路徑)、ServiceName(驅動這個節點的服務)、State 與 Flags。官方 Echo 範例驅動程式教學的一段輸出如下:
0: Kd> !devnode 0 1 echo
Dumping IopRootDeviceNode (= 0xffffe0007b725d30)
DevNode 0xffffe0007b71a630 for PDO 0xffffe0007b71a960
InstancePath is "ROOT\SAMPLE\0000"
ServiceName is "ECHO"
State = DeviceNodeStarted (0x308)📖 WinDbg !devstack 用法:語法與輸出
WinDbg !devstack 的語法是 !devstack DeviceObject,參數可以是 DEVICE_OBJECT 結構的十六進位位址,也可以是裝置名稱;只給名稱而沒有前綴時,會自動加上 \Device\。它顯示的是與這個裝置物件相關的裝置堆疊。
!devstack DeviceObject官方 Echo 範例中,對 !devnode 找到的 PDO 執行 !devstack,得到只有兩層的堆疊。
0: kd> !devstack 0xffffe0007b71a960
!DevObj !DrvObj !DevExt ObjectName
ffffe000801fee20 \Driver\ECHO ffffe0007f72eff0
> ffffe0007b71a960 \Driver\PnpManager 00000000 0000000e
!DevNode ffffe0007b71a630 :
DeviceInst is "ROOT\SAMPLE\0000"
ServiceName is "ECHO"| 輸出內容 | 意思 |
|---|---|
!DevObj 欄 | 裝置物件位址,可以帶進 !devobj 看細節 |
!DrvObj 欄 | 擁有這個裝置物件的驅動程式物件名稱,可以帶進 !drvobj |
!DevExt 欄 | 裝置擴充(device extension)位址 |
ObjectName 欄 | 裝置物件的名稱;沒有名稱時可能空白,偵錯器讀不到物件標頭時也可能顯示錯誤訊息(如官方 0x9F 範例) |
行首 > | 官方範例中標在執行指令時帶入的那個裝置物件 |
!DevNode 段落 | 這個堆疊所屬的裝置節點,含 DeviceInst 與 ServiceName |
- 列表由上往下,對應堆疊由頂端到底端。依據是官方說明 PDO 永遠在最底下,而官方範例中帶入的 PDO 正好是最後一列。
- Echo 範例只有兩層:上面是
\Driver\ECHO,下面是\Driver\PnpManager建立的 PDO;官方說明這是相當簡單的驅動程式堆疊,echo 驅動程式是 PnPManager 節點的子節點。 ServiceName是驅動這個節點的服務;Echo 範例中它是ECHO,正好是 PDO 上面那一列的驅動程式。
🛠️ 實戰步驟
本文的步驟只讀取傾印檔(以 WinDbg 分析副本),不修改任何系統設定。步驟一到三是準備工作,步驟四到六是找出問題所在那一層的主流程。
步驟一:確認傾印檔類型,複製一份再用 WinDbg 開啟
先確認手上是核心、自動、主動或完整記憶體傾印,再複製一份到工作資料夾開啟。這四種傾印預設都寫在 %SystemRoot%\Memory.dmp;核心記憶體傾印的官方說明寫到,再發生一次錯誤檢查時舊檔會被覆寫,分析前先複製一份比較保險。檔案來自 %SystemRoot%\Minidump 的是小型傾印檔,遇到它,或無法確認是上述四種傾印時,就停在這一步,改用「開始前的準備」提到的方式取得核心傾印。
在 WinDbg 按 Ctrl+D(Open dump file)選擇副本即可開啟;也可以從命令列執行 WinDbgX,用 -z 參數指定傾印檔,路徑含空白時要加引號。
WinDbgX -z D:\dumps\Memory.dmp步驟二:設定符號路徑
先執行 .symfix 把符號路徑指向微軟符號伺服器,再用 .reload 重新載入。核心模式除錯需要 Windows 公用符號,.symfix 需要偵錯器執行時能連上網路。符號路徑的完整設定與常見問題,見文末延伸閱讀的符號路徑教學。
.symfix
.reload步驟三:用 !analyze -v 找出起點
執行 !analyze -v,先看停止碼的參數裡有沒有直接給出裝置物件位址。有的停止碼會把裝置物件放在參數中,這時可以跳過步驟四,直接拿那個位址做步驟五。
!analyze -v- 停止碼是 0x9F DRIVER_POWER_STATE_FAILURE、參數 1 為 0x3:依官方參數表,參數 2 是堆疊的 PDO、參數 4 是被擋住的 IRP。官方除錯步驟是對參數 4 執行
!irp、對參數 2 執行!devstack,直接進入步驟五。0x9F 的完整處理流程見 DRIVER_POWER_STATE_FAILURE(0x9F)教學。 - 停止碼是 0x35 NO_MORE_IRP_STACK_LOCATIONS:先依 NO_MORE_IRP_STACK_LOCATIONS(0x35)教學 讀出 IRP 的堆疊位置;要確認那個裝置的堆疊有哪幾層時,回到步驟四。
- 報告中只有驅動程式名稱、沒有裝置物件位址時,進入步驟四,從裝置樹找出那個驅動程式負責的裝置。
步驟四:用 !devnode 在裝置樹找到裝置節點與 PDO
依手上的線索選一種寫法,從輸出中記下 DevNode 與 for PDO 後面的兩個位址。
!devnode 0 1
!devnode 0 1 <服務名稱>
!devnode 0 21- 已知驅動程式的服務名稱(步驟三報告中的模組名稱通常是線索):用第二行,官方 Echo 範例即是
!devnode 0 1 echo。 - 想找有問題的裝置:依參數說明,把 0x20(只顯示有問題的節點)與 0x1(含子節點)組合成 0x21,從根開始列出帶有 DNF_HAS_PROBLEM 或 DNF_HAS_PRIVATE_PROBLEM 的節點。
- 什麼線索都沒有:用第一行列出整個裝置樹,輸出很長,官方教學的做法是用 Ctrl+F 搜尋驅動程式名稱。
- 只有驅動程式名稱、
!devnode帶服務名稱卻找不到節點時,改用!drvobj <驅動程式名稱>,它會列出這支驅動程式建立的所有裝置物件。同一支驅動程式可能在不同節點各建立裝置物件,所以要逐一帶進步驟五,找出!DevNode段落屬於目標裝置的那一個。
找到節點後,看 Flags 一行。官方〈Device Node Status Flags〉列出的旗標中,DNF_HAS_PROBLEM 代表裝置有問題、將被移除,DNF_DRIVER_BLOCKED 代表這個節點有驅動程式被阻擋載入。
步驟五:用 !devstack 列出那個裝置的整個堆疊
對步驟三或步驟四拿到的 PDO 位址執行 !devstack,由上往下抄下每一列的驅動程式名稱。
!devstack 0xffffe0007b71a960上面這行是官方 Echo 範例的位址,請換成自己傾印中的位址。手上是裝置名稱,或 !drvobj 列出的裝置物件位址,也可以直接帶入,!devstack 列出的是與它相關的裝置堆疊;官方兩個範例中,行首 > 都標在帶入的那一列。
依官方說明的建構順序(PDO 最先建立、每個堆疊有且只有一個功能驅動程式),輸出可以歸成三種角色。
- 最後一列是 PDO,
!DrvObj欄是匯流排驅動程式(Echo 範例是\Driver\PnpManager)。 !DevNode段落的ServiceName是驅動這個節點的服務。官方 Echo 範例的ECHO與 0x9F 範例的HidUsb,都正好是 PDO 上面那一列的驅動程式;據此推論,在列表中找到與ServiceName同名的那一列,就是功能驅動程式的 FDO。- 其他列是過濾驅動程式:在 FDO 上面的是上層過濾驅動程式,在 PDO 與 FDO 之間的是下層過濾驅動程式。
想確認某一層的上下鄰居,可以對該列的 !DevObj 位址執行 !devobj,官方說明輸出中的 AttachedDevice 是疊在它上面的裝置物件,AttachedTo 是它下面的裝置物件。
步驟六:對照 IRP 停在哪一列,定位出問題的那一層
有被擋住的 IRP 位址時(例如 0x9F 參數 4),執行 !irp <位址>,找出行首標了 > 的目前堆疊位置,記下那一筆的 Device 欄位址與驅動程式名稱,再到步驟五的列表中找出 !DevObj 相同的那一列。
!irp fffffa800ab61bd0
!devstack fffffa8007b13440以官方 0x9F 範例來看:!irp 顯示 IRP 共有 7 個堆疊位置、第 6 個是目前位置,標 > 的那一筆是 IRP_MJ_POWER、IRP_MN_SET_POWER,狀態為 pending,Device 欄是 fffffa800783f060,驅動程式是 \Driver\HidUsb;!devstack 對參數 2 的 PDO 列出兩層,上面那一列的 !DevObj 同樣是 fffffa800783f060、屬於 \Driver\HidUsb,下面標 > 的 PDO 屬於 \Driver\usbhub,ServiceName 是 HidUsb。對照兩邊可以看出,電源 IRP 停在 HidUsb 這一層;依步驟五的推論,它是這個裝置的功能驅動程式,底下建立 PDO 的匯流排驅動程式是 usbhub。
驗證方式:!irp 目前堆疊位置的 Device 位址,必須出現在 !devstack 列表的 !DevObj 欄,而且你能說出那一列在堆疊中的角色(PDO、FDO 或過濾驅動程式)。對不上時,代表帶入的 PDO 不是這個 IRP 所屬的裝置,回到步驟四重新確認節點。確認那一層之後,記下驅動程式名稱,查它的版本與廠商(做法見延伸閱讀的 lmvm 教學),再把傾印與這些資訊交給該驅動程式的廠商,或確認是否有更新版本。
沒有 IRP 可以對照時,步驟五的分層結果就是線索清單:!analyze -v 指出的模組在堆疊中屬於哪一種角色、同一個堆疊裡還有哪些第三方過濾驅動程式,都要列入追查。
🔬 底層機制:為什麼同一個裝置會有好幾層驅動程式?
裝置堆疊是 PnP 管理員在開機列舉時一層層疊出來的。依微軟〈Device Nodes and Device Stacks〉,PnP 管理員要求匯流排驅動程式列舉子裝置,匯流排驅動程式為每個子裝置建立 PDO;PnP 管理員為每個新的 PDO 關聯一個裝置節點,再查登錄決定這個節點的堆疊要有哪些驅動程式。功能驅動程式與過濾驅動程式載入時,各自建立裝置物件並附加到堆疊上。
附加的順序決定了上下位置。PDO 最先建立,之後的裝置物件都附加在既有堆疊的頂端,所以 PDO 永遠在最底下。過濾驅動程式依它在功能驅動程式之上或之下附加,分成上層與下層過濾驅動程式。
請求由上往下流,所以每一層都可能是卡住的地方。依〈I/O Request Packets〉,IRP 通常先送到堆疊最上面的裝置物件,每一層的驅動程式處理後再交給下一層;有些 IRP 一路傳到 PDO,有些在中途被某一層完成。據此推論,請求停在某一層而遲遲沒有完成時,那一層的驅動程式就是首要嫌疑,而 !irp 標出的目前堆疊位置正是用來指出這一層。
裝置節點的旗標記錄了 PnP 管理員看到的狀態。官方〈Device Node Status Flags〉列出的 DNF_NO_UPPER_DEVICE_FILTERS、DNF_NO_LOWER_CLASS_FILTERS 等旗標,表示登錄中沒有對應類型的過濾驅動程式項目;DNF_LEGACY_DRIVER 表示控制這個裝置的是非 PnP 驅動程式。
💡 總結:進階玩法與底層邏輯
WinDbg !devnode 找位置,!devstack 看分層,!irp 指出停在哪一層。固定順序是 !analyze -v 看參數有沒有裝置物件、!devnode 找節點與 PDO、!devstack 列出整疊驅動程式、!irp 對照目前堆疊位置,最後說出那一層的角色與驅動程式名稱。
資源衝突與尚未啟動的裝置另有旗標可用。!devnode 的 0x2、0x4、0x8 旗標可以看資源配置,0x10 只列尚未啟動的節點;官方〈Determining the Status of a Device〉示範了一個因資源不足而沒有啟動的節點,它有資源需求清單、卻沒有使用中的資源清單。
不適用的情況也要先知道。只有小型傾印檔時,官方內容清單沒有整個裝置樹;卡死的原因在鎖或執行緒等待時,要改用 !process、!thread 這一類指令,見前面提到的卡死追查教學;依前面的推論,!devstack 看的是核心模式堆疊,UMDF 驅動程式所在的使用者模式堆疊不在其中。
本文依 Microsoft Learn 的 !devnode、!devstack、!devobj、!drvobj、!irp 參考頁、Device Nodes and Device Stacks、I/O Request Packets、Bug Check 0x9F 與 Echo 偵錯實驗等文件整理,2026-10-01 查證。
❓ 常見問題
Q:裝置樹跟裝置堆疊差在哪?
裝置樹描述裝置之間的父子關係,裝置堆疊描述單一裝置內部的分層。裝置樹的節點是裝置或匯流排,例如 PCI 匯流排節點底下接著 USB 主控制器、音訊控制器等子節點;每個節點各有一個裝置堆疊,由 PDO、FDO 與過濾驅動程式的裝置物件依序疊成。WinDbg 用 !devnode 看裝置樹,用 !devstack 看單一節點的裝置堆疊。
Q:怎麼知道是哪一層驅動程式出問題?
先用 !devstack 列出整個堆疊並分出角色:最後一列是 PDO,依官方範例推論與 ServiceName 同名的那一列是功能驅動程式,其餘是過濾驅動程式。再用 !irp 看被擋住的 IRP,行首 > 標出目前堆疊位置,用那一筆的 Device 位址對回 !devstack 的 !DevObj 欄,對到的那一列就是請求停住的那一層;沒有 IRP 可以對照時,把 !analyze -v 指出的模組放回堆疊中,看它屬於哪一種角色。
Q:!devstack 跟 !irp 追 I/O 差在哪?
!irp 從一個請求出發,列出這個 IRP 在每一層的堆疊位置、目前停在哪一層,以及各層設定的完成常式;!devstack 從一個裝置物件出發,列出這個裝置由哪些驅動程式依序組成。前者回答「請求走到哪裡」,後者回答「那裡是誰」。官方處理停止碼 0x9F 參數 1 為 0x3 時,就是兩個指令一起用。
Q:小型傾印檔可以用 !devnode 和 !devstack 嗎?
不建議。依官方說明,小型傾印檔收錄的是錯誤檢查訊息與參數、當機那顆處理器的 PRCB、當機行程的 EPROCESS、當機執行緒的 ETHREAD 與核心堆疊、已載入驅動程式清單等,另加 Windows 判斷有用的額外記憶體頁,清單中沒有整個裝置樹;官方也提醒,不是由當機當下那條執行緒直接造成的錯誤,可能無法從這種檔案分析出來。要改用核心、自動、主動或完整記憶體傾印。
Q:!devnode 的位址要填什麼?
填 0 表示從裝置樹的根開始。要查單一節點時,用 !devnode 0 1 輸出中 DevNode 後面的位址,或 !devobj 輸出中 DevNode 欄的位址;官方範例都是這樣帶入。參數說明雖然寫成「device extension 的位址」,本文流程不需要用到 device extension。
Q:這個方法在舊版本也適用嗎?
要分兩台電腦看。分析用的電腦要符合 WinDbg 的需求,也就是 Windows 11 各版本或 Windows 10 1607 以上;產生傾印檔的電腦,處理器與 Windows 版本不必相同。!devnode 與 !devstack 的官方參考頁沒有列出版本限制;部分官方範例的位址只有 8 位十六進位(如〈Determining the Status of a Device〉的 0xff0d06e8),x64 系統的位址較長(如 Echo 範例的 0xffffe0007b71a960)。依官方說明,較舊版本 Windows 的傾印,可以改用 Debugging Tools for Windows 內的 WinDbg (classic)。
🔗 延伸閱讀
- WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告,搞懂 STACK_TEXT 與 FAILURE_BUCKET_ID
- WinDbg lmvm 教學:一行指令看懂當機驅動模組與版本資訊
- WinDbg Preview 安裝與符號路徑設定完整教學
- LiveKd 教學:不必真的當機,用 WinDbg 分析正在執行中的 Windows 核心
- 裝置管理員錯誤碼完整解析:Code 10、28、31、43 分別代表什麼?
📎 參考資料來源
📖 第一級|廠商官方:
- !devnode(Microsoft Learn) — 2026-10-01 查證
- !devstack(Microsoft Learn) — 2026-10-01 查證
- !devobj(Microsoft Learn) — 2026-10-01 查證
- !drvobj(Microsoft Learn) — 2026-10-01 查證
- !irp(Microsoft Learn) — 2026-10-01 查證
- Device Nodes and Device Stacks(Microsoft Learn) — 2026-10-01 查證
- I/O Request Packets(Microsoft Learn) — 2026-10-01 查證
- Extensions for Debugging Plug and Play Drivers(Microsoft Learn) — 2026-10-01 查證
- Determining the Status of a Device(Microsoft Learn) — 2026-10-01 查證
- Device Node Status Flags(Microsoft Learn) — 2026-10-01 查證
- Debug Windows Drivers Step-By-Step Lab (Echo Kernel Mode)(Microsoft Learn) — 2026-10-01 查證
- Bug Check 0x9F DRIVER_POWER_STATE_FAILURE(Microsoft Learn) — 2026-10-01 查證
- Small Memory Dump(Microsoft Learn) — 2026-10-01 查證
- Kernel Memory Dump(Microsoft Learn) — 2026-10-01 查證
- Automatic Memory Dump(Microsoft Learn) — 2026-10-01 查證
- Active Memory Dump(Microsoft Learn) — 2026-10-01 查證
- Complete Memory Dump(Microsoft Learn) — 2026-10-01 查證
- Install WinDbg(Microsoft Learn) — 2026-10-01 查證
- Analyze a Kernel-Mode Dump File by Using WinDbg(Microsoft Learn) — 2026-10-01 查證
- WinDbg keyboard shortcuts(Microsoft Learn) — 2026-10-01 查證
- WinDbg: Command-line startup options(Microsoft Learn) — 2026-10-01 查證
- Symbols for Windows debugging(Microsoft Learn) — 2026-10-01 查證
- .symfix (Set Symbol Store Path)(Microsoft Learn) — 2026-10-01 查證
⚠️ 本文核心事實以第一級為準。!devnode 參考頁對 Address 參數的說明(device extension 的位址)與官方範例帶入 DevNode 位址的做法不一致,已於正文揭露;部分官方範例為 32 位元系統的輸出。
📅 本文查證戳記:2026-10-01 依據 Microsoft Learn 之 !devnode、!devstack 參考頁與裝置堆疊、傾印檔相關文件查證撰寫,內容整理自官方文件,未在實機上執行。
若你的
!devstack輸出欄位與本文範例不同,歡迎在留言區附上 WinDbg 版本回報。