DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)藍屏怎麼修?讀懂四個參數揪出兇手驅動

⚡ 站長快讀:核心重點

• 屬性 / 系統:疑難排除(底層除錯)/ Windows 10、11
• 難易度 / 耗時:⭐⭐⭐ / 約 40–90 分鐘
• 核心結論:別把力氣花在 IRQL 那個數字上——官方說多數情況真正該查的,是被存取的那塊記憶體。
• 適用對象:藍屏停止碼顯示 DRIVER_IRQL_NOT_LESS_OR_EQUAL,或 minidump 裡 bugcheck code 是 D1 的人。

📌 快速答案

一句話答案:DRIVER_IRQL_NOT_LESS_OR_EQUAL 0xD1 是核心模式驅動程式在過高的 IRQL 存取了可分頁或無效位址,先讀第一與第四參數定位兇手驅動,再用 Driver Verifier 確認。

🧰 開始前的準備

• 適用系統:Windows 10、Windows 11(Driver Verifier 位於 %WinDir%\system32\Verifier.exe;Microsoft 註明 Windows 10 S 未內含此工具)
• 權限需求:系統管理員(官方明訂必須是 Administrators 群組成員才能使用 Driver Verifier)
• 需要工具:WinDbg、記憶體傾印檔(小型記憶體傾印的預設目錄依官方文件為 %SystemRoot%\Minidump)、命令提示字元(系統管理員)
• 預計耗時:約 40–90 分鐘(含至少一次重開機)
• 事前必做:重要資料先備份、建立系統還原點、確認手上有可開機的救援 USB,並且先確認自己知道怎麼從 WinRE 進安全模式——本文最後一節有完整回退步驟,請先讀過再動手

🔍 症狀描述與錯誤訊息

先講結論:只要系統辨識得出該負責的驅動,它的名字就會直接印在這顆藍屏的訊息欄位裡,而很多人跳過去沒看。

典型畫面是這樣:

🙁 您的電腦發生問題,需要重新啟動。

停止碼:DRIVER_IRQL_NOT_LESS_OR_EQUAL

失敗的模組:xxxxxx.sys

觸發時機通常有幾種樣態:插上某個 USB 裝置就跳、開特定遊戲或虛擬機就跳、網路一吃重就跳、或是剛更新完某支驅動之後開始跳。以站長的經驗,共同點是跟某個裝置的使用強度相關,而不是隨機發生;官方文件並未描述觸發樣態,這一段屬經驗歸納。

如果你有接核心偵錯器,或事後用 WinDbg 開 minidump,!analyze -v 會印出類似這樣的四個參數(以下數值取自 Microsoft Learn 官方範例,非站長實測):

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

Arg1: fffff808add27150, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000000, value 0 = read operation, 1 = write operation

Arg4: fffff808adc386a6, address which referenced memory

這四行就是整份報告的全部重點。這篇文章要做的事,就是教你把這四行讀成一句人話。

🔎 問題根因

答案先給:0xD1 的官方定義句寫的是「核心模式驅動程式在過高的 IRQL 之下,試圖存取可分頁記憶體」,同頁成因段再補上「或根本無效」的位址;官方十六進位值為 0x000000D1。

Microsoft 把它拆成三種典型行為:

1. 在 DISPATCH_LEVEL 或更高的 IRQL,解參考了一個壞指標(NULL 指標或已被釋放的指標)。
2. 在 DISPATCH_LEVEL 或更高的 IRQL,存取了可分頁的資料。
3. 在 DISPATCH_LEVEL 或更高的 IRQL,執行了可分頁的程式碼。

官方另外列了幾個常見的頁面錯誤來源,對排查很有參考價值:該函式被標記為可分頁卻在提高的 IRQL 下執行(包含「取得了鎖」這個情況);呼叫的函式屬於另一支驅動,而那支驅動已經被卸載;以及用一個無效的函式指標去呼叫。

這裡有一個很多人搞反的重點,而且是官方自己寫在文件裡的:「在這類 bug check 的多數情況中,問題不是 IRQL 等級,而是被存取的那塊記憶體。」所以看到 Arg2 是 2 就一路往「IRQL 太高」鑽,方向通常是錯的——真正要查的是 Arg1、Arg3、Arg4 這三個。

還有一個好消息,而且是 0xD1 專屬的:官方明載,如果系統能辨識出該負責的那支驅動,它的名字會被印在藍屏上,並且存放在記憶體中的 KiBugCheckDriver。你可以在 WinDbg 裡直接下一行指令把它印出來,不需要拆堆疊。這條捷徑在 0x0A 的官方文件裡是沒有的,詳見下一節的對照。

🔬 底層機制:這個錯誤訊號從哪裡來?

一句話:Windows 核心裡有一套「中斷優先權階梯」,爬到某個高度以上就不准碰會被換出到硬碟的記憶體,踩線就當場停機。

IRQL 是什麼:核心的優先權階梯

IRQL(Interrupt Request Level,中斷要求層級)決定一段核心程式碼「現在有多不能被打斷」,也決定它能呼叫哪些核心支援常式。官方文件由低到高列出這幾層:

官方對 PASSIVE 與 APC 兩層有一句很關鍵的補充:這兩層都隱含執行緒上下文,也都隱含程式碼可以被換出分頁。爬到 DISPATCH_LEVEL 以上,這兩個前提就同時消失了。

為什麼「高 IRQL + 分頁記憶體」等於死刑

分頁管理員要把資料從硬碟換回實體記憶體,這件事本身需要等待 I/O 完成。而官方明訂:在 IRQL 大於等於 DISPATCH_LEVEL 時呼叫 KeWaitForSingleObject 或 KeWaitForMultipleObjects 去等待非零間隔,是致命錯誤。既然在這一層根本不准等,系統也就沒辦法把目前這條執行緒掛起來去等磁碟,於是只能停機。

官方把這條規則寫得很直接:任何執行在高於 APC_LEVEL 的常式,都不能安全地從 paged pool 配置記憶體或存取 paged pool 中的記憶體;如果一個執行在高於 APC_LEVEL 的常式造成了分頁錯誤,那是致命錯誤。

最容易踩到的一條線:自旋鎖會把你抬上去

實務上最常見的意外情境不是工程師「故意」把 IRQL 拉高,而是呼叫了某個會用到自旋鎖的支援常式,IRQL 被順手抬到 DISPATCH_LEVEL——官方明載,呼叫像 ExInterlockedXxx 這類使用自旋鎖的支援常式,會把目前處理器的 IRQL 提升到 DISPATCH_LEVEL 或 DIRQL(前提是呼叫端還沒處在被提高的 IRQL)。程式碼作者以為自己還在 PASSIVE_LEVEL,順手碰了一塊可分頁的緩衝區,0xD1 就出現了。

這也解釋了為什麼 0xD1 的災情常常跟裝置的使用強度掛鉤:DPC 與 ISR 是驅動程式最常在高 IRQL 執行的地方,而它們正是在裝置忙碌時才會密集被呼叫。

🧭 0xD1 跟 0x0A 差在哪?別把兩張參數表混著讀

先給結論:兩顆停止碼的第一、第二參數指涉相同(官方措辭略有出入),第三、第四參數的官方定義才是真的不同,而且 0xD1 多了一個 0x0A 沒有的捷徑。照著 0x0A 的讀法硬套 0xD1,很容易把 Arg4 讀反。

站長站內另有一篇IRQL_NOT_LESS_OR_EQUAL 0x0A 的完整拆解,那篇處理的是 0x0A;這篇專門處理 0xD1。兩者的官方差異整理如下:

三個實務上的差別值得記住:

1. 0xD1 的官方定義把肇事者限定在核心模式驅動程式。 官方對 0x0A 的定義句包含「Windows 本身」,對 0xD1 則寫死是 kernel-mode driver,排查因此可以更早聚焦在「哪一支 .sys」。但要注意核心模式驅動也包含系統自帶的模組——官方自己的範例輸出就是 Wdf01000.sys——所以「限定為驅動程式」不等於「一定是第三方驅動」。
2. 0xD1 的 Arg3 有一個 0x0A 沒有的值:2。 官方 0xD1 參數表把 2 與 8 都標為 Execute;0x0A 的表則是拆成 bit 0 與 bit 3 兩個獨立欄位來解釋。拿 0x0A 的位元邏輯去套 0xD1 的 2,會得到錯誤結論。
3. 先跑 dx KiBugCheckDriver 再拆堆疊。 這是 0xD1 專屬的省時步驟,能不能拿到值取決於系統當下有沒有辨識出責任驅動,但成本只有一行指令,不試白不試。

🛠️ 解決方案

⚠️ 執行前警語(⭐⭐⭐ 高風險段):本節的方法三會啟用 Driver Verifier。官方明確警告 Driver Verifier 可能造成電腦當機,只應在用於測試與偵錯的電腦上執行。開始之前請確認:①重要資料已備份 ②已建立系統還原點 ③筆電請接上電源 ④手上有可開機的救援 USB,並且已經讀過本文最後的回退步驟。

停止條件清單(符合任一,請停在這裡不要繼續):不確定自己的 Windows 版本或機型;尚未完成備份;已啟用 BitLocker 但手上沒有修復金鑰;公司或學校管控的設備且未取得 IT 授權;沒有可開機的救援 USB 也不會進 WinRE;指令輸出與本文描述不符。

方法一:先讀藍屏上的驅動名稱與 KiBugCheckDriver(成功率最高、風險最低)

這是門檻最低的一步,而且對 0xD1 特別有效——因為官方把「印出責任驅動名稱」寫進了這顆停止碼的規格裡。

1. 若藍屏畫面上有列出 xxxxxx.sys,先把它抄下來。這通常已經是答案的一半。
2. 開 WinDbg 載入 minidump 後,先下這一行:

dx KiBugCheckDriver

官方範例的輸出長這樣:

0: kd> dx KiBugCheckDriver
KiBugCheckDriver : 0xffffc6092de892c8 : "Wdf01000.sys" [Type: _UNICODE_STRING *]

1. 拿到檔名之後,別急著判死刑。先確認那支驅動是誰家的:在檔案總管開 C:\Windows\System32\drivers\,對該檔案按右鍵看「詳細資料」頁籤的產品名稱與版本。很多時候藍屏印出的是 ntoskrnl.exe 或 Wdf01000.sys 這類系統模組——那代表是別人叫它做的,還要往下查。
2. 同時去事件檢視器看系統記錄檔,對照藍屏發生的同一時間區段有沒有其他嚴重錯誤。官方在 0xD1 頁面把這一步列為不使用偵錯器時的基本排查手段之一。

藍屏訊息中一旦點名了某支驅動,官方在 0xD1 頁面列出的處置有兩條:停用該驅動,或向製造商確認有沒有更新版驅動(官方原句未限定第三方驅動)。站長再補第三條實務作法:把該驅動回滾到上一個確定可用的版本。若被點名的是系統自帶模組,通常代表真正的肇事者在它的呼叫端或下層,得回頭走方法二。

方法二:用 WinDbg 把四個參數拆開讀(定位精準度最高)

如果方法一拿到的是系統模組,或根本沒印出名字,就得動手拆參數。WinDbg 的安裝與 !analyze 輸出怎麼讀,站長另有一篇WinDbg 藍畫面 minidump 分析教學可以照著跑,這裡只講 0xD1 專屬的判讀順序。

第一步:用 Arg4 找出「誰碰的」。

對第四參數下 ln(list nearest symbols),官方文件對 0xD1 的說明是:這個位址就是「引用了該記憶體的位址」,對它下 ln 可以看到函式名稱。

ln fffff808adc386a6

第二步:用 Arg1 判斷「碰到了什麼」。

官方建議對第一參數下 !pool,看它是不是 paged pool;再視情況用 !address 與較進階的 !pte 進一步了解那塊記憶體的性質。

!pool fffff808add27150
!address fffff808add27150

判讀方向:如果 !pool 說那是 paged pool 或其他可分頁記憶體,那就對應到「IRQL 太高、不該在這裡碰它」;如果那個位址看起來根本不像有效位址,方向就轉向壞指標——官方在 0x0A 的說明中補了一條很實用的通則:參數 1 小於 0x1000 時,多半是 NULL 指標解參考,這條經驗在讀 0xD1 的 Arg1 時同樣有參考價值(但請注意它出現在 0x0A 的官方頁面,不是 0xD1 頁面)。

第三步:用 Arg3 決定接下來查什麼。

• Arg3 = 0(讀):驅動想讀一塊已經被換出或已釋放的資料。
• Arg3 = 1(寫):同上,但更容易伴隨記憶體毀損,後續適合搭配 Special Pool。
• Arg3 = 2 或 8(執行):這代表在高 IRQL 執行可分頁的程式碼,問題多半出在函式的分頁屬性,而不是資料指標。

第四步:補完現場。

官方另外建議的幾個常用指令:用 !irql 看中斷前該處理器的 IRQL(官方範例輸出為 2 (DISPATCH_LEVEL))、用 k 系列指令看堆疊、有 trap frame 時用 .trap 切上下文、用 lm t n 列出載入模組、用 !memusage 看系統記憶體整體狀態,以及用 u 系列指令反組譯 Arg4 指到的那段程式碼。

方法三:用 Driver Verifier 把藏很深的兇手逼到第一現場(最後手段)

前兩步都指不出具體的第三方驅動時,才輪到這一步。Driver Verifier 的用途是即時監看驅動行為,一旦抓到違規就主動觸發 bug check 停機,把最完整的證據留下來。

先鋪好退路,再開檢查員。 這是本節最重要的一句話,也是多數中文教學漏掉的一段。官方的 /bootmode 提供了幾個模式,其中兩個就是為了「開了之後開不了機」而存在的:

建議的下法是先設 bootmode,再設驗證目標。注意兩件事:官方明訂 /bootmode 要設定或變更都必須重新開機才生效;另外 /bc <重開機次數> 會自動把 bootmode 設成 resetonunusualshutdown。

先設定啟動模式:

verifier /bootmode resetonbootfail

再指定要驗的驅動(一次只驗一支,理由見下):

verifier /standard /driver 你要驗的驅動.sys

設定完之後重新開機,設定才會生效。

為什麼一次只驗一支? 因為 /standard 內含的 Special Pool 是有資源上限的:官方說明每一筆從 special pool 的配置會用掉一頁不可分頁的實體記憶體與兩頁虛擬位址空間;而當 special pool 被用完時,系統會改用一般的記憶體集區來滿足配置,而且回傳成功狀態、不會報錯。換句話說,同時驗一堆驅動的結果是「Special Pool 靜默失效,你卻以為它在保護你」。官方因此明確不建議在啟用 Special Pool 時同時驗證多支驅動。想確認 Special Pool 到底有沒有真的在用,可以看 Driver Verifier Manager 的 Global Counters——官方說明,若 Special Pool 已啟用但少於 95% 的集區配置來自 special pool,管理員會顯示警告。

/standard 實際包含哪些檢查,官方列得很清楚,其中對 0xD1 最對症的是前兩項:Special Pool(旗標 bit 0,0×1)負責抓記憶體越界與釋放後存取,Force IRQL Checking(旗標 bit 1,0×2)則是直接針對「在高 IRQL 碰可分頁記憶體」這個行為設計的。其餘標準項目還包含 Pool Tracking、I/O Verification、Deadlock Detection、DMA Verification、WDF Verification、Security Checks、Miscellaneous Checks 與 DDI compliance checking。

接下來會發生什麼? 官方明說:Driver Verifier 偵測到的所有違規都會導致 bug check,而且典型是 0xC4 DRIVER_VERIFIER_DETECTED_VIOLATION。所以請有心理準備——開了之後跳的藍屏停止碼會從 0xD1 換成 0xC4,那不是新故障,而是檢查員抓到人了。0xC4 的參數怎麼讀,站長另有一篇DRIVER_VERIFIER_DETECTED_VIOLATION 0xC4 的專文。

最後補一個官方註記,踩到會白忙一場:在 Windows build 20150 到 25126 之間的版本,若在 Driver Verifier 中選取 ntoskrnl,可能會收到 invalid state 錯誤;官方建議取消選取 ntoskrnl,或升級到 build 25126 之後的版本。

✅ 驗證修復結果

改完之後怎麼確認真的修好,而不是剛好幾天沒跳?建議按這個順序確認:

1. 先把 Driver Verifier 關掉。 這是第一步,不是最後一步——帶著 Verifier 跑日常工作只會拖慢系統並增加當機機率。
2. 確認設定真的清乾淨了。 下 verifier /querysettings 檢視「下次開機後會啟用哪些選項、會驗哪些驅動」;下 verifier /query 檢視目前的活動摘要。
3. 回到原本會觸發藍屏的場景實測。 0xD1 多半跟裝置使用強度有關,所以要重現的是原本那個情境(插上該裝置、跑那個遊戲、讓網路吃滿),不是開著桌面放三天。
4. 看事件檢視器有沒有新的嚴重錯誤。 沒有新的 bugcheck 事件、且原情境重跑多次都正常,才算過關。
5. 確認 minidump 有繼續在產生。 如果之後又跳藍屏卻找不到傾印檔,等於下一輪排查又要從零開始。依官方文件,傾印類型設定在「啟動與修復」對話方塊的「寫入偵錯資訊」區,小型記憶體傾印會把歷次檔案存進 %SystemRoot%\Minidump。

🔙 萬一翻車:回退步驟

情境一:還進得了 Windows。

開啟系統管理員身分的命令提示字元,下:

verifier /reset

官方說明:此指令會清除所有 Driver Verifier 設定,下次開機後不會驗證任何驅動。下完之後必須重新開機。 你也可以在 Driver Verifier Manager 裡選「刪除現有設定」再按完成,效果相同。

情境二:開機就跳藍屏,進不了桌面。

1. 讓電腦在開機過程中連續失敗(多數機器連續兩到三次開機失敗會自動進入 WinRE 修復環境)。
2. 進入 WinRE 後,依官方支援文件依序選「疑難排解」→「進階選項」→「啟動設定」→「重新啟動」。
3. 重新啟動後,在「啟動設定」清單按數字鍵 4 選擇啟用安全模式(官方清單中第 4 項)。
4. 進入安全模式後開啟系統管理員命令提示字元,下 verifier /reset,然後重新開機。

之所以能這樣救,是因為安全模式只載入最基本的驅動;Driver Verifier 的設定仍在,但你有機會在它把系統弄掛之前把它關掉。

情境三:安全模式也進不去。

回到 WinRE,改用「系統還原」還原到你在動手之前建立的還原點。這就是本文一開始要求先建立還原點的原因。若連系統還原也無法使用,才考慮用救援 USB 進行修復——這個階段請不要自行嘗試任何磁碟分割或開機設定的修改,那是另一個風險等級的操作,建議轉交能實機處理的人。

若你事前設過 verifier /bootmode resetonbootfail,系統在啟動失敗後會自動於後續重開機停用 Driver Verifier,上面這幾步大多用不到——這也是本文把它放在啟用步驟之前的原因。

💡 總結:預防再次發生

站長我這些年在工作中處理過的 0xD1,絕大多數最後都收斂到同一類答案:某支第三方驅動的版本,跟目前這台機器的硬體或 Windows 版本組合不對盤。 不是硬體壞掉,也不是系統中毒。這也是為什麼「重灌」對 0xD1 常常有效卻治標不治本——重灌之後你又把同一支驅動裝回去,過幾週它還是會回來。

三個實際有效的預防動作:

1. 驅動只從裝置製造商官網或 Windows Update 取得。 第三方「驅動更新工具」推來的版本經常不是給你這台機器的,而 0xD1 正是這類錯配最典型的表現。
2. 一次只換一樣東西。 同時更新顯示卡驅動、網路卡驅動又裝了新的虛擬機軟體,下次跳 0xD1 時你會分不出是誰的責任。
3. 把傾印檔設定先做好、放著不動。 藍屏是一次性的現場,沒有傾印檔就等於現場沒有拍照。這件事只需要設定一次,卻決定了下一次你是花 40 分鐘定位,還是花一個週末重灌。

最後回到官方那句話,它值得再抄一次:多數情況下,問題不是 IRQL 等級,而是被存取的那塊記憶體。 把注意力從 Arg2 移到 Arg1、Arg3、Arg4,你的排查效率會差很多。

❓ 常見問題

Q:0xD1 是不是記憶體(RAM)壞掉?

多半不是。官方的定義句寫的是「核心模式驅動程式在過高的 IRQL 存取了可分頁記憶體」;成因段則補一句「這顆 bug check 通常由使用了不當記憶體位址的驅動程式造成」。兩句的矛頭都落在軟體層的驅動程式,而不是實體記憶體模組。如果你同時看到多種不同的隨機停止碼、而且與特定裝置無關,那才比較符合實體記憶體或匯流排層的故障樣態(那類分流要看的是匯流排與實體層的訊號,不是驅動的 IRQL 行為)。

Q:藍屏印出 ntoskrnl.exe,是不是 Windows 自己壞了?

不能這樣推論。ntoskrnl.exe 是 Windows 核心本體,它出現在藍屏上通常代表「核心在執行某個由第三方驅動排入的工作時踩到地雷」,真兇還在堆疊更深處。這種情況正是方法二與方法三存在的理由。

Q:0xD1 跟 0x0A 到底哪裡不一樣?我兩顆都跳過。

最實用的差別有三個:0xD1 的官方定義限定肇事者是核心模式驅動程式,0x0A 則包含 Windows 本身;兩者的第三參數官方定義方式不同(0xD1 是列舉值 0/1/2/8,0x0A 是位元欄位);0xD1 多了 KiBugCheckDriver 這條可以直接讀出責任驅動名稱的捷徑。完整對照見本文上方的表格。

Q:一定要用 Driver Verifier 嗎?我怕開了開不了機。

不一定。方法一與方法二不需要動 Driver Verifier,而且對「藍屏已經印出具名第三方驅動」的案例通常就夠了。只有在前兩步都指不出兇手時才需要走方法三,而且務必先設 verifier /bootmode resetonbootfail 並建立還原點。

Q:修完之後又復發怎麼辦?

先確認復發時的停止碼與失敗模組是不是同一個。如果模組換了,那是新問題,重新從方法一走一次;如果模組相同、驅動也已經是最新版,那就要考慮是硬體與該驅動的相容性問題——把該裝置暫時移除或停用,觀察是否完全消失,是最快的二分法。

🔗 延伸閱讀

• BSOD 跳 PAGE_FAULT_IN_NONPAGED_AREA(0x50)?別急著換 RAM
• PFN_LIST_CORRUPT 0x4E 藍屏怎麼修?讀懂官方八個參數,分流驅動或硬體
• THREAD_STUCK_IN_DEVICE_DRIVER(0xEA)藍屏排錯教學
• BAD_POOL_CALLER 0xC2 藍屏怎麼修?讀懂 Parameter 1 揪出兇手驅動
• DATA_BUS_ERROR 0x2E 藍屏排錯:讀懂四個參數,用實體位址找出真兇

📎 參考資料來源

📖 第一級|廠商官方:

• Microsoft Learn:Bug Check 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL — 2026-08-03 查證
• Microsoft Learn:Bug check 0xA IRQL_NOT_LESS_OR_EQUAL — 2026-08-03 查證
• Microsoft Learn:Managing hardware priorities(IRQL 階梯、驅動常式、paged pool 與等待規則、自旋鎖抬升 IRQL) — 2026-08-03 查證
• Microsoft Learn:Driver Verifier(工具總覽與使用方式) — 2026-08-03 查證
• Microsoft Learn:Driver Verifier Command Syntax(含 /bootmode 與 /flags 對照) — 2026-08-03 查證
• Microsoft Learn:Special pool memory corruption detection in Driver Verifier — 2026-08-03 查證
• Microsoft Learn:Configure system failure and recovery options in Windows(傾印類型與 Minidump 目錄) — 2026-08-03 查證
• Microsoft 支援:Windows startup settings(WinRE 啟動設定與安全模式) — 2026-08-03 查證

⚠️ 本文核心事實全部以第一級官方文件為準;文中所有參數值與指令輸出均取自 Microsoft Learn 官方範例,非站長實測數據。

📅 本文查證戳記:2026-08-03 依 Microsoft Learn 現行官方文件撰寫。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。