⚡ 站長快讀:核心重點
- 文章屬性:疑難排除(A5 底層除錯 / cornerstone)
- 適用系統:Windows 10 / 11(含 24H2、25H2)
- 難易度 / 耗時:⭐⭐⭐ / 約 20–40 分鐘
- 核心結論:先讀 Parameter 1——它有 21 種值,而且其中兩種根本不是「被寫壞」而是「撞到上限」,搞錯方向會白忙一整晚。
- 適用對象:跳 0x13A、懷疑自己記憶體壞掉、想知道該查驅動還是查硬體的人
📌 快速答案
一句話答案:KERNEL_MODE_HEAP_CORRUPTION(0x13A)代表 Windows 核心模式的堆積(heap)管理員發現堆積結構已經被寫壞。依微軟官方 Bug Check 文件,Parameter 1 會標明損毀型別、共 21 種值,絕大多數描述指向緩衝區溢位、釋放後再使用、重複釋放這類程式碼層級的錯誤。值得注意的是:官方在這隻停止碼沒有建議執行記憶體診斷(同為記憶體結構損毀的 0x19 有),所以先別急著換 RAM。
🧰 開始前的準備
- 適用系統:Windows 10 全版本、Windows 11(含 24H2 / 25H2)。依微軟官方發行資訊,25H2 為 OS build 26200、24H2 為 26100;24H2 家用與專業版的服務終止日是 2026-10-13,若你還在 24H2,修完藍屏也順手把升級排進行事曆
- 權限需求:系統管理員(讀事件記錄檔可用一般帳號;開 Driver Verifier 則不行——微軟官方明列「必須是本機 Administrators 群組成員才能使用 Driver Verifier」)
- 需要工具:事件檢視器(內建,方法一只需要它)、Driver Verifier(
verifier.exe;官方說明多數 Windows 版本已內建於%WinDir%\system32\、不另外提供下載,Windows 10 S 不含此工具)、想讀當機檔再裝 WinDbg - 前置設定:先把「自動重新啟動」關掉、記憶體傾印設成「自動」或「核心」,否則當機當下什麼線索都留不下來
- 預計耗時:約 20–40 分鐘(方法一 5 分鐘內;要跑 Driver Verifier 再加)
⚠️ 動手前先讀這段(⭐⭐⭐ 高風險):本文方法三會用到 Driver Verifier。微軟官方文件在頁面最上方就用 Important 標了三句話:「執行 Driver Verifier 可能導致電腦當機」、「只在你用來測試與偵錯的電腦上執行 Driver Verifier」、「你必須是該電腦 Administrators 群組的成員」。設定不當會讓你一開機就藍屏、進不了桌面。動手前先確認:重要資料已備份、BitLocker 復原金鑰在手、你知道怎麼進安全模式關掉它(做法見文末〈萬一翻車〉)。符合下列任一「停止條件」就別往下做:不確定自己的 Windows 版本、沒做備份、BitLocker 開著但找不到金鑰、這是公司或學校管控的設備而你沒有 IT 授權、手上沒有救援 USB、指令輸出跟本文描述對不起來。
🔍 症狀描述與錯誤訊息
典型畫面是一張當機畫面,上面寫著停止碼 KERNEL_MODE_HEAP_CORRUPTION。
您的裝置發生問題,需要重新啟動。
停止碼:KERNEL_MODE_HEAP_CORRUPTION
畫面長相依版本而異:微軟官方支援文件明講「停止碼錯誤的畫面顏色與訊息,會依你執行的 Windows 11 版本而異」,並把 24H2 以後與 23H2 及更早分列成兩種畫面——所以如果你在 24H2 / 25H2 上看到的是黑底、而且沒有你印象中那個「:(」哭臉,那是正常的,不是別的問題。
在事件記錄檔或當機檔裡,它的完整面貌是 0x0000013A,後面跟著四個參數,例如 BugCheck 13A, {11, ffff8e0..., ffff8e0..., 0}。
先講一件其他中文文章不太會說的事:微軟對這隻停止碼的官方著墨,少得不太尋常。 打開官方 Bug Check 0x13A 頁面,你只會看到兩節——參數表,以及一段 Resolution;它沒有「Cause(成因)」段落。對照隔壁同樣是記憶體結構損毀的 Bug Check 0x19(BAD_POOL_HEADER),官方那頁不但有 Cause,還另外給了 Driver Verifier 與 Windows 記憶體診斷兩個完整段落。
這個「有跟沒有」的落差,正是本文接下來要拿來當導航的東西——官方在 0x19 明講「如果這個 Bug Check 不定期出現,可能與實體記憶體故障有關,請執行 Windows 記憶體診斷」;這句話在 0x13A 的頁面上並不存在。所以網路上那些看到「記憶體損毀」四個字就叫你去測 RAM、換 RAM 的建議,至少在 0x13A 這隻停止碼上,沒有官方文件替它背書。
另外提醒一句:官方 0x13A 頁面最上方掛著 Important——「這篇文章是寫給程式設計師的」。這不是叫你別讀,而是誠實告訴你:這隻停止碼的官方資訊密度,本來就是給驅動開發者用的。所以下面的段落,我會把官方講了什麼、沒講什麼,分得清清楚楚。
🔎 問題根因:Parameter 1 有 21 種值,先分六個陣營
官方對四個參數的定義很乾脆:
| 參數 | 官方定義 |
|---|---|
| Parameter 1 | 偵測到的損毀型別(見下方清單) |
| Parameter 2 | 回報此次損毀的 heap 位址 |
| Parameter 3 | 偵測到損毀的位址 |
| Parameter 4 | 保留(Reserved) |
真正的線索全在 Parameter 1。官方列出 0x3 到 0x17 共 21 種值,一條一條讀完會頭昏,但把它們按「這句話在講什麼行為」歸類之後,其實只有六個陣營:
| 陣營 | Parameter 1 值 | 官方描述的重點 | 對你的意義 |
|---|---|---|---|
| ①寫過界 | 0x6、0x7、0x10 | 特徵符合緩衝區溢位(overrun)、緩衝區低溢(underrun);0x10 官方寫「內部狀態無效,可能是緩衝區溢位造成」 | 有程式碼寫超出自己配到的範圍 |
| ②釋放後亂用 | 0xB、0xD、0x11、0x12、0x17 | 特徵符合「釋放後繼續使用該區塊」;0x11 官方另列「可能是重複釋放(double-free)」;0xD/0x12/0x17 官方寫「use-after-free 或相鄰區塊溢位」 | 記憶體已經還回去了還在用,或還兩次 |
| ③表頭與清單壞了 | 0x3、0x4、0x5、0xE | 偵測到損毀的 entry header(單一 / 多個 / 大型配置);0xE 是 free list 以外的清單損毀 | 結構本身被寫爛,兇手不一定是誰 |
| ④呼叫端用錯 API | 0x8、0x9、0xC、0xF、0x13 | 把 free 區塊丟給只接受 busy 區塊的操作、參數無效、指定錯 heap、對 free 區塊做非法操作、傳入 NULL heap handle | 這是呼叫端的邏輯錯,通常較好認 |
| ⑤撞到上限 | 0x14、0x15 | 要求的配置大於目前配置上限;認可(commit)請求會超過目前 commit 上限 | 這不是「被寫壞」,是資源不夠 |
| ⑥內部錯誤 | 0xA、0x16 | 與配置型別相關的內部 heap 錯誤;0x16 官方寫「可能是位址錯誤或記憶體損毀造成」 | 官方講得最模糊的一群 |
陣營是本文依官方逐條描述所做的整理,官方文件本身並未做此分群;每一格的描述都對得回官方原文,分群只是幫你少讀 20 遍。
這張表最值錢的一格,是⑤。 官方把 0x14(配置超過上限)和 0x15(commit 超過上限)也放進 KERNEL_MODE_HEAP_CORRUPTION 這隻停止碼裡——但依官方對這兩個值的描述,它們講的是請求超出上限,而不是有人把結構寫壞。如果你的 Parameter 1 是 0x14 或 0x15,那麼把整晚花在 Driver Verifier 上抓「兇手驅動」,方向從一開始就偏了,該查的是誰在狂吃核心記憶體、以及分頁檔與 commit 上限的設定。
而①②③④(共 17 種值,佔 21 種裡的絕大多數)講的都是有程式碼在亂寫或誤用記憶體——這才是 Driver Verifier 派得上用場的地方。
(順帶一提,用 Parameter 1 分流方向的思路,在其他停止碼上同樣管用:PFN_LIST_CORRUPT(0x4E)的官方八種值也能分成驅動嫌疑與硬體嫌疑兩個陣營,值得對照著讀。)
🔬 底層機制:heap 不是 pool,搞混這件事會查錯方向
要理解 0x13A,得先分清楚 Windows 核心裡兩種不同的記憶體管理員:
- 集區(pool):核心元件與驅動最常用的核心記憶體來源。它壞掉時,對應的是 Bug Check 0x19(BAD_POOL_HEADER),官方定義是「pool header 損毀」(那隻停止碼的完整排錯另有專文:BAD_POOL_HEADER(0x19)藍屏怎麼修)。
- 堆積(heap):由 heap 管理員維護的另一套配置結構(官方
!heap文件說明它同時支援 segment heap 與 NT heap 兩種型別)。它在核心模式下壞掉時,對應的就是 0x13A——官方原文寫得很直接:「kernel mode heap manager 偵測到某個 heap 發生損毀」。
兩者都是「記憶體結構被寫壞」,但它們不是同一套結構、不是同一個管理員、官方給的處置建議也不一樣。這就是為什麼把 0x19 的偏方(先測 RAM)套到 0x13A 上,常常整晚白測。
接著是本文要老實告訴你的一個坑。 官方 0x13A 的 Resolution 只給了三樣東西:!analyze 擴充命令、!heap 擴充命令,以及〈Analyze Bug Check Blue Screen Data〉那篇通用指南。問題出在第二樣——翻開官方 !heap 自己的文件,Remarks 第一句就寫著:「標準的 !heap 命令用來顯示目前行程的 heap 資訊(這應該只用於使用者模式行程。系統行程應該改用 !pool 擴充命令)」。
也就是說:0x13A 是核心模式的 heap 損毀,官方卻在 Resolution 建議你用一個「其官方文件註明應用於使用者模式行程」的工具。這兩份文件擺在一起讀,對非驅動開發者來說就是打架。
本文的處理方式是如實呈現、不代微軟裁定:這是兩份官方文件之間的敘述張力,站長我沒有內部資訊可以斷定哪一句該優先。實務上的意義是——別把「跑 !heap 就會告訴我兇手」當成預期。真正對一般讀者投資報酬率最高的,是官方在兩份文件都推薦、且不需要你先搞懂 heap 型別的 !analyze -v,以及完全不必碰 WinDbg 的方法一與方法二。
(順帶一提,!heap 文件裡有個細節值得知道:-triage 是唯一能驗證低碎片堆積〔LFH〕損毀的方式,一般的 -v 驗證選項官方明講「無法偵測 LFH 損毀」。真要走 WinDbg 路線的人,別漏了這條。)
🛠️ 解決方案
依照風險由低到高排。請照順序做——方法一、二零風險而且是後面所有判斷的前提,跳過它們直接跑 Driver Verifier 是本文最不建議的做法。
方法一:先讀出四個參數(零風險,不必裝 WinDbg)
這一步不用任何額外工具,而且是整篇文章的前提。 沒有 Parameter 1,你就只能盲猜。
微軟官方〈Analyze Bug Check Stop Code Error Data〉明確列出三種取得四個參數的方式,其中第一種完全不需要偵錯器:「檢視事件檢視器裡的 Windows 系統記錄檔。該 bug check 的事件屬性會列出四個停止碼參數。」
1. Win + R → 輸入 eventvwr.msc → Enter
2. 左側展開 Windows 記錄檔 → 系統
3. 右側「篩選目前的記錄檔」,或直接找當機時間點附近、來源與 BugCheck 相關的錯誤事件
4. 點開事件,在描述或「詳細資料」裡就會看到四個參數
拿到 Parameter 1 之後,回上一節的六陣營表對號入座。是 0x14 / 0x15(⑤撞到上限,共 2 種)→ 你要查的是資源與 commit 上限,不是驅動;其餘 19 種 → 往方法二、方法三走(其中①②③④共 17 種官方明確描述為亂寫或誤用記憶體;⑥的 0xA / 0x16 官方講得較模糊,但 0x16 官方也寫了「可能是位址錯誤或記憶體損毀」,一樣從驅動查起最合理)。
另外兩種官方方式是:用偵錯器載入當機檔跑 !analyze(見方法四),或掛核心偵錯器到出問題的機器上。
方法二:盤點近期變更(零風險,期望值最高)
這一步之所以排第二,是有官方數字撐腰的。 微軟在〈Analyze Bug Check Stop Code Error Data〉裡寫:「據估計,大約四分之三的停止碼錯誤是由有問題的驅動程式所造成。」
⚠️ 誠實標註:這個「約四分之三」是官方對整體停止碼錯誤的估計,不是 0x13A 這隻的專屬統計;官方並未公布 0x13A 的成因分布。但配合上一節的觀察——21 種 Parameter 1 值裡有 17 種在描述「有程式碼亂寫或誤用記憶體」——把驅動當成第一嫌疑犯,是目前依官方資訊能做的最合理判斷。
實際動作:
1. 回想並列出藍屏前 1–2 週裝了什麼,尤其是這幾類會塞核心驅動的東西:防毒 / 端點防護、VPN、虛擬機器與虛擬光碟、螢幕錄影與串流工具、RGB 燈效與超頻工具、外接音效卡 / 擷取卡驅動
2. 可疑的先移除或回退版本(不是停用,是移除),一次動一項,每動一項觀察兩三天
3. 驅動只從裝置或晶片組廠商官網、Windows Update 取得——微軟官方支援文件在這件事上講得很直白:取得驅動更新最好的方式,是透過 Windows Update 自動取得;而若要手動更新,官方也明講「避免從製造商官方網站以外的任何網站下載驅動」。至於坊間「驅動一鍵更新」類工具,官方並未就其風險做過任何統計,以下是站長我個人的取捨:它們的來源與版本對應不透明,而核心模式驅動一旦裝錯版本,代價就是你正在讀這篇文章,所以我不用
4. 移除前先建立系統還原點
如果藍屏在你移除某支軟體後停了,恭喜,你不必碰後面的方法三。
方法三:Driver Verifier 讓兇手驅動現形(⭐⭐⭐ 高風險)
⚠️ 再說一次官方警語:「執行 Driver Verifier 可能導致電腦當機」、「只在你用來測試與偵錯的電腦上執行」、「必須是 Administrators 群組成員」。這不是嚇唬你,是官方寫在文件最上方的前提條件。 資料沒備份、BitLocker 金鑰不在手上,就到方法二為止。
注意適用範圍:Parameter 1 = 0x14 / 0x15(⑤撞到上限)不適用這條路。
官方步驟(依 Microsoft Learn〈Driver Verifier〉;這套工具的完整選項與進階用法,站內另有專篇整理:Driver Verifier 完整使用教學):
1. 以系統管理員身分開啟命令提示字元
2. 輸入 verifier 開啟 Driver Verifier Manager
3. 選 Create standard settings(預設工作)→ Next
4. 在 Select what drivers to verify 選擇驅動範圍——這一步是關鍵,別直接選全部
官方對四種選取方案的建議寫得很清楚:
| 選項 | 官方建議用途 |
|---|---|
| Automatically select unsigned drivers | 用於不要求驅動簽章的 Windows 版本 |
| Automatically select drivers built for older versions of Windows | 測試舊驅動與新版 Windows 的相容性 |
| Automatically select all drivers installed on this computer | 涵蓋率最大,但官方明講可能耗盡 Special Pool 與部分資源追蹤可用的資源,也會明顯拖慢系統效能 |
| Select driver names from a list | 官方寫「大多數情況下,你會想指定要測哪些驅動」;若要盡量爭取偵測記憶體損毀的資源,一次只選一支——官方明講 Special Pool 與 I/O Verification 選項一次針對一支驅動時最有效 |
5. 選 Finish,重新開機
指令列等價做法(官方範例,針對單一驅動):
verifier /standard /driver myDriver.sys📌 官方另有一則版本註記:在 Windows build 20150 到 25126 之間,若選取
ntoskrnl可能收到 invalid state 錯誤;解法是取消選取ntoskrnl,或升級到 25126 之後的版本。
接下來會發生什麼:官方說明——Driver Verifier 一旦偵測到違規,會產生一個 bug check 把電腦停下來,目的是給你最多的除錯資訊。此時你看到的停止碼通常不再是 0x13A,而是 0xC4(DRIVER_VERIFIER_DETECTED_VIOLATION);官方另列的常見碼還有 0xC1(SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION)、0xC6、0xC9、0xD6、0xE6。這是好消息——代表兇手當場被逮,新的當機檔裡會直接指出是哪一支 .sys。
抓到之後一定要關掉。 Driver Verifier 是短期抓兇工具,不是長期開著的:
verifier /reset然後重新開機。查目前狀態與設定的官方指令分別是 verifier /query 與 verifier /querysettings。
方法四:WinDbg —— 該對 !analyze 與 !heap 有什麼期待
如果你願意裝偵錯器,官方在 0x13A 的 Resolution 給的就是這兩支:
!analyze -v:官方在多份文件重複推薦的起手式,會顯示 bug check 資訊並協助判斷根因;Driver Verifier 文件也明講,加-v是為了顯示額外資訊以協助辨識出問題的驅動。這是投資報酬率最高的一條命令。!heap:官方說它可顯示 heap 使用資訊、控制 heap 管理員中的中斷點、偵測洩漏的 heap 區塊、搜尋 heap 區塊或顯示 page heap 資訊;無參數執行會列出所有 heap 與其型別。但請回頭看上一節那個坑——官方!heap文件自己註明標準用法針對使用者模式行程、系統行程應改用!pool。
站長我的建議是:非驅動開發者走到 !analyze -v 為止,把它指出的可疑模組交叉比對方法二的「近期變更清單」,通常就夠你做決定了。真的要深挖 heap 結構,那已經是驅動開發與逆向的守備範圍,不是一篇教學能讓你速成的——這句話我寧可講得難聽,也不想給你不切實際的期待。
✅ 驗證修復結果
判斷「真的修好」與「暫時沒事」的差別,在於你有沒有拿到因果。
1. 確認 Driver Verifier 已關閉:verifier /query 應顯示沒有正在驗證的驅動;若你跑過方法三,務必確認 verifier /reset 已生效並重開機
2. 回到事件檢視器:觀察期內系統記錄檔不再出現新的 bug check 事件
3. 重現原本的操作:當初什麼情境下藍屏,就回去做那件事——插拔那台外接裝置、開那套軟體、跑那個工作負載
4. 給它一段真實的觀察期:官方並未公布 0x13A 的發生頻率或規律性,所以「一天沒事」本身不構成任何證據。站長我的做法是至少觀察一週,而且期間不要同時又裝新東西——不然下次再藍屏,你又分不清是誰的錯
最理想的驗證:你能說出「因為我移除了 X,所以不再藍屏」,而不是「我做了七件事,現在好像好了」。
🔙 萬一翻車:回退步驟
情境一:跑了 Driver Verifier,開機就藍屏、進不了桌面
這是 Driver Verifier 最常見的翻車情境,也是官方警告「可能導致電腦當機」的具體樣貌。
1. 連續強制關機兩到三次(開機看到 Windows 標誌就長按電源鍵),觸發自動修復
2. 進入 疑難排解 → 進階選項 → 啟動設定 → 重新啟動
3. 按 F4 進入安全模式(或 F5 帶網路的安全模式)
4. 開啟命令提示字元(系統管理員),執行 verifier /reset
5. 重新開機
情境二:安全模式也進不去
1. 用另一台電腦做 Windows 安裝 USB,從它開機
2. 選 修復您的電腦 → 疑難排解 → 命令提示字元
3. 若 BitLocker 已啟用,這裡會要求復原金鑰——這就是前面反覆要你先備好金鑰的原因
4. 在此環境中回復到先前的還原點,或依微軟官方指引處理
情境三:移除某支驅動後裝置不能用
1. 從裝置或晶片組廠商官網重新下載該驅動的穩定版(不要用一鍵更新工具)
2. 或用系統還原回到你動手前建立的還原點
💡 總結:預防再次發生
站長我看 0x13A 的習慣,是先問 Parameter 1,再問其他所有事。理由不是玄學,是官方文件本身的結構就這樣寫:整頁 0x13A 連 Cause 段都沒有,唯一給你的實質線索,就是那張 21 種值的 Parameter 1 表。先讀它,你至少能立刻分出「有人在亂寫記憶體」(①②③④共 17 種)還是「撞到上限」(⑤共 2 種)——這兩條路的處置方式完全不同,而這個判斷不花你一毛錢、五分鐘就能做完。
反過來,這隻停止碼上最容易白花的錢,就是看到「記憶體損毀」四個字就先去買兩條 RAM。我要再強調一次那個對照:官方在 0x19 明白寫了「若不定期出現,可能與實體記憶體故障有關,請跑 Windows 記憶體診斷」;這句話在 0x13A 的官方頁面上不存在。 這不代表你的記憶體一定沒事(記憶體真的壞掉時什麼怪事都可能發生),但它代表——在 0x13A 上,把測 RAM 當第一步,沒有官方文件替你背書。
給三個實用習慣:
一、驅動只從裝置或晶片組廠商官網、Windows Update 拿——官方支援文件本身就寫著「避免從製造商官方網站以外的任何網站下載驅動」,而取得更新最好的方式是 Windows Update。依官方估計,約四分之三的停止碼錯誤(全體,非 0x13A 專屬)來自有問題的驅動,驅動的來源乾不乾淨因此值得你講究。
二、裝任何含核心驅動的軟體前先設好還原點,而且一次只裝一樣。這個習慣的價值在藍屏那天才會顯現:你能立刻列出「最近變更清單」,而不是對著一台裝了二十樣東西的電腦發呆。
三、平時就把記憶體傾印設好、BitLocker 金鑰存好。真要除錯時你手上才有 dump;要走方法三時,才有翻車的退路。
最後老話一句:0x13A 是核心在結構爛掉之前踩了煞車。 比起讓一支亂寫記憶體的驅動默默把你的資料寫壞,這張藍屏其實是站在你這邊的。
❓ 常見問題
Q:KERNEL_MODE_HEAP_CORRUPTION 是不是代表我的記憶體壞了要換?
不能這樣直接推論。微軟官方對 0x13A 的定義是「核心模式 heap 管理員偵測到 heap 損毀」,而 Parameter 1 的 21 種值裡,絕大多數描述的是緩衝區溢位、釋放後再使用、重複釋放、API 用錯這類程式碼層級的行為。更關鍵的是:官方在同性質的 0x19 頁面明白建議「不定期出現時跑 Windows 記憶體診斷」,但在 0x13A 頁面沒有這句話。 先讀 Parameter 1、先盤點近期驅動變更,再談硬體。
Q:0x13A 跟 0x19(BAD_POOL_HEADER)差在哪?
壞掉的東西不一樣。0x19 是「pool(集區)header 損毀」,0x13A 是「heap(堆積)損毀」——核心裡這是兩套不同的配置結構、由不同的管理員維護。官方給的處置建議也不同:0x19 那頁有 Cause 段、有 Driver Verifier 段、還有 Windows 記憶體診斷段;0x13A 那頁只有參數表和一段 Resolution(!analyze / !heap / 通用指南),連 Cause 都沒有。
Q:官方叫我用 !heap,可是我跑了看不懂也抓不到兇手,是我的問題嗎?
不完全是。這裡確實有一個文件之間的張力:0x13A 的 Resolution 建議 !heap,但官方 !heap 文件自己註明「標準的 !heap 命令……應該只用於使用者模式行程;系統行程應改用 !pool」。站長我沒有內部資訊可以裁定哪一句優先,只能如實告訴你:別把「跑 !heap 就會指出兇手」當成合理期待,!analyze -v 才是官方在多份文件都推薦、也比較實際的起手式。
Q:Parameter 1 是 0x14 或 0x15,也要跑 Driver Verifier 嗎?
依官方對這兩個值的描述,它們講的是「請求超過配置上限」與「commit 請求會超過目前 commit 上限」,也就是資源撞到天花板,而不是結構被寫壞。這種情況跑 Driver Verifier 去抓「亂寫記憶體的驅動」,方向從一開始就偏了;該查的是誰在大量吃核心記憶體、以及分頁檔與 commit 上限的設定。
Q:Driver Verifier 開了以後電腦變超慢、還一直當,正常嗎?
正常。它是刻意加重檢查、一抓到違規就故意觸發 bug check 的工具,官方也明講「執行 Driver Verifier 可能導致電腦當機」、且只該在測試用的機器上跑;官方還特別提到,選「驗證所有驅動」會耗盡 Special Pool 資源並影響效能——這也是為什麼本文要你一次只選一支。抓到之後務必 verifier /reset 並重開機。
Q:我什麼驅動都沒裝,怎麼也會跳 0x13A?
「沒裝驅動」通常是錯覺——防毒、VPN、虛擬機器、虛擬光碟、錄影串流、RGB 燈效、擷取卡,這些軟體都會塞核心模式驅動。另外 Windows Update 推送的裝置驅動也算。先跑方法一拿到 Parameter 1,再用方法二把近期變更列出來,你會發現名單通常比想像中長。
📎 參考資料來源
📖 第一級|廠商官方:
- Microsoft Learn:Bug check 0x13A KERNEL_MODE_HEAP_CORRUPTION — 2026-07-16 查證(停止碼值 0x0000013A、「kernel mode heap manager 偵測到 heap 損毀」之定義、四個參數定義、Parameter 1 之 0x3–0x17 共 21 種值與各自官方描述、Resolution 僅列
!analyze/!heap/ Analyze Bug Check Blue Screen Data、頁面無 Cause 段、頁首 Important「本文寫給程式設計師」) - Microsoft Learn:Bug Check 0x19 BAD_POOL_HEADER — 2026-07-16 查證(停止碼值 0x00000019「pool header 損毀」、Cause 段、Resolution 段、Driver Verifier 段、Windows Memory Diagnostics 段及「若此 Bug Check 不定期出現,可能與實體記憶體故障有關」一句——本文用於與 0x13A 之官方處置建議對照)
- Microsoft Learn:!heap(WinDbg) — 2026-07-16 查證(「支援 segment heap 與 NT heap、無參數列出所有 heap 與其型別」、Remarks「標準 !heap 命令用於目前行程……只該用於使用者模式行程;系統行程應改用 !pool」、
-triage為驗證 LFH 損毀之唯一方式、-v無法偵測 LFH 損毀) - Microsoft Learn:Analyze bug check (stop code error) data — 2026-07-16 查證(取得四個停止碼參數之三種方式、「檢視事件檢視器 Windows 系統記錄檔,事件屬性會列出四個停止碼參數」、「據估計約四分之三的停止碼錯誤由有問題的驅動程式造成」、
!analyze說明) - Microsoft Learn:Driver Verifier — 2026-07-16 查證(Important 三句警語、verifier.exe 內建於 %WinDir%\system32 且 Windows 10 S 不含、Create standard settings 步驟、四種驅動選取方案之官方建議與「選全部會耗盡 Special Pool 資源並影響效能」「Special Pool 與 I/O Verification 一次一支最有效」、
verifier /standard /driver、/reset、/query、/querysettings、違規觸發 bug check 通常為 0xC4 及 0xC1/0xC6/0xC9/0xD6/0xE6、!analyze -v、build 20150–25126 選取 ntoskrnl 之 invalid state 註記) - Microsoft Learn:Windows 11 發行資訊 — 2026-07-16 查證(25H2 = OS build 26200、24H2 = OS build 26100、24H2 家用與專業版服務終止日 2026-10-13)
- Microsoft 支援:疑難排解 Windows 非預期重新啟動與停止碼錯誤 — 2026-07-16 查證(「停止碼錯誤的畫面顏色與訊息會依 Windows 11 版本而異」、24H2 以後與 23H2 以前分列之兩種畫面、「Your device ran into a problem and needs to restart.」訊息)
- Microsoft 支援:透過裝置管理員更新 Windows 驅動程式(KB 4028443) — 2026-07-16 查證(「取得驅動更新最好的方式是透過 Windows Update 自動取得」、手動更新須先自裝置製造商網站下載、「避免從製造商官方網站以外的任何網站下載驅動」、回復驅動〔Roll Back Driver〕步驟)
⚠️ 本文核心事實以第一級官方文件為準。本文為依微軟官方文件整理之深度解析(非站長第一手實測);Parameter 1 的六陣營分群為本文依官方逐條描述所做的整理、官方並未如此分類,停止碼參數與工具行為請以你機器上的實際版本與當機檔為準。
📅 本文查證戳記:2026-07-16 依據 Microsoft 官方 Bug Check 0x13A、Bug Check 0x19、!heap、Analyze Bug Check Data 與 Driver Verifier 文件撰寫,適用 Windows 10 / 11(含 24H2、25H2)。若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。