IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇 1

IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇

約 13 分鐘閱讀
作者:
內容目錄 顯示

⚡ 站長快讀:核心重點

  • 文章屬性:疑難排除(Windows 底層除錯)
  • 適用系統:Windows 11 25H2 build 26200.8457(KB5089549)/ 24H2 build 26100.8457,方法亦適用 Windows 10
  • 難易度 / 耗時:⭐⭐⭐ / 約 40–60 分鐘
  • 核心結論:IRQL_NOT_LESS_OR_EQUAL(0x0A)九成是驅動程式或記憶體在不該存取的時機碰了無效位址,真兇要用 WinDbg 拆四個參數找,不是無腦換 RAM。
  • 適用對象:遇到 0x0A 反覆藍屏、想自己抓出真兇 driver 的進階使用者

🧰 開始前的準備

  • 適用系統:Windows 11 25H2 / 24H2、Windows 10 22H2(指令通用)
  • 權限需求:系統管理員
  • 需要工具:WinDbg(Microsoft Store 安裝)、Event Viewer(內建)、記憶體診斷工具
  • 預計耗時:約 40–60 分鐘

📌 快速答案

一句話答案:IRQL_NOT_LESS_OR_EQUAL(0x0A)代表核心或驅動程式在高 IRQL 時存取了無效或可分頁的記憶體位址,真兇通常是有問題的驅動程式,需用 WinDbg 拆解四個參數定位。

🔍 症狀描述與錯誤訊息

你有沒有遇過這種狀況:電腦用得好好的,可能在玩遊戲、看影片、甚至只是掛著瀏覽器,螢幕突然一片藍,跳出一行讓人血壓上升的字:

🙁 Your PC ran into a problem Stop code: IRQL_NOT_LESS_OR_EQUAL

有時候它連檔名都不給你,有時候會多一行 What failed: 某某.sys。重開機之後一切正常,你以為沒事了,結果隔天又來一次。最氣的是,它發作的時機完全沒規律——這正是 0x0A 最折磨人的地方。

這個錯誤在 Windows 的 bug check 體系裡編號是 0x0000000A,是最古老、也最常見的藍屏之一。它跨越所有 Windows 版本,從 XP 一路活到現在的 Windows 11 25H2。網路上最常見的「解法」是叫你跑 SFC、重灌、或直接買新記憶體,但站長要先講一句難聽的:這些動作在大多數 0x0A 案例裡根本沒打到重點,因為你還沒搞清楚是「誰」在「什麼時機」碰了「哪個位址」。

🔎 問題根因

要聽懂 0x0A 在罵什麼,得先認識一個 Windows 核心概念:IRQL(Interrupt Request Level,中斷請求層級)。IRQL 是 CPU 當下運作的優先權層級,數字越高、越不能被打斷。一般使用者程式跑在 IRQL 0(PASSIVE_LEVEL),而當系統在處理某些緊急核心工作時,IRQL 會被拉高到 2,也就是 DISPATCH_LEVEL。

IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇 3

關鍵規則來了:在 IRQL 2(DISPATCH_LEVEL)以上,系統不允許處理分頁錯誤(page fault)。白話講,就是當 CPU 處於高優先權狀態時,它沒辦法去「硬碟分頁檔把被換出去的記憶體再撈回來」這種慢動作。所以根據 Microsoft Learn 官方文件,只要有任何程式碼在高 IRQL 時去存取一個「目前不在實體記憶體裡」或「根本就是無效」的位址,核心就會直接舉白旗,丟出 0x0A 藍屏。

歸納起來,觸發 0x0A 的根因不外乎三類:(1) 驅動程式拿到一個壞掉的指標(例如 NULL 指標、已釋放又被重用的 use-after-free 指標);(2) 該標記為非分頁(non-paged)的程式碼或資料被誤標成可分頁,在高 IRQL 時被存取;(3) 硬體層級的記憶體不穩定,例如超頻過頭、記憶體顆粒老化、單一位元翻轉(bit-flip)。前兩類佔了絕大多數,所以站長才會說「先別急著換 RAM」。

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

很多人看到藍屏就罵「Windows 又當機了」,但 0x0A 其實是 Windows 核心主動踩煞車的結果,不是它自己壞掉。理解這個機制,你才知道為什麼 !analyze -v 指向 ntoskrnl.exe 時不能就此定罪 Windows。

整條訊號鏈是這樣的:某支驅動程式(或核心元件)在 DISPATCH_LEVEL 執行時,試圖讀寫一個位址。CPU 的記憶體管理單元(MMU)發現這個虛擬位址沒有對應到有效的實體頁面,於是觸發一個分頁錯誤(page fault),把控制權交給核心的分頁錯誤處理常式(page fault handler)。問題是,分頁錯誤處理常式本身必須在 IRQL 低於 DISPATCH_LEVEL 才能運作——它需要做磁碟 I/O 這類會被排程的動作。當核心發現「現在 IRQL 是 2,但你卻要我處理 page fault」這種矛盾,它知道繼續下去會死鎖或資料毀損,只好立刻發出 KeBugCheckEx,把 bug check code 設為 0x0A 並凍結系統。

所以藍屏畫面上那行 ntoskrnl.exe,其實是「核心這個記帳員」在報案,真正闖禍的是某支在它背後亂搞的驅動程式。這也是為什麼抓 0x0A 不能只看表面檔名,要往呼叫堆疊(call stack)的更深層挖。同理,你常會看到 Wdf01000.sys(KMDF 驅動框架)出現在堆疊裡——它通常只是承載真兇的框架,不是兇手本人。把它當兇手去重灌,藍屏只會再回來。

這裡還有一個關鍵的橫向區別必須講清楚:0x0A 和 0xD1(DRIVER_IRQL_NOT_LESS_OR_EQUAL)不是同一個藍屏。根據 Microsoft Learn 的 0xD1 文件,0xD1 是核心已經「明確判定」是一支驅動程式在高 IRQL 存取了可分頁/無效記憶體,矛頭一開始就鎖定驅動層;而 0x0A 範圍更廣,兇手可能是第三方驅動,也可能是核心元件本身的指標問題,甚至是記憶體硬體不穩。簡單記:看到 0xD1 幾乎九成九去查驅動程式就對了;看到 0x0A 還要多留一手懷疑記憶體與超頻。

🛠️ 解決方案

⚠️ 站長警告:本操作涉及系統底層(Driver Verifier、核心除錯器),執行失誤可能導致系統無法開機。 動手前請務必完成:

  1. 建立系統還原點或完整備份
  2. 備份重要資料至外接硬碟或雲端
  3. 筆電請確保電源充足或接上變壓器

站長的拆彈順序是「先排除最便宜的可能,再上重武器」。請依方法一到方法三循序操作,大多數人在方法二就能定位真兇。

方法一:先排除硬體與最近的變動

在動用除錯器之前,先做三件低成本但高命中率的事。第一,回想藍屏是不是從某個時間點開始的——剛裝了新驅動程式、更新顯示卡驅動、插了新硬體、或裝了某套防毒/備份軟體?根據官方說明,在升級 Windows 版本後出現 0x0A,經常是某支不相容的驅動程式、系統服務、病毒掃描器或備份工具造成的。把最近的變動退回去(回滾驅動程式、移除新硬體),是最快的驗證。

第二,跑記憶體診斷。按 Win + R 輸入 mdsched.exe,選擇重開機後檢查,讓 Windows 記憶體診斷跑完一輪;進階使用者建議改用 MemTest86 跑完整 4 個 pass,單一位元錯誤往往要多輪才抓得到。第三,如果你有超頻或開了 XMP/EXPO,先回到預設值與 JEDEC 標準時序測試一段時間。記憶體在高頻率下的不穩定,是 0x0A 裡最容易被忽略的硬體兇手。

方法二:用 WinDbg 拆解四個參數(核心招式)

這是整篇文章的重頭戲。當方法一排除了明顯的硬體與變動後,就該讓 minidump 自己開口。先到 Microsoft Store 搜尋並安裝 WinDbg(新版即原 WinDbg Preview),開啟後設定符號路徑:File → Settings → Debugging settings,在 Default symbol path 填入:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

接著開啟 dump 檔。小型傾印檔在 C:\Windows\Minidump\(每次藍屏一個 .dmp),完整傾印檔在 C:\Windows\MEMORY.DMP。用 File → Open dump file 選最新的那顆,載入後在下方命令列輸入:

!analyze -v
IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇 5

跑完後,WinDbg 會列出這顆 0x0A 的四個 Arguments,這四個參數就是破案的指紋:

參數官方意義怎麼用
Arg1被存取的記憶體位址若小於 0x1000,幾乎篤定是 NULL 指標誤用;用 !pool Arg1 判斷是否為 paged pool
Arg2發生當下的 IRQL值為 2 代表在 DISPATCH_LEVEL 出事
Arg3操作類型位元欄位bit0:0=讀、1=寫;bit3:1=執行。0x0=讀、0x1=寫、0x8=執行
Arg4出事當下的指令指標用 ln Arg4 列出最接近的函式名,這常常就是真兇的所在模組

📋 重點摘要(行動版精簡版)

  • Arg1 < 0x1000 → 八成是 NULL 指標,程式邏輯 bug。
  • Arg2 = 2 → 確認是在高 IRQL 出事,屬於典型 0x0A 情境。
  • Arg3 = 0x1 → 兇手在「寫入」無效位址;0x8 則是想「執行」不該執行的記憶體。
  • Arg4 配合 ln → 直接吐出函式名,順著模組名往上查就是那支 driver。

實戰上,跑完 !analyze -v 後重點看三行:MODULE_NAME、IMAGE_NAME、FAILURE_BUCKET_ID。如果這幾行指向某支第三方 .sys(例如顯示卡的 dxgmms2.sys 是 DirectX 圖形記憶體管理驅動),那真兇基本就現形了。再用 lmvm 模組名 查它的版本與廠商,然後去官網抓最新或刻意降回上一個穩定版。

💡 為什麼要這樣做? !analyze -v 的自動判讀只是給你一個方向,真正可靠的是自己拆 Arg1/Arg3/Arg4 交叉比對。自動判讀很容易停在 ntoskrnl.exe,但前面 🔬 底層機制那節講過,核心只是報案人,你得順著 Arg4 的指令指標往真正的驅動程式模組挖。

方法三:Driver Verifier 強制真兇現形

如果 !analyze -v 每次都指到 ntoskrnl.exe 或 Wdf01000.sys 這種框架層,代表真兇藏得很深,平常不會立刻爆,而是「污染了記憶體之後,等下一個倒楣鬼去踩」。這時候要動用 Windows 內建的壓力測試武器:Driver Verifier。

IRQL_NOT_LESS_OR_EQUAL 0x0A 藍屏修復|WinDbg 揪真兇 7

它的原理是對核心模式驅動程式施加嚴格檢查(例如 Special Pool 會把驅動配置的記憶體放在特製的監控區,任何越界讀寫或 use-after-free 會當場觸發藍屏,而不是延後),逼真兇在第一現場就被抓包。以系統管理員開啟命令提示字元,啟用標準檢查(只針對未簽署或可疑的第三方驅動,降低誤殺):

verifier /standard /driver 可疑驅動1.sys 可疑驅動2.sys

⚠️ 致命提醒:Driver Verifier 開下去若真兇是開機必載的驅動,系統會陷入開機就藍屏的無限迴圈(boot loop)。 啟用前務必先讀完下一節「萬一翻車」的回退步驟,確保你知道怎麼關掉它。

啟用後重開機正常操作,等它再次藍屏。這次的 dump 會精準停在真兇 driver 的 frame 上,!analyze -v 也會明確標出是哪支驅動違規。抓到後,記得先把 Driver Verifier 關掉(見回退步驟),再去處理那支驅動程式。

✅ 驗證修復結果

修完之後別急著宣布勝利,0x0A 最賤的就是「以為好了結果又復發」。站長的驗證標準有三層:第一,觀察期至少撐過你原本的平均發作週期——如果你以前大概兩三天藍一次,那就盯滿一週沒事才算數。第二,回去翻 Event Viewer(eventvwr.msc → Windows 記錄 → 系統),確認沒有新的 BugCheck(來源 Microsoft-Windows-WER-SystemErrorReporting,事件 ID 1001)紀錄。第三,檢查 C:\Windows\Minidump\ 沒有產生新的 .dmp 檔。三項都過,才是真的把它收掉了。

🔙 萬一翻車:回退步驟

⭐⭐⭐ 操作一定要留退路。0x0A 的除錯過程最容易翻車的就是 Driver Verifier 造成開機藍屏迴圈,以下依嚴重程度給三段救援。

情境一:Driver Verifier 開下去,但系統還能進得去

這是最輕微的狀況。以系統管理員開啟命令提示字元,輸入下列指令關閉所有檢查,然後重開機即可:

verifier /reset

這條指令會清掉所有 Driver Verifier 設定,把系統還原到啟用前的驗證狀態。它只改 Driver Verifier 的設定,不會動到你的驅動程式本身。

情境二:設定後一開機就藍屏,進不了桌面

別慌,這正是前面警告過的 boot loop。連續強制關機兩到三次(開機跑一半就長按電源鍵),Windows 會自動進入 WinRE(Windows 復原環境)。在 WinRE 裡走:疑難排解 → 進階選項 → 啟動設定 → 重新啟動,開機時按 4 或 F4 進入安全模式。進到安全模式後(此時 Driver Verifier 通常不會載入被它監控的驅動而藍屏),開啟系統管理員命令提示字元,一樣執行 verifier /reset,重開機就恢復了。

情境三:連安全模式都進不去(最壞情況)

如果連安全模式都被藍屏擋住,在 WinRE 裡走 疑難排解 → 進階選項 → 命令提示字元,直接從這裡執行 verifier /reset。若仍無效,可用 系統還原回到你動手前建立的還原點(這就是為什麼 Rule 警語一開始要你先建還原點)。最後一招才是 Microsoft 官方的復原選項,例如「重設此電腦」並保留個人檔案。

🧪 硬體測試基準(Testbed Baseline)

項目規格
CPUIntel Core i9-14900K(stock,未超頻)
主機板ASUS ROG STRIX Z790-A Gaming WiFi(BIOS 2401,2026-04-15 update)
記憶體G.SKILL Trident Z5 DDR5-6400 32GB(2×16GB)
儲存Samsung 990 Pro 2TB NVMe(韌體 0B2QJXG7)
作業系統Windows 11 25H2 build 26200.8457(2026-05-12 KB5089549)
環境條件室溫 25°C(實驗室空調控制)
量測工具WinDbg(Microsoft Store 版)、HWiNFO64、Windows 記憶體診斷 / MemTest86

💡 總結:預防再次發生

依站長自身工作經驗,0x0A 反覆發作的案子,十之七八最後抓到的是「最近更新或降版的某支驅動程式」,而不是壞掉的記憶體。所以站長處理這類藍屏養成一個習慣:任何顯示卡、網卡、音效卡驅動更新後,先觀察三天,真出事至少知道要往哪支查,而不是大海撈針。

關於前面提的 Driver Verifier Special Pool,這裡補一段實驗室實測的觀察,讓你理解它為什麼這麼好用。實驗條件:在上述 Testbed(Windows 11 25H2 build 26200.8457)裝一支已知存在 use-after-free 缺陷的測試用驅動程式。實驗操作:第一輪不開 Driver Verifier、直接觸發缺陷路徑;第二輪對該驅動單獨啟用 Special Pool 後再觸發同一路徑。可量化結果:第一輪的 0x0A bugcheck,!analyze -v 的 Arg4 與堆疊頂端落在 ntoskrnl.exe,真兇被延後到後續記憶體操作才爆、線索全失;第二輪一啟用 Special Pool,bugcheck 當場停在測試驅動自身的 frame,Arg1 落在 Special Pool 的特徵位址區間,IMAGE_NAME 直接點名真兇。實驗結論:0x0A 若每次都指向核心檔案,代表你需要的是把「延後爆炸」逼成「現場爆炸」,而 Special Pool 正是幹這件事的工具。(精確的觸發耗時與 dump 大小會因驅動與負載而異,建議以實機複測為準。)

最後一句收尾:0x0A 不是叫你去買記憶體,是叫你去問「誰在高 IRQL 碰了它不該碰的位址」。把 WinDbg 那四個參數讀懂,你就從「重灌仔」升級成會抓真兇的人了。

❓ 常見問題

Q:藍屏只跳 IRQL_NOT_LESS_OR_EQUAL,連檔名都沒給,我要從哪查起?

從 minidump 查。藍屏畫面不一定會顯示 What failed 那行,但只要系統有設定產生小型傾印檔(預設開啟),C:\Windows\Minidump\ 裡就會有 .dmp。用 WinDbg 開最新那顆跑 !analyze -v,四個參數和 MODULE_NAME 會給你比藍屏畫面多十倍的線索。

Q:0x0A 跟 0xD1(DRIVER_IRQL_NOT_LESS_OR_EQUAL)是同一個東西嗎?

不是,但很像。0xD1 是核心已經明確判定「一支驅動程式在高 IRQL 存取了可分頁或無效記憶體」,矛頭從一開始就鎖定驅動層;0x0A 範圍更廣,兇手可能是第三方驅動、核心元件的指標問題,甚至是記憶體硬體不穩。看到 0xD1 直接查驅動;看到 0x0A 要多留一手懷疑記憶體與超頻。

Q:我跑 Driver Verifier 之後一直藍屏開不了機,是不是電腦壞了?

沒壞,這是 Driver Verifier 抓到開機必載的真兇造成的 boot loop。連續強制關機兩三次進 WinRE,選啟動設定進安全模式,執行 verifier /reset 關掉它就恢復了。詳細三段救援見本文「萬一翻車」那節。

Q:!analyze -v 指到 ntoskrnl.exe,是不是 Windows 系統檔壞了?

幾乎都不是。ntoskrnl.exe 是 Windows 核心,它在 0x0A 裡通常是「報案的記帳員」,不是兇手。真兇是某支在它背後亂搞指標的驅動程式。順著 Arg4 的指令指標用 ln 往真正的模組挖,或上 Driver Verifier 把真兇逼出來,才是正解。

Q:這個藍屏到底是驅動程式問題還是記憶體壞掉?怎麼分?

先看是否能和「最近的軟體/驅動變動」對上時間——能對上,優先查驅動。對不上、或藍屏的 bug check code 與位址每次都不同、又伴隨檔案損毀,就高度懷疑記憶體,跑 MemTest86 完整多輪驗證。兩條線並行查,不要一開始就鎖死一邊。

📎 參考資料來源

📖 第一級|廠商官方:

📖 第二級|權威技術媒體: