PFN_LIST_CORRUPT 0x4E 藍屏怎麼修?讀參數分流真兇

一句話答案:PFN_LIST_CORRUPT(0x4E)代表 Windows 核心在維護「頁框編號(PFN)清單」時發現帳目對不上;依微軟官方 Bug Check 文件,最常見的元兇是驅動程式傳了壞掉的 MDL(例如對同一份清單呼叫兩次 MmUnlockPages),實體記憶體故障只是其中一種可能。先看藍屏或當機檔裡的 Parameter 1,官方八種值可分成「驅動嫌疑」與「硬體嫌疑」兩個陣營,再據此決定要開 Driver Verifier 還是先測記憶體。

🧰 開始前的準備

適用系統:Windows 10 全版本、Windows 11(含 24H2 / 25H2)。0x4E 是很老的停止碼,本文所述的核心 API 自 Windows 2000 起即存在
權限需求:系統管理員(改記憶體傾印設定、開 Driver Verifier 都需要;微軟官方明列「必須是本機 Administrators 群組成員才能使用 Driver Verifier」)
需要工具:系統內建的 Windows 記憶體診斷、Driver Verifier(verifier.exe,微軟官方說明多數 Windows 版本已內建於 %WinDir%\system32\、不另外提供下載)、事件檢視器;想讀當機檔再裝 WinDbg
前置設定:想自己抓兇手,請先把「自動重新啟動」關掉、記憶體傾印設成「自動」或「核心」,否則當機當下什麼線索都留不下來
預計耗時:約 20–40 分鐘(視要不要跑 Driver Verifier 與記憶體測試而定)

⚠️ 動手前先讀這段(⭐⭐⭐ 高風險):本文方法三會用到 Driver Verifier。微軟官方文件在頁面最上方就用 Important 標註兩句話:「執行 Driver Verifier 可能導致電腦當機」、「只在你用來測試與偵錯的電腦上執行 Driver Verifier」。設定不當可能讓你一開機就藍屏、進不了桌面。動手前先確認:重要資料已備份、BitLocker 復原金鑰在手、而且你知道怎麼進安全模式關掉它(做法見文末〈萬一翻車〉)。這不是嚇唬,是官方寫在文件裡的前提條件——符合任一「停止條件」就先停,別硬做。

🔍 症狀描述與錯誤訊息

先確認你遇到的是不是這隻。PFN_LIST_CORRUPT 的典型畫面,是電腦用到一半突然當機、跳出當機畫面,底下寫著:

🙁 你的裝置發生問題,需要重新啟動⋯⋯
停止碼(Stop code):PFN_LIST_CORRUPT

📌 畫面長相會隨版本不同:微軟官方說明明講「停止碼錯誤的畫面顏色與訊息會依你執行的 Windows 11 版本而異」,並分列「Windows 11 24H2 以後」與「Windows 11 23H2 以前」兩組畫面——舊版是藍底、開頭有 :(,24H2 起改為黑底、版面也不同。你看到的字句可能和上面不完全一樣,以停止碼文字 PFN_LIST_CORRUPT 或 0x0000004E 為準。

有時只顯示十六進位代碼 0x0000004E(簡寫 0x4E),有時兩者一起出現。

先講清楚一件事:微軟官方文件並沒有列出 0x4E 的觸發情境,也沒有給任何發生頻率的統計。 不過從官方寫的成因往回推,有一類動作在機制上落在射程內——插拔 USB 裝置、錄影或串流、掛載虛擬磁碟、跑備份、大量讀寫檔案。它們的共通點是都會讓某支驅動去「鎖住」一段實體記憶體做 I/O、事後再「解鎖」,而 0x4E 正是核心在這個鎖定/解鎖的帳目上抓到對不上(機制詳見下一節)。

這是依官方成因所做的機制推論,不是官方統計,也不是說做這些事就會當機。但有一條線索的價值確實高:「藍屏前你剛做了什麼、剛裝了什麼」——請先記下來,後面方法二整套都靠它。

🔎 問題根因:Parameter 1 會告訴你該查誰

先給直接結論:依微軟官方 Bug Check 文件,0x4E 表示「頁框編號(PFN)清單已損毀」,而這個錯誤「通常是由驅動程式傳遞了一份不正確的記憶體描述元清單(MDL)所造成」;官方甚至直接舉例:「驅動程式可能用同一份清單呼叫了兩次 MmUnlockPages」。

請注意官方用的是 *typically*(通常)。也就是說,0x4E 的預設嫌疑犯是驅動,不是記憶體條。這和多數中文搜尋結果給你的「跑 SFC、換一條 RAM 試試」剛好相反——那套做法碰巧會解掉一部分案例,但你會在錯誤的方向上花掉最多錢與時間。

真正該做的第一件事,是讀 Parameter 1。官方文件明訂:「*Parameter 1* 表示違規的類型,其餘參數的意義取決於 *Parameter 1* 的值」。以下是官方完整的八種值,對照你在藍屏畫面或 WinDbg !analyze -v 看到的第一個參數:

Parameter 1	官方定義的錯誤原因	白話解讀
0x01	清單前端(ListHead)已損毀	PFN 清單的頭被寫壞了
0x02	正在移除的清單項目已損毀	要從清單拿掉的那一項,內容對不上
0x06	硬體 PTE 和/或原型 PTE 資料結構已損毀	官方明指:可能由硬體單一位元錯誤、DMA 傳輸中斷等造成
0x07	驅動程式解除鎖定某頁面的次數超過鎖定的次數	經典的「解鎖比鎖定多」——驅動的錯
0x8D	page-free list 已損毀	官方明指:此錯誤碼很可能表示硬體問題(Parameter 2 給出狀態不一致的那個頁框編號)
0x8F	free 或 zeroed 頁面清單標頭已損毀	清單標頭被寫壞
0x99	PTE 或 PFN 損毀	分頁表項目或頁框編號本身被改壞
0x9A	驅動程式嘗試釋放仍鎖定於 I/O 的頁面	驅動在 I/O 還沒做完就把頁面還回去——驅動的錯

這張表最值錢的地方,是它能幫你分流。 把八個值分成三個陣營:

驅動嫌疑重(先查驅動,別急著拆機):0x07、0x9A。官方對這兩個值的描述直接點名 driver 的行為錯誤——一個是解鎖次數多於鎖定,一個是頁面還鎖在 I/O 就被釋放。看到這兩個,Driver Verifier 是你的主戰場。
硬體嫌疑重(先測記憶體):0x8D、0x06。官方對 0x8D 寫的是「most likely indicates a hardware issue(很可能表示硬體問題)」,對 0x06 則明列硬體單一位元錯誤與 DMA 傳輸中斷為可能成因。看到這兩個,先老實測 RAM。
兩邊都有可能(依 §方法二的時間線判斷):0x01、0x02、0x8F、0x99。這幾個只說「某個結構被寫壞了」,沒說是誰寫的。壞記憶體會寫壞它,亂寫記憶體的驅動也會寫壞它——這時就回到最實用的線索:藍屏是不是從某次安裝/更新之後才開始。

0x4E Parameter 1 分流表:0x07/0x9A 指向驅動、0x8D/0x06 指向硬體、0x01/0x02/0x8F/0x99 未指明 — 0x4E Parameter 1 分流表(來源:Microsoft Learn Bug Check 0x4E 官方參數表,2026-07-16 查證)

要補一句常見的誤會:0x4E 不等於 0x1A。MEMORY_MANAGEMENT(0x1A)涵蓋的是整個記憶體管理員的各種嚴重違規,官方的 Parameter 1 表洋洋灑灑列了三、四十種(其中確實也有和 PFN 相關的,例如 0x9696 的「PFN 連結損毀」、0x403 的「分頁表與 PFN 不同步」);而 0x4E 專指 PFN 清單這個資料結構本身的鏈結帳目出錯,範圍窄得多、指向性也強得多。兩者都可能跟壞掉的實體記憶體有關,但切入點不同,別把兩篇的做法混著用——想深入 0x1A 的參數判讀,請看〈MEMORY_MANAGEMENT(0x1A)藍屏怎麼修?站長教你讀懂停止碼參數揪真兇〉。

🔬 底層機制:PFN 清單是什麼,又是怎麼被寫壞的?

要理解 0x4E,先理解 Windows 怎麼記帳。

實體記憶體被切成一頁一頁(x64 上通常是 4KB),每一頁都有一個編號,叫做 PFN(Page Frame Number,頁框編號)。核心的記憶體管理員得隨時知道每一頁現在的狀態:是誰在用、被引用幾次、是空閒的、還是已經歸零可以直接發出去的。這些帳目就記在一組串起來的清單裡——這就是「PFN 清單」。

關鍵在於:當驅動程式要對一段記憶體做 I/O(例如把資料 DMA 到你的網卡、音效卡、SSD),它必須先「鎖住」那些實體頁面,不然記憶體管理員可能在傳輸途中把那些頁面換出去、挪作他用,資料就爛了。這個鎖定/解鎖是成對的動作,靠一個叫 MDL(Memory Descriptor List,記憶體描述元清單) 的結構描述哪些頁面被鎖住。

微軟官方 DDI 文件把這對 API 的契約寫得很清楚:MmUnlockPages 用來「解鎖由指定 MDL 所描述的實體頁面」,而且「該 MDL 所描述的記憶體必須先前已經由 MmProbeAndLockPages 呼叫鎖定過」。

問題就出在這裡。每一頁都有一個參考計數(reference count / share count)在記「現在有幾個人鎖著我」。鎖一次加一,解一次減一。如果某支驅動:

1. 對同一份 MDL 解鎖了兩次(官方在 0x4E 的成因段落直接舉的就是這個例子),那個計數就會被減成不該有的值;

2. 或在 I/O 還沒完成、頁面還鎖著時就把它釋放回去(對應 Parameter 1 = 0x9A);

3. 或解鎖的次數多過鎖定的次數(對應 Parameter 1 = 0x07)。

核心下一次巡到這條清單、發現「這一頁的狀態跟帳目對不上」時,它不會賭一把繼續跑——因為記憶體管理員的帳目一旦錯亂,接下來可能把還在用的頁面發給別人,造成無聲的資料毀損。它選擇立刻停機,這就是 0x4E。

換句話說,0x4E 這張藍屏其實是核心在幫你踩煞車。討厭的是,當機當下呼叫堆疊上的那支驅動,未必是兇手——很可能是前一支驅動早就把帳記錯了,只是由後來這支剛好巡到的倒楣鬼引爆。這正是為什麼你需要 Driver Verifier:讓違規者在犯案當下就當機,而不是等到事後。

至於硬體那條路:實體記憶體如果有壞的位元,或某張介面卡的 DMA 傳輸出錯、寫到不該寫的實體位址,一樣會把 PFN 清單或 PTE 的內容改壞。這就是官方為什麼在 0x06 註明「hardware single bit errors, broken DMA transfers」、在 0x8D 註明「most likely indicates a hardware issue」的原因。同一張藍屏、兩條完全不同的追查路線,分岔點就在 Parameter 1。

🛠️ 解決方案

⚠️ 方法三為 ⭐⭐⭐ 高風險操作,請先讀完上方警語與文末〈萬一翻車〉再動手。

方法一:先關自動重啟、設好傾印,把參數看清楚

這一步零風險,而且是後面所有判斷的前提。 沒有 Parameter 1,你就只能盲猜。

1. 按 Win + R,輸入 sysdm.cpl,按 Enter。

2. 切到「進階」索引標籤 → 「啟動及修復」的「設定」。

3. 取消勾選「自動重新啟動」(這樣藍屏會停在畫面上,你才抄得到停止碼)。

4. 「寫入偵錯資訊」選「自動記憶體傾印」或「核心記憶體傾印」,確認路徑(預設 %SystemRoot%\MEMORY.DMP;小型傾印在 %SystemRoot%\Minidump)。

5. 按確定,下次藍屏時把畫面上的停止碼與四個參數抄下來,或事後用 WinDbg 讀當機檔。

看不懂當機檔沒關係——!analyze -v 這一行就能吐出絕大部分你要的資訊。微軟官方在 0x4E 文件的最後也是這樣建議的:「如果核心偵錯工具可供使用,請檢查堆疊追蹤:!analyze 偵錯延伸模組會顯示錯誤檢查的相關資訊,並有助於判斷根本原因」。完整操作見〈WinDbg 藍畫面 minidump 分析教學 2026|三行輸出找出真兇〉。

方法二:回想「藍屏前你動了什麼」——先處理近期驅動

這一步零風險,而且期望值最高。 既然官方說 0x4E 的成因「通常」是驅動傳了壞掉的 MDL,從驅動查起就是命中率最高的方向。(注意:這是依官方的成因分布推的方向,官方並沒有提供各種處置的解決率數字。)

回想藍屏是不是從某個時間點之後才開始,對照這幾類最常見的嫌疑犯——它們的共通點是都會鎖記憶體做 I/O:

顯示卡 / 音效卡 / 網卡(含 Wi-Fi)驅動,尤其是剛更新過的
儲存控制器、RAID、NVMe 驅動
VPN、防毒、虛擬光碟、虛擬機器、螢幕錄影 / 串流工具(這幾類都會塞核心模式驅動)
USB 週邊的自家驅動(擷取卡、外接音效介面、印表機)
「驅動一鍵更新」工具灌進去的、來路不明的版本

處理原則:一次只動一項,動完觀察。優先做的是回退到裝置或晶片組廠商官網的穩定版驅動(不是「最新版」,是你出事前那一版),或直接把最近新增的那個核心模式軟體移除。有還原點就用還原點。

📌 事件檢視器可以幫你抓時間線:Win + X → 事件檢視器 → Windows 記錄 → 系統,依「錯誤」篩選,對照藍屏發生的時間點前後,常能看到某個驅動或裝置反覆報錯。

方法三:用 Driver Verifier 揪出兇手驅動(⭐⭐⭐)

如果方法二找不到源頭、又反覆發作,這是唯一能「指名道姓」的路。Driver Verifier 的原理就是刻意加重檢查,讓違規的驅動在犯案當下立刻當機,而不是等到帳目爛掉才爆。

微軟官方的操作步驟是:以系統管理員身分開啟命令提示字元,輸入 verifier 開啟 Driver Verifier Manager,選「Create standard settings」→ 下一步 → 選擇要驗證哪些驅動 → 完成後重新啟動。

關鍵是「選哪些驅動」這一步,別直接選全部。 官方文件對各選項的建議寫得很明白:

選項	官方建議用途
自動選取未簽署的驅動程式	用於不強制驅動簽章的 Windows 版本測試
自動選取為舊版 Windows 建置的驅動程式	測試舊驅動與新版 Windows 的相容性
自動選取這台電腦上安裝的所有驅動程式	涵蓋率最大,但官方明講可能耗盡 Special Pool 與資源追蹤可用資源,並對系統效能造成不良影響
從清單選取驅動程式名稱	官方建議的常態做法——多數情況你會想指定要測哪些驅動

官方在 Special Pool 文件裡講得更直接:「如果啟用了 Special Pool 功能,不建議同時驗證多支驅動程式」,因為 Special Pool 容量有限,配置不到時系統會默默改用一般集區、而且不回報錯誤,你的檢查就悄悄失效了。所以請把方法二列出的嫌疑名單,一次挑一到兩支來驗。

命令列版本(對 myDriver.sys 套用標準設定):

verifier /standard /driver myDriver.sys

設定完要重新開機才生效。接著就照平常的方式用電腦,特別是去重現當初會藍屏的那個動作(插那支 USB、開那個錄影軟體、跑那個備份)。

接下來會發生什麼: 如果 Driver Verifier 抓到違規,它會故意觸發一個 bug check 把電腦停下來——官方說明這是為了給你最多的除錯資訊。此時你看到的停止碼通常不再是 0x4E,而是 0xC4(DRIVER_VERIFIER_DETECTED_VIOLATION),也可能是 0xC1(SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION)、0xC6、0xC9、0xD6、0xE6 這幾個常見的 Verifier 專屬碼。這是好消息:代表兇手當場被逮,而且新的當機檔裡會直接寫出是哪一支 .sys。用 !analyze -v 讀它就對了。

查目前狀態與設定:

verifier /query

verifier /querysettings

抓到之後一定要關掉。 Driver Verifier 是短期抓兇工具,不是長期開著的:

verifier /reset

關掉後要重新開機。想更完整地了解各選項與判讀方式,見〈Driver Verifier 完整使用教學 2026|揪出偷偷作亂的驅動程式〉。

方法四:測實體記憶體(Parameter 1 = 0x8D / 0x06 請直接從這裡開始)

如果你的 Parameter 1 落在硬體陣營,或驅動那條路全部走完仍反覆發作,就老實測記憶體。微軟官方在 0x1A(同為記憶體管理類停止碼)的解決段落也明白建議:「執行 Windows 記憶體診斷工具來檢查影響實體記憶體模組的問題」。

1. 按 Win + R,輸入 mdsched.exe,按 Enter。

2. 選「立即重新啟動並檢查問題」,電腦會重開並在開機前跑測試。

3. 測完自動進系統,結果在事件檢視器 →「Windows 記錄」→「系統」,找來源為 MemoryDiagnostics-Results 的事件。

內建工具是初篩,通過不代表記憶體一定沒問題;要深驗請跑更長時間的第三方工具。兩者的定位差異與實務取捨,見〈電腦常當機/藍屏?用 Windows 內建「記憶體診斷」工具檢查 RAM 問題〉。

📌 測記憶體時的三個實務重點:①先把 XMP / EXPO 超頻設定關掉,用 JEDEC 預設時脈再測一次——記憶體「體質不夠」跑不動超頻參數,症狀和壞條幾乎一樣;②多條記憶體請單條輪流測,才知道是哪一條;③把金手指擦乾淨、重新插拔,接觸不良造成的偶發位元錯誤,比你想的常見。

方法五:排除系統檔與更新層面的問題

若前面都無所獲,再做這些通用處理(它們解不掉真正的驅動 bug,但能排除掉一些變因):

以系統管理員身分執行 sfc /scannow,修復損毀的系統檔案。
移除最近安裝的 Windows 更新(設定 → Windows Update → 更新記錄 → 解除安裝更新),觀察是否停止發作。
使用還原點回到藍屏開始前的狀態。

✅ 驗證修復結果

修好了沒,別只看「今天沒當」。至少確認這三件事:

1. Driver Verifier 已確實關閉:命令列跑 verifier /querysettings,應顯示沒有正在驗證的驅動;沒關掉的話你之後看到的當機都是它製造的。

2. 重現原本的觸發情境:當初是插擷取卡才當,就再插一次;是跑備份才當,就再跑一輪完整備份。不敢重現,就等於沒驗證。

3. 觀察期至少涵蓋一個完整使用週期:0x4E 常是「特定動作才觸發」,建議至少正常使用 3–7 天,並回頭看事件檢視器的系統記錄有沒有新的錯誤事件、%SystemRoot%\Minidump 有沒有新的當機檔。

🔙 萬一翻車:回退步驟

情境一:開了 Driver Verifier 後,一開機就藍屏、進不了桌面

這是最常見的翻車,而且有解,別急著重灌:

1. 連續強制關機兩到三次(開機到出現 Windows 標誌時長按電源鍵),觸發「自動修復」。

2. 進入「疑難排解」→「進階選項」→「啟動設定」→ 重新啟動 → 按 4 或 F4 進入安全模式(安全模式只載入最基本的驅動,通常不會踩到被驗證的那一支)。

3. 在安全模式開命令提示字元(系統管理員),執行 verifier /reset。

4. 重新開機。

情境二:連安全模式都進不去

1. 用同樣方式進入「進階選項」,選「命令提示字元」。

2. 執行 verifier /reset 後重新開機。

3. 仍不行,選「系統還原」回到啟用 Driver Verifier 之前的還原點。

⚠️ 這一步可能要求 BitLocker 復原金鑰。這就是為什麼開工前要先確認金鑰在手——臨時找不到金鑰,救援會直接卡死在這裡。金鑰可到 account.microsoft.com/devices/recoverykey 用你的 Microsoft 帳戶查詢。

情境三:回退驅動 / 移除更新後反而更糟

回到「進階選項」→「系統還原」,選回你動手之前的那個還原點。這也是為什麼方法二強調「一次只動一項」:動了五件事才發現更糟,你根本不知道要退哪一件。

💡 總結:預防再次發生

站長我讀這類停止碼的習慣,是先問 Parameter 1 是多少,而不是先問「你記憶體幾條」。理由很單純:官方文件已經把分流依據寫在表格裡了——0x07 和 0x9A 直接點名是驅動的鎖定/解鎖行為出錯,0x8D 和 0x06 才明講指向硬體。這一個問題就能把追查範圍砍掉一半,而它不花你一毛錢。反過來說,一看到「記憶體」三個字就先去買兩條 RAM,是這隻停止碼上最容易白花的錢——因為依官方描述,驅動才是預設嫌疑犯。

當然,反過來也要誠實:如果你的 Parameter 1 就是 0x8D,官方說「很可能是硬體問題」,那就別在驅動上耗,老實把記憶體測到底、把 XMP 關掉再測一次。這隻停止碼的價值,就在於它會告訴你該往哪邊走——聽它的。

預防上給三個實用習慣:一、驅動只從裝置或晶片組廠商官網、Windows Update 拿,遠離「驅動一鍵更新」這類工具,它們是各種核心層藍屏的常客;二、裝任何含核心驅動的軟體(防毒、VPN、虛擬光碟、虛擬機器、錄影串流)前先設好還原點,出事好回頭;三、平時就把記憶體傾印設好、BitLocker 金鑰存好,真要除錯時你手上才有 dump、翻車時也有退路。最後老話一句:0x4E 看起來嚇人,但它其實是核心在帳目爛掉前幫你踩了煞車——比起讓它默默寫壞你的資料,這張藍屏是好事。

❓ 常見問題

Q:PFN_LIST_CORRUPT 是不是代表我的記憶體壞了要換?

不一定,而且依官方描述,這通常不是第一嫌疑。微軟 Bug Check 0x4E 文件明寫「此錯誤通常是由傳遞不正確的記憶體描述元清單的驅動程式所造成」。只有 Parameter 1 = 0x8D(官方註明「很可能表示硬體問題」)或 0x06(官方列出硬體單一位元錯誤、DMA 傳輸中斷)時,才該優先懷疑硬體。先讀參數再決定,別先買 RAM。

Q:0x4E 跟 0x1A(MEMORY_MANAGEMENT)差在哪?

範圍不同。0x1A 是記憶體管理員的各種嚴重違規總稱,官方 Parameter 1 表列了三、四十種情況;0x4E 專指 PFN 清單這個結構的帳目損毀,指向性強得多。0x1A 的參數表裡確實也有幾個和 PFN 有關(如 0x9696、0x403),但除錯切入點不同,別把兩篇做法混用。

Q:我什麼驅動都沒裝,怎麼也會跳 0x4E?

Windows Update 也會靜默更新驅動。而且很多驅動是「特定情境才踩線」——睡眠喚醒、插拔裝置、大量 I/O 時才發作,平常完全正常。回想藍屏起始的時間點、對照更新記錄,常能找到源頭。

Q:一定要會用 WinDbg 才能修嗎?

不一定。方法一(讀藍屏畫面上的參數)、方法二(處理近期驅動)、方法四(測記憶體)都不需要 WinDbg。但如果要靠 Driver Verifier「指名道姓」抓兇手,最後那一步讀當機檔還是得用它——好消息是 !analyze -v 這一行就夠用了。

Q:Driver Verifier 開了以後電腦變超慢、還一直當,正常嗎?

正常。它是刻意加重檢查、一抓到違規就當機的工具,本來就會拖慢系統、增加當機次數;官方也明講「執行 Driver Verifier 可能導致電腦當機」、只該在測試用的機器上跑。它是短期抓兇用的,不是長期開著的,抓到後務必 verifier /reset 並重開機。

📎 參考資料來源

📖 第一級|廠商官方:

Microsoft Learn:Bug Check 0x4E PFN_LIST_CORRUPT — 2026-07-16 查證(停止碼定義 0x0000004E、Parameter 1 八種值〔0x01/0x02/0x06/0x07/0x8D/0x8F/0x99/0x9A〕與各自錯誤原因、「通常由驅動程式傳遞不正確 MDL 造成/MmUnlockPages 呼叫兩次」之成因段落、!analyze 建議)
Microsoft Learn:How to Use Driver Verifier for Driver Testing — 2026-07-16 查證(「可能導致電腦當機/只在測試電腦執行/需 Administrators 群組」警語、verifier.exe 內建於 %WinDir%\system32、Create standard settings 步驟、四種驅動選取方案之官方建議、verifier /standard /driver、/query、/querysettings、/reset、違規觸發 0xC4 及 0xC1/0xC6/0xC9/0xD6/0xE6、!analyze -v)
Microsoft Learn:Special pool memory corruption detection in Driver Verifier — 2026-07-16 查證(Special Pool 容量有限、耗盡時改用一般集區且不回報錯誤、「不建議同時驗證多支驅動程式」)
Microsoft Learn:MmUnlockPages function (wdm.h) — 2026-07-16 查證(解鎖 MDL 所描述之實體頁面、須先由 MmProbeAndLockPages 鎖定之契約、自 Windows 2000 起提供)
Microsoft Learn:Bug Check 0x1A MEMORY_MANAGEMENT — 2026-07-16 查證(0x1A 參數範圍、含 PFN 相關之 0x9696 / 0x403、官方建議執行 Windows 記憶體診斷)
Microsoft Learn:Windows 11 發行資訊 — 2026-07-16 查證(現行支援版本 25H2〔OS build 26200〕/ 24H2〔OS build 26100〕)
Microsoft 支援:疑難排解 Windows 非預期重新啟動與停止碼錯誤 — 2026-07-16 查證(「停止碼錯誤的畫面顏色與訊息會依 Windows 11 版本而異」、24H2 以後與 23H2 以前分列之畫面)

⚠️ 本文核心事實以第一級官方文件為準。本文為依微軟官方文件整理之深度解析(非站長第一手實測),停止碼參數與工具行為以你機器的實際版本與當機檔為準。

📅 本文查證戳記:2026-07-16 依據 Microsoft 官方 Bug Check 0x4E、Driver Verifier 與 MmUnlockPages 文件撰寫,適用 Windows 10 / 11(含 24H2、25H2)。若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。