⚡ 本文重點
- 文章屬性:教學實戰
- 適用系統:WinDbg 需 Windows 11 或 Windows 10 1607 以上;傾印檔須來自 Windows Server 2003 以後的版本;數值對照限 x86、x64
- 難易度 / 耗時:★★ / 約 10–20 分鐘
- 核心結論:
!irql只回答當機前一刻處在哪一層,不回答誰造成當機;沒有參數 2 佐證的 DISPATCH_LEVEL 只當旁證,0xA、0xD1 回到參數 1、3、4 找責任驅動,其他停止碼以!analyze -v為主。 - 適用對象:看過
!analyze -v報告、想弄懂 IRQL 藍屏的進階使用者與 IT 人員
📌 快速答案
一句話答案:WinDbg !irql 顯示處理器在當機前一刻保存的中斷請求層級(IRQL),開啟傾印檔、設好符號後輸入
!irql,從括號內的名稱判讀當時處在哪一層;顯示 DISPATCH_LEVEL 時可能受偵錯器中斷或錯誤檢查影響,0xA、0xD1 可再和參數 2(當時的 IRQL)比對。–
!pcr顯示的是目前 IRQL,官方說明這個值通常沒有參考價值,判讀以!irql為準
🧰 開始前的準備
- 系統需求:WinDbg 支援 Windows 11 各版本與 Windows 10 1607 以上,處理器架構為 x64 與 ARM64。產生傾印檔的電腦,處理器與 Windows 版本不必和分析用的電腦相同;手邊電腦不符合需求時,把傾印檔複製到符合需求的電腦再分析
- 傾印檔來源:
!irql只支援 Windows Server 2003 以後的 Windows,Windows 2000 與 Windows XP 產生的傾印檔無法使用,只能改看停止碼參數(見步驟三) - 權限需求:
%SystemRoot%底下的傾印檔,建議用系統管理員帳戶複製到工作資料夾;分析本身只需要讀得到那份副本 - 需要工具:WinDbg(官方安裝頁提供安裝檔、Microsoft Store 與
winget install Microsoft.WinDbg三種方式),以及能連上微軟公用符號伺服器的網路 - 要分析的檔案:核心記憶體傾印(預設寫入
%SystemRoot%\Memory.dmp)或%SystemRoot%\Minidump裡的小型傾印檔;要逐顆檢查處理器時選核心記憶體傾印,原因見步驟一 - 預計耗時:約 10–20 分鐘;第一次下載符號檔時,網路慢會更久
- 難度門檻:會在 WinDbg 指令列輸入指令,看得懂
!analyze -v報告中的停止碼與參數
🔍 為什麼你需要這個?
藍屏出現 IRQL_NOT_LESS_OR_EQUAL(0xA)或 DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)時,停止碼名稱就帶著 IRQL,!analyze -v 報告也會列出當時的 IRQL 值,但這個值怎麼直接讀、讀出來的名稱代表什麼,要另外查好幾份文件。WinDbg !irql 補的就是這一段:依微軟文件,它顯示目標電腦處理器在偵錯器中斷前的 IRQL;分析當機傾印檔時,讀到的是錯誤檢查(bug check)發生前一刻保存的 IRQL。兩個停止碼各自的排錯流程,可以參考 IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復 與 DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)藍屏怎麼修?。
這個指令的官方參考頁只有一頁,判讀要用到的細節散在錯誤檢查、驅動程式 IRQL 規則與傾印檔等多份文件;整理起來,!irql 的輸出要搭配停止碼參數與處理器架構一起看,才不會誤判。
!irql讀的是當機前一刻的值。官方說明,錯誤檢查發生並產生傾印檔時,檔案保存的是錯誤檢查前一刻的 IRQL,不是KeBugCheckEx執行時的 IRQL。!pcr也會顯示 IRQL,但那是目前 IRQL,官方說明這個值通常沒有參考價值,而且!pcr的頁面標示這個指令目前不支援、輸出可能不正確。- DISPATCH_LEVEL 不一定是當機前的真實層級。官方寫到,偵錯器中斷與錯誤檢查這兩種情況,除了 x86 以外,目前 IRQL 都會被提高到 DISPATCH_LEVEL;這類事件發生不只一次時,
!irql顯示的也會是 DISPATCH_LEVEL,結果就失去除錯價值。看到 DISPATCH_LEVEL,最好再和停止碼參數比對。 - 同一個數字在不同架構代表不同層級。官方的 x86 範例輸出
28 (CLOCK2_LEVEL),x64 範例輸出12 (SYNCH_LEVEL),並註明 IRQL 數字的意義常隨處理器而不同。判讀時看括號內的名稱,不要只背數字。 - 以 0xD1 來說,要查的多半是記憶體。0xD1 的官方說明寫到,這類錯誤檢查多數情況要查的是被存取的那塊記憶體,IRQL 的高低本身通常不是問題所在。
!irql用來確認當機時處在哪一層,要找責任驅動,還是得回到參數 1、3、4。
📖 什麼是中斷請求層級(IRQL)?
中斷請求層級(Interrupt Request Level,IRQL)是 Windows 為中斷排定的優先順序,處理器處在某個 IRQL 時,同級與較低層級的中斷會被擋下,更高層級的中斷仍能插進來。微軟驅動程式文件說明,IRQL 是 0 到 31 的整數,PASSIVE_LEVEL、APC_LEVEL、DISPATCH_LEVEL 通常直接用名稱稱呼,其餘層級用數值,這些值定義在 WDK 的 Wdm.h。IRQL 以處理器為單位,所以 !irql 的參數是處理器編號。
| 層級(由低到高) | 這一層擋下的中斷 | 常在這一層執行的驅動常式 | 能否存取分頁記憶體 |
|---|---|---|---|
| PASSIVE_LEVEL | 無 | DriverEntry、AddDevice、Unload、多數分派常式、驅動建立的執行緒 | 可以 |
| APC_LEVEL | APC 中斷 | 部分分派常式 | 可以 |
| DISPATCH_LEVEL | DISPATCH_LEVEL 與 APC 中斷 | StartIo、DpcForIsr、CustomDpc、IoTimer | 不可以 |
| DIRQL(裝置層級) | 小於等於該驅動中斷物件 DIRQL 的所有中斷 | 中斷服務常式(ISR)、SynchCritSection | 不可以 |
- 官方寫明,執行在高於 APC_LEVEL 的常式,不能安全地配置或存取分頁集區(paged pool)記憶體;在這種層級引發分頁錯誤,就是致命錯誤。
- APC_LEVEL 和 PASSIVE_LEVEL 的唯一差別是收不到 APC 中斷,兩者都代表有執行緒內容,程式碼也可以被分頁出去。
- 處理器在 DISPATCH_LEVEL 時,裝置、時鐘與電源失效中斷仍然可能發生。
- 微軟封存部落格〈What is IRQL?〉說明,NT 的自旋鎖預設都在 DISPATCH_LEVEL;程式把 IRQL 提高到 DISPATCH_LEVEL,就等於停掉這顆處理器的執行緒分派器(dispatcher)。
📖 WinDbg !irql 指令語法與參數
!irql 只有一個選用參數,也就是處理器編號;省略時顯示目前處理器的 IRQL。
!irql [Processor]這個擴充指令放在 Kdexts.dll,官方頁面標示只支援 Windows Server 2003 以後的 Windows。0xD1 官方說明的範例輸出如下方程式碼區塊,0x0 是十六進位的處理器編號,2 是 IRQL 數值,括號內是層級名稱。
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)| 指令 | 顯示內容 | 使用時機 |
|---|---|---|
!irql | 目前處理器在偵錯器中斷或錯誤檢查前保存的 IRQL | 判斷當機時處在哪一層 |
!irql 1 | 指定處理器(此例為 1 號)保存的 IRQL | 多處理器傾印要逐顆檢查時 |
!cpuinfo | 各處理器的資訊,CP 欄為處理器編號 | 不確定有哪些處理器編號時 |
.bugcheck | 錯誤檢查代碼與參數 | 取得 0xA、0xD1 的參數 2 |
!pcr | 處理器控制區(PCR)的內容,含目前 IRQL | 官方標示目前不支援,判讀 IRQL 不要用它 |
- 多處理器目標的提示字元會帶目前處理器編號,例如
0: kd>;單處理器時只顯示kd>。 - 開啟詳細模式(verbose mode)時,輸出會在名稱後附上層級說明,例如官方 x64 範例的
[Synchronization level];WinDbg 切換詳細模式的快速鍵是 Ctrl+Alt+V。 - 指定了無效的處理器編號,或核心已經毀損時,偵錯器會顯示
Cannot get PRCB address。 .bugcheck只列代碼與參數,完整的自動分析仍用!analyze -v。
🛠️ 實戰步驟
整個流程只讀取傾印檔,不會改動出問題的電腦。先把傾印檔複製一份,之後都在副本上操作;遇到下面任何一種情況就先停下來,處理完再往下做。
- 傾印檔來自公司或學校管控的設備:核心記憶體傾印包含當機時核心使用中的記憶體,帶出或轉交前先取得 IT 同意
- 設好符號路徑後,
!analyze -v仍大量出現找不到符號的錯誤:回到步驟二用.sympath確認路徑,並確認網路能連上微軟符號伺服器 - 指令輸出和本文描述明顯對不上:先對照「讀懂 !irql 輸出」一節的表格,仍對不上就以
!analyze -v的結論為主
步驟一:確認傾印檔類型,複製一份再用 WinDbg 開啟
要逐顆檢查處理器,選核心記憶體傾印比較完整;只有小型傾印檔時,先查當機的那顆處理器。依微軟文件,核心記憶體傾印包含當機時核心使用中的所有記憶體;小型傾印檔收錄停止碼與參數、當機那顆處理器的處理器內容(PRCB)、當機的處理序與執行緒資訊、核心模式呼叫堆疊與已載入的驅動清單等。!irql 找不到處理器的 PRCB 時會回報錯誤,據這兩點推論,小型傾印檔應能查當機那顆處理器,查其他處理器時可能讀不到。
看檔案放在哪個位置,就能先分出兩種傾印檔。
%SystemRoot%\Minidump資料夾裡的是小型傾印檔,每次當機另存一個新檔,檔名含當機日期,例如官方範例的mini022900-01.dmp%SystemRoot%\Memory.dmp是核心記憶體傾印預設寫入的檔案;官方說明再次當機產生新的核心記憶體傾印時,舊檔會被覆寫,拿到後先複製
手上只有小型傾印檔、又需要檢查其他處理器時,傾印類型的設定方式可參考當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手;改傾印類型會改動出問題電腦的系統設定,不在本文的分析流程內。檔案複製到工作資料夾後,啟動 WinDbg,按 Ctrl+D 開啟傾印檔副本(官方快速鍵表列為 Open dump file)。
步驟二:設定符號路徑
先把符號路徑指向微軟公用符號伺服器,後面的 ln 與 !analyze -v 才能把位址對應到函式名稱。在指令列輸入下面兩行。
.symfix C:\Symbols
.reload.symfix 會把符號路徑設為微軟符號存放區,C:\Symbols 是本機快取資料夾,不存在時會在開始下載符號時自動建立;省略這個參數,會改用 WinDbg 安裝目錄下的 sym 子資料夾。.reload 讓偵錯器更新模組清單並刪除舊的符號資訊,實際需要時才讀取符號。輸入 .sympath 可以確認目前的路徑。
步驟三:用 .bugcheck 記下停止碼與參數 2
.bugcheck.bugcheck 會列出錯誤檢查代碼與參數,0xA、0xD1 的參數 2 就是當時的 IRQL。依官方說明,0xA 的參數 2 是發生錯誤時的 IRQL,值為 2 代表當時在 DISPATCH_LEVEL;0xD1 的參數 2 是存取記憶體當下的 IRQL,!analyze -v 會把它列成 Arg2: 0000000000000002, IRQL 這樣的一行。其他停止碼的參數 2 不一定是 IRQL,請先查該停止碼的官方說明;沒有 IRQL 參數可比對時,步驟五就以 !analyze -v 的結論為主。
步驟四:執行 !irql,讀出當機前一刻的 IRQL
!irql不加參數時,!irql 讀的是目前處理器,也就是提示字元 n: kd> 裡的 n 號處理器。官方 0xD1 範例在 0: kd> 下執行,得到 Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL),代表 0 號處理器在錯誤檢查前一刻處在 DISPATCH_LEVEL。
要看其他處理器,先用 !cpuinfo 列出處理器編號(CP 欄),再在指令後加上編號,例如 !irql 1。官方的雙處理器 x86 範例中,!irql 0 得到 28 (CLOCK2_LEVEL),!irql 1 得到 0 (LOW_LEVEL);數值 0 與 PASSIVE_LEVEL 相同,代表那顆處理器當時在最低層級。編號打錯會出現 Cannot get PRCB address,用 !cpuinfo 核對後重新輸入;編號正確仍出現這個訊息,官方列出的另一個原因是核心已經毀損,分析小型傾印檔時也可能只是沒有收錄該處理器的資料(見步驟一),兩種情況都改以 !analyze -v 的結論為主。
步驟五:交叉比對,決定下一步查什麼
!irql 和參數 2 都指向 DISPATCH_LEVEL 時,判讀才站得住;接著照 0xD1 官方建議,改查被存取的記憶體與程式位址。把參數 4 交給 ln,可以看到發出存取的是哪個函式;把參數 1 交給 !pool,可以確認那塊記憶體是不是分頁集區。以官方 0xD1 範例的參數為例,實際操作時換成你的參數 4 與參數 1。
ln fffff808adc386a6
!pool fffff808add271500xA 的官方說明另列出幾個並列的判讀方向,不論屬於哪一種,發出存取的函式都由 ln 查參數 4 得到。參數 1 小於 0x1000,多半是 NULL 指標;!pool 顯示參數 1 位於分頁集區,代表以當時的 IRQL 不能存取這份資料;也可能是釋放後又使用(use-after-free)或位元翻轉造成的壞指標,這時用 !pte、!address 查參數 1;這些指令查不到結果時的處理方式見步驟六。0xD1 若能判定責任驅動,驅動名稱會存在 KiBugCheckDriver,可以用 dx KiBugCheckDriver 顯示。
!irql 與參數 2 的情況 | 代表什麼 | 下一步 |
|---|---|---|
| 兩邊都是 DISPATCH_LEVEL(數值 2) | 當時可能在執行 DPC、StartIo 一類常式,或持有自旋鎖 | 用 ln、!pool 追查參數 4 與參數 1 |
| 兩邊數值不同 | 兩者記錄的時間點不同,參數 2 是存取記憶體當下,!irql 是錯誤檢查前一刻 | 以參數 2 判斷那次記憶體存取,!irql 只當旁證 |
沒有 IRQL 參數可比,!irql 為 LOW_LEVEL、PASSIVE_LEVEL 或 APC_LEVEL | 這兩層發生分頁錯誤不會因此致命,「IRQL 太高」解釋不了這次當機 | 回到 !analyze -v,依停止碼本身的說明判讀 |
沒有 IRQL 參數可比,!irql 為 DISPATCH_LEVEL | 可能真的在 DISPATCH_LEVEL,也可能是多次偵錯器中斷或錯誤檢查造成的顯示值(x86 除外) | 以 !analyze -v 的結論為主 |
!irql 高於 DISPATCH_LEVEL | 當時在裝置中斷服務常式或更高層級 | 用 k 指令看呼叫堆疊,確認當時在執行哪個模組 |
- 兩邊一致之後,下一步就改查記憶體,參數 1 是被存取的位址,參數 3 是讀、寫或執行,參數 4 是發出存取的程式位址。
- 參數 3 的寫法兩個停止碼不同,0xA 為位元欄位(0x0 讀、0x1 寫、0x8 執行),0xD1 為 0 讀、1 寫、2 或 8 執行。
- 兩邊數值不同時的處理方式,依據是兩份官方文件對參數 2 與
!irql的定義,這是本文整理的判讀順序。 - 沒有 IRQL 參數可比時,
!irql只能說明當時處在哪一層,不能單獨指出責任驅動。
步驟六:驗證結果
判讀完成前,確認兩件事對得上。
!irql與參數 2 一致(限 0xA、0xD1):不一致時,照步驟五表格的第二列處理。- 參數 1 的查詢結果能對應到官方列出的成因:位於分頁集區,符合「IRQL 太高還存取分頁資料」;小於 0x1000,多半屬 NULL 指標。兩者都不符合時,用
!pte、!address進一步調查參數 1;!pool、!pte、!address查不到結果,或仍判斷不出成因時,照實戰步驟開頭的停止條件,以!analyze -v的結論為主。
兩項都對得上時,ln 查到的函式所屬模組,或 dx KiBugCheckDriver 顯示的驅動,就是頭號嫌疑人。0xD1 的官方建議是停用該驅動,或向製造商確認有沒有驅動更新;停用驅動會改變系統設定,本文不示範,建議先把分析結果交給廠商或 IT 確認。
🔎 讀懂 !irql 輸出:數字、名稱與架構差異
判讀時看括號內的名稱,數字只是輔助。DIRQL 以上的部分層級,在不同處理器架構對應的數值不同,下表整理 x86 與 x64 常見層級,數值取自微軟封存部落格〈What is IRQL?〉(2010 年)的對照表,該表的 x64 欄標為 AMD64。
| 層級名稱 | x86 數值 | x64 數值 | 代表的情境 |
|---|---|---|---|
| PASSIVE_LEVEL | 0 | 0 | 使用者執行緒與多數核心模式作業 |
| APC_LEVEL | 1 | 1 | 非同步程序呼叫(APC)與分頁錯誤處理 |
| DISPATCH_LEVEL | 2 | 2 | 執行緒排程與延遲程序呼叫(DPC) |
| 裝置中斷層級(DIRQL) | 3–26 | 3–11 | 裝置中斷 |
| HIGH_LEVEL | 31 | 15 | 機器檢查與嚴重錯誤 |
- 官方
!irql範例中,數值 0 顯示為LOW_LEVEL,和上表的 PASSIVE_LEVEL 是同一個數值。 - 官方 x86 範例的
28 (CLOCK2_LEVEL)和上表同源資料一致,CLOCK2_LEVEL 是 x86 的時鐘層級,x64 沒有這個名稱。 - 兩份微軟資料對 x64 的 SYNCH_LEVEL 數值不一致,
!irql參考頁的 x64 範例輸出12 (SYNCH_LEVEL),封存部落格的 AMD64 欄則把 SYNCH_LEVEL 列為 13(與 CLOCK_LEVEL 同值)。本文查不到差異原因,遇到 12、13 這類數值,一律以輸出的名稱為準。 - 本文沒有查到 ARM64 的官方數值對照,分析 ARM64 裝置的傾印檔時,不要套用上表的數字,改以輸出內容搭配停止碼參數判讀。
🔬 底層機制:IRQL 為什麼一踩錯就藍屏?
分頁錯誤要靠較低 IRQL 的機制才能處理,程式卻停在較高的 IRQL,這個錯誤就沒有機會被處理。微軟封存部落格〈What is IRQL?〉說明,I/O 完成要靠在 APC_LEVEL 執行的程式碼,而處理器在 DISPATCH_LEVEL 時,APC_LEVEL 的程式碼不會執行,所以分頁錯誤在 DISPATCH_LEVEL 無法被解決;持有自旋鎖這類 DISPATCH_LEVEL 鎖的程式,因此不能碰可能被分頁出去的記憶體。驅動程式文件則直接寫明,在高於 APC_LEVEL 的層級引發分頁錯誤是致命錯誤;0xA 與 0xD1 描述的,都是在過高的 IRQL 存取分頁或無效位址的情況。
IRQL 的升降有嚴格規矩,違反同樣會當機。驅動程式 IRQL 註解文件要求升降 IRQL 遵守堆疊紀律,函式應以被呼叫時的 IRQL 返回,沿呼叫堆疊的 IRQL 值不得遞減,也不能在沒有先提高的情況下降低 IRQL。硬體優先順序文件列出幾種會造成致命錯誤的呼叫,例如以低於目前 IRQL 的值呼叫 KeRaiseIrql、在不是還原原本 IRQL 的情況下呼叫 KeLowerIrql,以及在 DISPATCH_LEVEL 以上等待非零時間的核心分派器物件。0xA 的官方說明也把「在 DISPATCH_LEVEL 呼叫不能在該層級呼叫的函式」與「忘記釋放自旋鎖」列為成因。
!irql 的數字來自當機前保存的值。官方說明,目標電腦中斷進偵錯器或發生錯誤檢查時,IRQL 會改變,但改變前一刻的 IRQL 會被保存下來,!irql 顯示的就是這個保存值。官方列出兩種會出現 Cannot get PRCB address 的情況,一是處理器編號無效,二是核心已經毀損;PRCB 是處理器控制區塊,官方說明它是 PCR 的延伸。小型傾印檔收錄的是當機那顆處理器的 PRCB,據此推論查其他處理器時可能讀不到,這也是步驟一建議逐顆檢查時改用核心記憶體傾印的原因。
驅動程式開發端可以用程式碼分析工具提早抓出來。微軟建議在驅動程式碼加上 IRQL 註解,例如用 _IRQL_requires_max_(DISPATCH_LEVEL) 標出函式可被呼叫的最高 IRQL;函式在更高的 IRQL 被呼叫時,程式碼分析工具就能找出不一致。
💡 總結:進階玩法與底層邏輯
!irql 回答的是「當機前一刻這顆處理器在哪一層」,要回答「誰造成當機」,還是得靠停止碼參數與呼叫堆疊。把它放進分析流程的固定位置,先 .bugcheck 記參數、再 !irql 讀層級、兩邊比對後才追記憶體,就能避免只看 DISPATCH_LEVEL 就下結論。
多處理器傾印可以逐顆檢查。在核心記憶體傾印中用 !cpuinfo 列出處理器編號,再以 !irql 0、!irql 1 逐顆讀出;官方的雙處理器範例,就是兩顆處理器分處不同層級的例子。
不適用的情況也要先知道。Windows 2000、Windows XP 產生的傾印檔不支援 !irql;只有小型傾印檔時,其他處理器可能讀不到;看到 DISPATCH_LEVEL 又沒有停止碼參數可比時,只能當旁證。
本文依 Microsoft Learn 的 !irql 參考頁(頁面標示最後更新 2023-10-25)、0xA 與 0xD1 錯誤檢查說明,以及驅動程式 IRQL 相關文件整理,2026-09-29 查證。
❓ 常見問題
Q:IRQL 是什麼意思?
IRQL 是中斷請求層級(Interrupt Request Level),Windows 用它排定中斷的優先順序。微軟文件說明 IRQL 是 0 到 31 的整數,常見的 PASSIVE_LEVEL、APC_LEVEL、DISPATCH_LEVEL 在 x86 與 x64 上分別是 0、1、2;處理器處在某個層級時,同級與較低的中斷會被擋下。
Q:為什麼 IRQL 搞錯會直接藍屏?
因為在高於 APC_LEVEL 的層級,分頁錯誤無法被處理。微軟文件寫明,在這種層級引發分頁錯誤就是致命錯誤,驅動在過高的 IRQL 存取分頁或無效的記憶體,常見的結果就是 0xA 或 0xD1。另外,以低於目前 IRQL 的值呼叫 KeRaiseIrql、在不是還原原本 IRQL 的情況下呼叫 KeLowerIrql,或在 DISPATCH_LEVEL 以上等待非零時間的核心分派器物件,官方也列為致命錯誤。
Q:!irql 指令怎麼看?
開啟傾印檔、設好符號後輸入 !irql,輸出會像官方範例的 Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL),0x0 是處理器編號,2 是數值,括號內是層級名稱。判讀以名稱為準;遇到 0xA、0xD1,再和 .bugcheck 顯示的參數 2 比對。
Q:!irql 和 !pcr 差在哪?
!irql 顯示錯誤檢查或偵錯器中斷前一刻保存的 IRQL,!pcr 顯示的是目前 IRQL。官方說明目前 IRQL 通常沒有參考價值,錯誤檢查前的 IRQL 只有 !irql 看得到;!pcr 的官方頁面也標示這個指令目前不支援、輸出可能不正確。
Q:小型傾印檔可以用 !irql 嗎?
應能查當機的那顆處理器。依官方文件,小型傾印檔收錄了當機那顆處理器的 PRCB,而 !irql 找不到 PRCB 時會回報 Cannot get PRCB address;據此推論,查其他處理器時可能讀不到。要逐顆檢查,改用核心記憶體傾印。
Q:這個方法在舊版本也適用嗎?
要分兩台電腦看。產生傾印檔的電腦須為 Windows Server 2003 以後的 Windows,Windows 2000 與 Windows XP 不支援 !irql,只能改看停止碼參數;分析用的電腦要符合 WinDbg 的需求,也就是 Windows 11 各版本或 Windows 10 1607 以上,不符合時把傾印檔複製到符合需求的電腦分析。本文以新版 WinDbg 示範;依官方說明,較舊版本 Windows 產生的傾印檔,應改用 Debugging Tools for Windows 內的 WinDbg (classic),或該 Windows 版本 SDK 所附的偵錯工具。
🔗 延伸閱讀
- WinDbg !analyze -v 完整教學:逐欄位讀懂當機分析報告,搞懂 STACK_TEXT 與 FAILURE_BUCKET_ID
- WinDbg Preview 安裝與符號路徑設定完整教學:為什麼你的當機分析報告一堆問號
- System Interrupts CPU 佔用高怎麼查?ISR 與 DPC 分層揪出兇手驅動
- 電腦一直跳 DPC_WATCHDOG_VIOLATION?先別重灌,八成是這支驅動程式
📎 參考資料來源
📖 第一級|廠商官方:
- !irql(Microsoft Learn) — 2026-09-29 查證
- !pcr(Microsoft Learn) — 2026-09-29 查證
- !cpuinfo(Microsoft Learn) — 2026-09-29 查證
- .bugcheck (Display Bug Check Data)(Microsoft Learn) — 2026-09-29 查證
- Bug Check 0xA IRQL_NOT_LESS_OR_EQUAL(Microsoft Learn) — 2026-09-29 查證
- Bug Check 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL(Microsoft Learn) — 2026-09-29 查證
- Managing Hardware Priorities(Microsoft Learn) — 2026-09-29 查證
- IRQL Annotations for Drivers(Microsoft Learn) — 2026-09-29 查證
- Small Memory Dump(Microsoft Learn) — 2026-09-29 查證
- Kernel Memory Dump(Microsoft Learn) — 2026-09-29 查證
- Install WinDbg(Microsoft Learn) — 2026-09-29 查證
- Analyze a Kernel-Mode Dump File by Using WinDbg(Microsoft Learn) — 2026-09-29 查證
- Using Debugger Commands(Microsoft Learn) — 2026-09-29 查證
- WinDbg: Keyboard Shortcuts(Microsoft Learn) — 2026-09-29 查證
- .symfix (Set Symbol Store Path)(Microsoft Learn) — 2026-09-29 查證
- .reload (Reload Module)(Microsoft Learn) — 2026-09-29 查證
- What is IRQL?(Microsoft Learn 封存部落格,2010-02-02) — 2026-09-29 查證
⚠️ 本文核心事實以第一級為準。x64 的 SYNCH_LEVEL 數值,!irql 參考頁範例(12)與 2010 年封存部落格對照表(13)不一致,已於正文揭露。
📅 本文查證戳記:2026-09-29 依據 Microsoft Learn 之 !irql 參考頁與 WinDbg、錯誤檢查、驅動程式 IRQL 相關文件查證撰寫,內容整理自官方文件,未在實機上執行。
若你在後續版本遇到步驟失效,歡迎在留言區回報。