⚡ 站長快讀:核心重點
- 文章屬性:疑難排除(A5 底層除錯)
- 適用系統:Windows 10 / Windows 11
- 難易度 / 耗時:⭐⭐⭐ / 約 20 分鐘
- 核心結論:參數 1、2 是紀錄指標,不是陷阱編號。
- 適用對象:藍屏顯示 0x0000003D 的人。
📌 快速答案
一句話答案:INTERRUPT_EXCEPTION_NOT_HANDLED 是核心中斷物件的例外處理器無法處理該例外所觸發的藍屏,先用 WinDbg 讀參數 1、2 兩個紀錄指標定位出錯驅動。
🧰 開始前的準備
- 適用系統:Windows 10 / Windows 11(桌機、筆電皆適用)
- 權限需求:系統管理員
- 需要工具:WinDbg(Microsoft Store 或 Windows SDK 內含)、事件檢視器、Driver Verifier(多數 Windows 版本內建於
%WinDir%\system32\Verifier.exe;官方註明 Windows 10 S 不含此工具) - 必要前置:確認系統有產出核心傾印檔。傾印設定位於「控制台 → 系統及安全性 → 系統 → 進階系統設定 → 啟動及修復 → 設定」,在「寫入偵錯資訊」下拉選單指定;沒有傾印檔,下面所有步驟都做不了。
- 預計耗時:讀懂約 20 分鐘。若要跑 Driver Verifier 抓兇手,重現時間完全取決於這台機器多久當一次(官方未提供任何時間基準),請預留彈性。
若你完全沒碰過 WinDbg,建議先看過站長寫的 WinDbg 藍畫面 minidump 分析教學,把符號路徑與 !analyze -v 的基本用法先跑通,再回來處理 0x3D。
🔍 症狀描述與錯誤訊息
0x3D 的表現和多數驅動類藍屏一樣:機器可能在開機後幾分鐘、看影片、玩遊戲、外接裝置插拔或系統從睡眠喚醒時突然停住,畫面切到藍色的停止畫面,重新開機後在事件檢視器的「系統」記錄裡留下一筆 BugCheck 事件。
藍屏畫面上通常長這樣:
Your PC ran into a problem and needs to restart.
Stop code: INTERRUPT_EXCEPTION_NOT_HANDLED
在 WinDbg 裡則會看到停止碼與四個參數並列的格式,型如 0x0000003D (參數1, 參數2, 0, 0)。這裡有一個關鍵訊號要先講:後兩個參數固定是 0,這不是傾印檔壞掉,而是微軟官方對這支停止碼的參數定義本來就把參數 3、參數 4 寫成 0。
要特別提醒一個容易混淆的地方:0x3D 的參數 1 不是陷阱編號(trap number)。「參數 1 是陷阱編號」是另一支停止碼 UNEXPECTED_KERNEL_MODE_TRAP(0x7F)的規格;兩支停止碼名字裡都帶著「核心接不住」的意思,參數語意卻完全不同,套錯會把整個排錯方向帶偏。
🔎 問題根因:0x3D 到底在說什麼
先給結論:0x3D 說的是「例外發生在中斷處理路徑上,而且中斷物件那一層的例外處理器接不住」。
微軟官方對 Bug Check 0x3D 的定義只有一句話:INTERRUPT_EXCEPTION_NOT_HANDLED 的值為 0x0000003D,表示核心中斷物件之中斷管理的例外處理器無法處理所產生的例外(This indicates that the exception handler for the kernel interrupt object interrupt management was not able to handle the generated exception)。
把這句話拆成三層來看,對排錯比較有用:
- 「產生了一個例外」——某段核心模式程式碼踩到記憶體存取違規、對齊錯誤、無效指令之類的狀況。這一層跟其他核心例外類藍屏(0x1E、0x8E)沒有差別。
- 「這個例外發生在中斷管理的脈絡下」——也就是系統正在處理某個裝置的中斷。這是 0x3D 有別於泛用例外碼的地方:它指名了出事的「時機」。
- 「例外處理器接不住」——中斷路徑上的例外處理器沒有辦法把它吃掉,只能呼叫
KeBugCheckEx讓系統停下來。
所以 0x3D 是一支「指名時機、但不指名兇手」的停止碼。它告訴你事情發生在中斷處理過程中,卻沒有直接把出事的模組名稱塞進參數裡。這也是為什麼很多人看到 0x3D 會覺得無從下手——因為它的四個參數裡,真正有資訊的只有兩個,而且那兩個還是指標,不是可以直接查表的數值。
至於「是不是顯示卡或音效卡驅動的問題」,合理但不能直接斷言。會註冊中斷服務常式(ISR)的是實體裝置的驅動程式:顯示卡、音效卡、網路卡、儲存控制器、USB 控制器都算。單看停止碼不足以判定是哪一類,要靠下面的傾印檔分析與 Driver Verifier 才能收斂。
🔬 底層機制:這個錯誤訊號從哪裡來?
要理解 0x3D,得先知道 Windows 怎麼處理硬體中斷。
依微軟官方文件,實體裝置的驅動程式若要接收中斷,會註冊一個或多個中斷服務常式(Interrupt Service Routine,ISR),系統每次收到該中斷就呼叫這個 ISR。Windows 同時支援傳統的線路式中斷(line-based)與 PCI 裝置的訊息式中斷(message-signaled interrupt),驅動可註冊 InterruptService 常式處理兩者,或註冊 InterruptMessageService 常式專門處理訊息式中斷。
從硬體到程式碼的路徑大致是:
裝置拉中斷 → 中斷控制器送到 CPU → 核心的中斷分派程式碼提高 IRQL → 依中斷物件找到對應的 ISR → 呼叫驅動的 ISR。
在這條路徑上跑的程式碼,受到的限制比一般核心程式碼嚴格得多。依微軟《Writing an ISR》官方文件,驅動的 ISR 執行於中斷脈絡、跑在系統指派的 DIRQL 上,而正因為 ISR 跑在相對高的 IRQL,它可以呼叫的支援常式集合會受到限制。一旦這裡面有人踩到例外,結構化例外處理不見得能像在一般執行緒脈絡裡那樣被攔下來收拾——這時中斷管理層的例外處理器就會攤手,系統走 bugcheck 0x3D。
這也解釋了 0x3D 的兩個參數為什麼是「紀錄指標」而不是「數值」:例外是在中斷脈絡裡發生的,當下的暫存器狀態與呼叫堆疊,對除錯器來說不是預設可見的。系統把 EXCEPTION_RECORD(記錄例外碼、例外位址、例外旗標與參數)和 CONTEXT(記錄當下的暫存器內容)的指標交出來,讓分析者自己去把「案發現場」還原回來。
官方定義的四個參數
| 參數 | 官方描述 | 實際意義 | 怎麼用 |
|---|---|---|---|
| 參數 1 | Exception Record(When Available) | 例外紀錄的位址 | 餵給 .exr |
| 參數 2 | Context Record(When Available) | 內容紀錄的位址 | 餵給 .cxr |
| 參數 3 | 0 | 官方定義即為 0 | 無資訊 |
| 參數 4 | 0 | 官方定義即為 0 | 無資訊 |
注意參數 1、2 後面那個「When Available」。這是官方原文自己加的但書,意思是這兩個指標不保證每次都拿得到。官方並未定義「取不到」時該參數會是什麼值,只說了不保證有;實務上的判準很單純——參數若不是有效位址,.exr 與 .cxr 就餵不進去,只能退回 !analyze -v 與堆疊回溯。這個但書很重要,它決定了下面方法一能不能走完。
🧭 0x3D 跟 0x1E、0x8E、0x7F 差在哪
先給結論:四支停止碼都跟「核心例外」有關,但指名的層級不同——0x3D 指名中斷脈絡、0x1E 與 0x8E 指名一般核心例外、0x7F 指名 CPU 陷阱。參數第一格的語意完全不一樣,不能互相套用。
| 停止碼 | 官方定義的觸發情境 | 參數 1 的語意 | 主要排查入口 |
|---|---|---|---|
| 0x3D INTERRUPT_EXCEPTION_NOT_HANDLED | 中斷物件的中斷管理例外處理器無法處理該例外 | 例外紀錄指標(可能取不到) | .exr / .cxr 還原現場 |
| 0x1E KMODE_EXCEPTION_NOT_HANDLED | 核心模式程式產生了錯誤處理器沒接住的例外 | 未被處理的例外碼 | 先查例外碼,再看參數 2 的例外位址 |
| 0x8E KERNEL_MODE_EXCEPTION_NOT_HANDLED | 核心模式應用程式產生了錯誤處理器沒接住的例外 | 未被處理的例外碼 | 先查例外碼分流 |
| 0x7F UNEXPECTED_KERNEL_MODE_TRAP | Intel CPU 產生了核心沒接住的陷阱 | 陷阱編號(0x08 為雙重錯誤等) | 查陷阱編號表 |
這張表就是本文最想釐清的一件事:「參數 1 是陷阱編號」是 0x7F 的規格,不是 0x3D 的。0x7F 的官方文件明寫「藍屏上出現的第一個參數指定陷阱編號」,並列出常見與較少見的陷阱編號對照表(0x00 除以零、0x05 邊界檢查錯誤、0x06 無效指令、0x08 雙重錯誤等,表外的編號官方要你查 Intel 處理器架構手冊);0x3D 的官方文件則從頭到尾沒有出現 trap 這個字。
順帶一提,如果你手上的是 0x1E,站長另外寫過 KMODE_EXCEPTION_NOT_HANDLED(0x1E)藍屏的完整排錯,那支的參數第一格才是可以直接查 NTSTATUS 表的例外碼,處理路線跟 0x3D 不同,別拿錯文章對照。
還有一個有趣的落差值得寫下來:微軟官方對 0x3D 的「Resolution」章節只有一句話,叫你用 !analyze 除錯延伸模組。相較之下 0x1E 的官方頁面有成因分析、疑難排解與完整的除錯範例輸出,0x7F 也有成因與疑難排解兩大節。這代表微軟並沒有為 0x3D 準備專屬處置流程——所以下面的方法一,本質上是借用 0x1E 官方文件裡的 EXCEPTION_POINTERS 拆解法,而且對 0x3D 來說更省事:0x1E 要先用 kb 找到 PspUnhandledExceptionInSystemThread、再 dd 出兩個指標;0x3D 直接把這兩個指標放在參數 1、2,省掉前面兩步。
🛠️ 解決方案
⚠️ 執行前必讀(高風險操作):本節方法二會啟用 Driver Verifier。微軟官方明確警告「執行 Driver Verifier 可能導致電腦當機」,並建議「只在你用於測試與偵錯的電腦上執行」。實務上多數讀者只有一台主力機,因此動手前務必先做兩件事:①備份重要資料;②建立系統還原點或確認你有可開機的 Windows 修復媒體。另外請確保筆電接上電源、桌機不要在雷雨或供電不穩時操作——Driver Verifier 觸發的當機次數會明顯變多。
停止條件(符合任一,請不要繼續往下做):
– 不確定自己的 Windows 版本或機器型號
– 尚未完成資料備份
– 已啟用 BitLocker 但手邊沒有修復金鑰
– 這是公司或學校控管的設備,且未取得 IT 授權
– 沒有可開機的修復媒體或不知道怎麼進安全模式
– 指令輸出與本文描述明顯不符
方法一:用參數 1、2 把案發現場還原出來(建議先做)
這是 0x3D 專屬、也是最省時的一條路,而且完全不改動系統。
步驟 1|載入傾印檔並跑基本分析
在 WinDbg 開啟 C:\Windows\Minidump 下最新的 .dmp,先跑:
!analyze -v先看它有沒有直接點名某個模組。有的話記下來,但別急著下結論——中斷路徑上被點名的可能是核心本身或 HAL(微軟官方的 0x1E 除錯範例輸出裡,堆疊上就同時出現 NT! 與 HAL! 的框架,真正出事的第三方驅動在更下面),真正的兇手往往還在後面。
步驟 2|確認四個參數,取出前兩個位址
在 !analyze -v 的輸出裡找 Arguments,或直接讀藍屏畫面上的四個參數。確認第三、四個是 0(符合官方定義),把第一個與第二個記下來。
步驟 3|用 .exr 讀例外紀錄
.exr 這個指令的官方用途就是顯示例外紀錄的內容,包含例外位址、例外碼、例外旗標,以及一串例外參數。把參數 1 餵給它:
.exr <參數1的位址>輸出裡最關鍵的是 ExceptionCode 與 ExceptionAddress。例外碼可以對到 NTSTATUS 值:0xC0000005 是存取違規,0x80000002 是資料型別未對齊,0x80000003 是在沒接核心除錯器時撞到中斷點或 ASSERT。例外位址則指向出事的那行程式碼所在的模組。
步驟 4|用 .cxr 切換暫存器內容並回溯堆疊
.cxr 的官方說明寫得很清楚:它顯示指定位址的內容紀錄,同時把除錯器的暫存器內容設成那一份;文件並直接指出,內容紀錄的資訊可以用來協助除錯「發生未處理例外、且無法取得精確堆疊回溯」的系統停止狀況。這正是 0x3D 的處境。
.cxr <參數2的位址>接著立刻跑堆疊回溯:
kb這時 kb 印出來的,才是例外真正發生時的那條呼叫堆疊。從最上面往下讀,第一個出現的第三方驅動檔名(.sys),就是你的頭號嫌疑犯。
步驟 5|如果指標拿不到
如果參數 1 或參數 2 不是有效位址(官方「When Available」但書生效),.exr 與 .cxr 就沒得用。此時退回三件事:仔細讀 !analyze -v 的 MODULE_NAME 與 IMAGE_NAME;用 kb 加大框架數看完整堆疊;到事件檢視器「Windows 記錄 → 系統」對照當機時間點前後有沒有裝置或驅動相關的錯誤。收斂不出來就走方法二。
方法二:用 Driver Verifier 逼兇手現形
當方法一指不出明確模組,或指到的模組換了版本仍然當機,就換 Driver Verifier 上場。它會即時監控核心模式驅動與圖形驅動,偵測會讓系統不穩的非法函式呼叫與問題行為;一旦抓到違規,它會直接觸發 bugcheck 停機,好留下最完整的除錯資訊。
選對驗證範圍是關鍵。 官方建議大多數情況下應該「從清單選取驅動程式名稱」自行指定,而不是一次驗證全部——因為「自動選取這台電腦上安裝的所有驅動程式」雖然覆蓋率最高,卻會耗盡 Special Pool 與資源追蹤可用的資源,也會明顯拖慢系統。針對 0x3D,合理的清單是:方法一點名的模組、近期更新過的顯示卡與音效卡驅動、以及非微軟簽署的第三方驅動。
用圖形介面: 以系統管理員身分開啟命令提示字元,輸入 verifier 開啟 Driver Verifier 管理員,選「建立標準設定」→ 下一步 → 選「從清單選取驅動程式名稱」→ 勾選嫌疑驅動 → 完成 → 重新開機。
用指令列: 針對單一驅動下標準設定,只要一行:
verifier /standard /driver mydriver.sys下完之後自行重新開機讓設定生效。
查目前狀態:
verifier /query接下來就是照平常的方式用電腦,等它當。Driver Verifier 抓到違規時通常會丟出 Bug Check 0xC4(DRIVER_VERIFIER_DETECTED_VIOLATION),也可能是 0xC1、0xC6、0xC9、0xD6、0xE6 這幾支。重點是:這時藍屏的停止碼會換成 0xC4 家族,不再是 0x3D,而這是好消息——因為 0xC4 會直接告訴你是哪支驅動違反了哪條規則。拿到新傾印檔後再跑一次 !analyze -v,並可搭配 !verifier 傾印 Driver Verifier 的統計資料。
Driver Verifier 的完整選項與各規則類別怎麼挑,站長另外寫過一篇 Driver Verifier 完整使用教學,要調進階設定的人可以直接看那篇。
方法三:回到最單純的變因控制
如果前兩個方法都沒收斂,就回頭做變因控制,這一步不需要任何除錯工具:
- 驅動回溯:把方法一或方法二點名的驅動,在裝置管理員裡回復到前一版;或到裝置廠商官網抓官方版本,不要用第三方驅動更新工具。
- 拔掉近期新增的硬體:外接音效卡、擷取卡、USB 集線器、無線網卡這類會產生中斷的裝置,一次移除一項再觀察。
- 檢查系統記錄:事件檢視器裡當機時間點前後的裝置錯誤,常常比停止碼本身更能指出方向。
- 記憶體檢測:記憶體問題會讓核心程式碼在各種地方踩到例外,用 Windows 記憶體診斷跑一輪排除掉。
✅ 驗證修復結果
改完之後不要只看「這兩天沒當」就收工。0x3D 屬於偶發型當機,誤判為修好是很常見的事。建議照下面三項確認:
- 確認 Driver Verifier 已經關掉。這一項最重要,漏掉會讓系統長期承受額外負擔並偶發當機。用
verifier /querysettings確認目前沒有啟用中的設定。 - 刻意重現原本的觸發情境。原本是玩遊戲當、看影片當、還是睡眠喚醒當?就照原情境重複操作數次,而不是開機放著不動。
- 查事件檢視器有沒有新的 BugCheck 事件。到「Windows 記錄 → 系統」依來源篩選 BugCheck;
C:\Windows\Minidump裡也不應該再出現新的傾印檔。
三項都過才算收工。至於要觀察多久,官方沒有標準;站長的建議是抓一到兩週——這是編輯建議、不是官方數字,實際請以「原本多久當一次」的兩三倍時間為準。
🔙 萬一翻車:回退步驟
Driver Verifier 最典型的翻車情境是:啟用之後系統開機就當、當完重開又當,陷入開機循環。它本來就設計成「一抓到違規就停機」,而問題驅動如果在開機階段就載入,你會連桌面都進不去。這種情況照下面處理。
情境一:還進得了桌面
以系統管理員身分開命令提示字元,執行:
verifier /reset然後重新開機。也可以在 Driver Verifier 管理員裡選「刪除現有設定」→ 完成,再重新開機。
情境二:進不了桌面,但進得了安全模式
依官方 WinRE 技術參考,連續兩次開機失敗、或開機完成後兩分鐘內連續兩次非預期關機或重新開機,Windows 會自動進入修復環境;選「疑難排解 → 進階選項 → 啟動設定 → 重新啟動」,開機後按對應數字進入安全模式。進入安全模式後開命令提示字元,一樣執行:
verifier /reset然後重新開機回到正常模式。要注意:安全模式並不會替你關掉 Driver Verifier——官方指令說明寫著預設的 persistent 模式會「確保 Driver Verifier 設定跨多次重新開機持續生效」,設定寫在登錄檔裡、開機時照樣套用。真正幫上忙的是安全模式只載入最小驅動集合,你原本的嫌疑驅動多半不會被載入,所以通常撐得到你把指令下完。
情境三:安全模式也進不去
⚠️ 先說一件容易誤會的事:微軟官方只記載「在執行中的那套 Windows 裡下 verifier /reset 再重開機」這一條停用程序,並沒有提供在修復環境(WinRE)裡清除 Driver Verifier 設定的做法。所以不要把希望押在修復環境的命令提示字元上。
這種情況請走「系統還原」:修復環境 →「疑難排解 → 進階選項 → 系統還原」,選你動手之前建立的那個還原點——這就是前面要求先建還原點的原因。
更好的做法是不要走到這一步。 官方的 verifier 指令有一個防呆開關 /bootmode,其中 resetonbootfail 的官方說明是「若系統無法啟動,則在後續重新開機時停用 Driver Verifier」(預設值是 persistent,會跨多次重開機持續生效)。在啟用 Driver Verifier 的同時一併下這個設定,就能大幅降低卡在開機循環的風險:
verifier /bootmode resetonbootfail官方註明 /bootmode 要設定或變更都必須重新開機才生效,所以請在你重開機讓 Driver Verifier 上線之前就先下好。
情境四:方法三回退驅動之後更糟
裝置管理員的「回復驅動程式」按鈕會還原到上一版;若該按鈕是灰的,就到裝置廠商官網下載你原本在跑的那個版本重裝。不要憑印象亂裝更舊的版本,那只會多一個變因。
⚠️ 一個原則:回退時請把設定改回你操作前的原值,而不是照抄任何文章寫的固定值。不同機器、不同 Windows 版本的原廠預設不一定相同,照抄別人的數值可能讓你的機器變成另一種不對的狀態。
💡 總結:預防再次發生
站長我處理罕見停止碼的習慣,是先去官方文件把「參數定義」抄一遍,再回頭看二手教學對不對得起來。0x3D 就是一個很好的例子:它的官方頁面短到不到一百個英文字,連 Resolution 都只有一句話。遇到這種官方著墨極少的停止碼,先回官方文件確認參數語意,通常比多讀三篇二手教學有效——尤其它旁邊還有 0x1E、0x8E、0x7F 這幾支名字相近、參數語意卻完全不同的鄰居,不先把定義釘住,很容易拿錯規格套。
這裡也要誠實說明:本文屬於官方文件與權威來源交叉查證的深度解析,不是站長第一手實測;文中沒有出現任何未經來源支持的實測數字或機器型號。
要降低再遇到 0x3D 的機率,實務上有三件事值得做:
- 驅動更新走官方通道。會註冊 ISR 的驅動(顯示卡、音效卡、網路卡、儲存控制器)只從裝置廠商或 Windows Update 取得,不要用第三方驅動更新工具。0x3D 這種中斷路徑上的例外,很大一部分來自版本不對的驅動。
- 先確認傾印檔設定是開的。很多人是當了第三次才想到要看 dump,結果發現系統根本沒在寫。花兩分鐘把「啟動及修復」設定好,下次出事就有東西可以看。
- Driver Verifier 用完立刻關。這是站長看過最常見的後遺症:抓完兇手忘記
verifier /reset,系統從此莫名其妙地慢、莫名其妙地偶發當機。養成「開啟前先記一筆、結案後立刻關掉」的習慣。
❓ 常見問題
Q:0x3D 藍屏到底是什麼原因造成的?
依官方定義,是核心中斷物件的中斷管理例外處理器無法處理所產生的例外。白話說:系統在處理某個裝置的中斷時,那段核心模式程式碼踩到了例外,而中斷路徑上的例外處理器接不住,只能停機。它指名了「出事的時機是在中斷處理過程中」,但沒有指名兇手,兇手要靠參數 1、2 的兩個紀錄指標去挖。
Q:是不是顯示卡或音效卡驅動的問題?
有可能,但不能只憑停止碼就斷定。所有會註冊中斷服務常式的實體裝置驅動都在嫌疑範圍內,包含網路卡、儲存控制器、USB 控制器。正確做法是用 .exr / .cxr 還原堆疊看第一個第三方 .sys 是誰,或用 Driver Verifier 針對嫌疑清單逼它現形。
Q:跟 0x1E、0x8E 藍屏有什麼不同?
0x1E 與 0x8E 講的是「核心模式程式產生了未被處理的例外」,是泛用的;0x3D 額外指名了例外發生在中斷管理的脈絡下。更實際的差別在參數:0x1E 的參數 1 是可以直接查表的例外碼,0x3D 的參數 1 是例外紀錄的位址。兩者的排查第一步完全不同。
Q:要怎麼用 Driver Verifier 抓兇手?
以系統管理員身分執行 verifier 開啟管理員介面,選「建立標準設定」,再選「從清單選取驅動程式名稱」勾選嫌疑驅動,重開機後正常使用等它當。抓到違規時停止碼會變成 0xC4 家族,該碼會直接指出違規驅動與違反的規則。做之前先備份、先建還原點,做完立刻 verifier /reset。
Q:修完之後又復發怎麼辦?
先確認復發的停止碼是否仍是 0x3D。若換了停止碼,代表原本那支驅動的問題已經處理掉,現在是另一個變因,要重新走一次分析流程。若仍是 0x3D 且參數 1、2 指向同一個模組,把該模組的版本、Windows 版本與重現步驟整理好,直接回報給裝置廠商——有些驅動缺陷只能等原廠修。若參數指向不同模組,優先懷疑記憶體或主機板等會造成隨機錯誤的硬體因素。
📎 參考資料來源
📖 第一級|廠商官方:
- Bug Check 0x3D: INTERRUPT_EXCEPTION_NOT_HANDLED — 2026-08-07 查證
- Bug check 0x1E: KMODE_EXCEPTION_NOT_HANDLED — 2026-08-07 查證
- Bug Check 0x8E: KERNEL_MODE_EXCEPTION_NOT_HANDLED — 2026-08-07 查證
- Bug check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP — 2026-08-07 查證
- Writing an ISR — 2026-08-07 查證
- .exr (Display Exception Record) — 2026-08-07 查證
- .cxr (Display Context Record) — 2026-08-07 查證
- Driver Verifier — 2026-08-07 查證
- Driver Verifier Command Syntax — 2026-08-07 查證
- Windows Recovery Environment (Windows RE) technical reference — 2026-08-07 查證
- Introduction to Interrupt Service Routines (ISRs) — 2026-08-07 查證
- Enabling a Kernel-Mode dump file — 2026-08-07 查證
⚠️ 本文核心事實以第一級官方文件為準。
📅 本文查證戳記:2026-08-07 依據 Microsoft Learn 現行文件撰寫;本文為官方文件交叉查證之深度解析,非第一手實測。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。
🔗 延伸閱讀
- KERNEL_MODE_EXCEPTION_NOT_HANDLED(0x8E)藍屏排錯:參數 1 定路線、參數 2 鎖模組
- UNEXPECTED_KERNEL_MODE_TRAP(0x7F)藍屏排錯:讀懂第一參數的陷阱編號揪出真兇
- DRIVER_VERIFIER_DETECTED_VIOLATION(0xC4)藍屏怎麼修?讀懂 Parameter 1 揪出違規驅動
- DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)藍屏怎麼修?讀懂四個參數揪出兇手驅動
- 藍屏跳 SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(0x7E)?先讀「What failed」揪出兇手驅動