DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏|拆集區揪真兇驅動

適用系統:Windows 10 / Windows 11(桌面版;Windows 10 S 未內建 Driver Verifier)
權限需求:系統管理員(Driver Verifier 官方要求操作者屬於 Administrators 群組)
需要工具:WinDbg(Debugging Tools for Windows)、內建的 verifier.exe、選用的 Gflags(隨 Debugging Tools for Windows 安裝)
預計耗時:讀 dump 約 15 分鐘;Special Pool 壓力測試視復現頻率,通常要跑數小時到數天

⚠️ 開工前先做這三件事:①建立系統還原點或完整備份——本文後半會啟用 Driver Verifier,微軟官方明確警告「執行 Driver Verifier 可能導致電腦當機」,只建議在測試機或正在除錯的機器上使用。②確認 BitLocker 狀態,若已啟用請先備妥 Recovery Key——依官方說明,救援環境在某些情況下會要求輸入金鑰才能解鎖磁碟。③先讀完本文的「🔙 萬一翻車」段,確定你知道怎麼把 Verifier 關掉,再開始動手。

🔍 症狀描述與錯誤訊息

0xC5 的典型症狀是時間點飄忽的隨機藍屏:可能開機後五分鐘就跳,也可能連續順跑兩天才跳一次;拔掉某個裝置後好像有改善,過幾天又復發。這種「沒有穩定復現路徑」的特性正是它最惱人的地方,也是它和「插上某個裝置就必當」那類藍屏最大的差別。

藍畫面上會出現的訊息通常長這樣:

你的裝置發生問題,需要重新啟動。
停止代碼(Stop code):DRIVER_CORRUPTED_EXPOOL

在事件檢視器的「系統」記錄中,這類當機通常可以在來源 BugCheck、事件識別碼 1001 的記錄裡找到(此為實務上常見的對應關係,非官方文件明定),參數欄位會寫成 0x000000c5 (0x…, 0x…, 0x…, 0x…) 這樣的四參數形式。

還有一個很值得注意的線索:同一台機器有時跳 0xC5、有時跳 0xD0(DRIVER_CORRUPTED_MMPOOL)。這兩碼在官方文件中是明文同源的——下一段會說明為什麼。若還偶爾夾雜 0xA(IRQL_NOT_LESS_OR_EQUAL)或 0x50,那部分屬於推測:同一支寫壞集區的驅動,有可能以那些形式表現,但官方並未把 0xA、0x50 歸入集區損毀家族。

🔎 問題根因

先給結論:0xC5 的直接觸發動作是「核心在 IRQL 太高的情況下去存取了可分頁記憶體或完全無效的記憶體」,但真正的病灶在更早之前——某支驅動程式把系統集區(system pool)寫壞了。

微軟官方在 Bug Check 0xC5 文件的「Cause」段寫得很直接:核心試圖在 IRQL 過高時存取可分頁記憶體(或根本無效的記憶體),而「這個問題的最終成因幾乎可以確定是某支驅動程式損毀了系統集區」。

這句話拆開來看有兩層意義,而中文圈的討論串經常只講前半段、漏掉後半段:

前半段(觸發):當下這次存取確實違規了。IRQL 達到或高於 DISPATCH_LEVEL(≥ 2)時——也就是高於 APC_LEVEL 之後——常式就不能安全地存取分頁集區記憶體;此時若發生分頁錯誤,官方定義為嚴重錯誤,系統只能當機。
後半段(病灶):之所以會存取到一個「不該是這個內容」的位址,是因為集區裡的資料結構(例如某個指標)早就被別人踩爛了。踩爛它的驅動可能在幾秒、幾分鐘甚至幾小時前就已經執行完畢、卸載乾淨。

這就是 0xC5 最重要的一個特性:它是延遲引爆的。 藍屏當下的呼叫堆疊記錄的是「誰踩到地雷」,不是「誰埋的地雷」。所以 !analyze -v 給你的 MODULE_NAME 常常每次都不一樣——不是工具不準,是這個停止碼本質上就抓不到兇手。(站長經驗上,這個欄位也常落在系統核心元件而不是第三方驅動身上;這是經驗觀察,官方文件沒有這類統計。)

也因為這樣,針對 0xC5 去「照著 !analyze 指的模組更新驅動」的成功率很低,那是在治症狀。真正有效的路線只有一條:讓系統在「寫壞的當下」就立刻當機,而不是等到後來才引爆——這正是 Special Pool 的設計目的。

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

四個 Parameter 的官方定義

0xC5 的四個參數在官方文件中定義如下:

Parameter	官方定義	白話解讀
1	Memory referenced	被存取的那個記憶體位址
2	IRQL at time of reference	存取當下的 IRQL 值
3	0 = Read / 1 = Write	這次是讀還是寫
4	Address that referenced memory	發出這次存取的程式碼位址

注意這組欄位——它和 IRQL_NOT_LESS_OR_EQUAL(0xA)家族的四個欄位語意高度對應(不是逐字相同:0xA 的 Parameter 3 在官方文件中是位元欄位,除了讀/寫還多一個執行位元)。依官方對成因的描述可以推得:0xC5 本質上就是一次「IRQL 過高的非法存取」,而系統之所以不報成一般的 IRQL 錯誤,是因為它把成因歸到了集區損毀這一類。需要說明的是,官方文件只以「配置大小」區分 0xC5 與 0xD0,並未描述核心內部如何做出這個歸類判斷,這一層屬於站長依官方敘述所做的機制推導。

實務上這四個參數怎麼用:

Parameter 2(IRQL):官方對可分頁記憶體的安全門檻是 APC_LEVEL(1)——在高於 APC_LEVEL 的 IRQL 上執行的常式,就不能安全地配置或存取分頁集區記憶體。換句話說,數值達到 2(DISPATCH_LEVEL)就已經越線,不是要大於 2 才算高。
Parameter 3:是 1(寫入)時,問題更可能來自越界寫入;是 0(讀取)時,通常是跟著一個已被污染的指標走進了無效位址。
Parameter 4:這是唯一有機會直接落到「某支驅動」的欄位,可以在 WinDbg 用 ln 或 u 指令去解析它落在哪個模組——但請記得,它指的是踩到地雷的人。

0xC5 與 0xD0 的分水嶺:是「大小」,不是「分頁與否」

這一點是中文資料裡最常被寫錯的地方,值得單獨拉出來講。

很多文章看到 EXPOOL 就直譯成「分頁式集區(paged pool)」、看到 MMPOOL 就說是「非分頁集區」。官方文件的實際判準完全不是這樣。 微軟在 0xC5 與 0xD0 兩份文件中互相對照,寫的是同一句話的兩面:

0xC5:多數情況下,是驅動損毀了一筆小於 PAGE_SIZE 的配置。更大的配置會產生 0xD0。
0xD0:多數情況下,是驅動損毀了一筆 PAGE_SIZE 或更大的配置。更小的配置會產生 0xC5。

換句話說,0xC5 與 0xD0 的差別是被踩壞的那筆配置有多大,而不是它在分頁集區還是非分頁集區。這個區分對排查有實際價值:同一台機器如果 0xC5 和 0xD0 交替出現,代表被污染的範圍橫跨大小配置,越界寫入的幅度可能不小;如果只穩定出現 0xC5,兇手大概率是在一筆小結構上做越界或釋放後續用(use-after-free)。

集區家族三碼:偵測層次完全不同

0xC5 常和另外兩個「看起來也跟記憶體有關」的停止碼被混為一談,但它們攔截的位置差很多:

停止碼	系統攔到的是什麼	兇手在當下堆疊上嗎
0xC2 BAD_POOL_CALLER	呼叫端當下的集區用法錯誤(零位元組配置、重複釋放、IRQL 不對、tag 用錯)	在——當場人贓俱獲
0xC5 DRIVER_CORRUPTED_EXPOOL	集區已經被寫壞,後來有人踩到	不在——延遲引爆
0x4E PFN_LIST_CORRUPT	頁框編號(PFN)資料庫層的清單損毀	視 Parameter 1 而定——官方仍建議先看堆疊

📌 表格讀法說明:「系統攔到的是什麼」與各碼的官方名稱、參數語意均依官方文件敘述翻譯整理;「兇手在當下堆疊上嗎」這一欄則是站長依官方成因描述所做的推導,官方文件並未直接論述肇事者是否出現在當下的呼叫堆疊(0x4E 一欄尤其如此——官方只說明 Parameter 1 各代碼分別指向驅動或硬體)。

三碼的排查策略因此完全不同:

跳 0xC2 時,Parameter 1 直接告訴你違規類型,堆疊通常就指得到兇手。詳細的參數對照可以看站長寫過的 BAD_POOL_CALLER 0xC2 藍屏怎麼修?讀懂 Parameter 1 揪出兇手驅動。
跳 0x4E 時,官方指出典型成因是驅動傳了錯誤的記憶體描述元清單(MDL),例如對同一份清單呼叫了兩次 MmUnlockPages;官方也明確建議在有核心偵錯器時先跑 !analyze 再用 k 系列指令檢視呼叫堆疊。參數 1 的八種代碼各有不同含義,拆法見 PFN_LIST_CORRUPT 0x4E 藍屏怎麼修?讀懂官方八個參數,分流驅動或硬體。
跳 0xC5 時,如上所述——別在堆疊上找兇手,直接進 Special Pool 流程。

🛠️ 解決方案

⚠️ 高風險操作警語:方法三會啟用 Driver Verifier,微軟官方明確警告此工具可能造成電腦當機,並建議只在測試機或正在除錯的機器上執行。動手前務必:①建立系統還原點或完整備份;②確認 BitLocker Recovery Key 在手;③確認你能進入安全模式(不確定的話,先照著「🔙 萬一翻車」段演練一次)。
停止條件清單(符合任一項,請不要繼續往下做):不確定自己的 Windows 版本或機型、尚未完成備份、BitLocker 已啟用但沒有 Recovery Key、這是公司或學校的受管控設備而你沒有 IT 授權、機器是唯一的生產工作機且沒有替代機、指令輸出與本文描述明顯不符。

方法一:先把「最近變更」與硬體因素刷掉

先給結論:在動用 Driver Verifier 之前,先花 30 分鐘做三件低風險的排除,可以省掉後面好幾天的壓力測試。

0xC5 雖然幾乎都是驅動問題,但實體記憶體故障會製造出一模一樣的症狀——壞掉的記憶體位元會直接把集區內容改掉,結果和驅動越界寫入無法區分。所以先做這三步:

回想最近的變更:官方在 0xC5 的 Resolution 段開頭就提到「如果你最近安裝了任何新軟體,檢查它是否正確安裝」(在 0xD0 頁面,這句更是 Resolution 的第一句)。防毒軟體、VPN 用戶端、虛擬磁碟機、遊戲反作弊模組、硬體監控工具——這幾類都會掛核心驅動,是最常見的嫌疑犯。有可疑對象就先移除,觀察幾天。
跑 Windows 記憶體診斷:官方在 0xC2 文件中特別建議,遇到集區損毀情境時要跑一次 Windows 記憶體診斷來嘗試排除實體記憶體。在控制台搜尋「記憶體」,選擇診斷電腦的記憶體問題;測完之後到事件檢視器的「系統」記錄找 MemoryDiagnostics-Results 項目看結果。
到硬體廠商官網更新驅動:注意是廠商官網,不是 Windows Update,也不是第三方驅動更新軟體。官方 Resolution 段的原文就是「到製造商網站檢查是否有更新的驅動程式」。

這三步都做完仍然復發,才進方法二。

方法二:用 WinDbg 讀 dump,先確認這是不是集區損毀

先給結論:這一步的目的不是找兇手,而是確認「集區確實被寫壞了」,並取得可用的 pool tag 線索。

開啟 minidump 或完整記憶體傾印之後,先跑基本盤:

!analyze -v

官方對 0xC5 的 Resolution 明確寫著:!analyze 這個除錯延伸命令會顯示錯誤檢查的相關資訊,對判定根本原因有幫助。看三個地方:

BUGCHECK_P1 到 BUGCHECK_P4,對回上面那張參數表。
FAILURE_BUCKET_ID,如果多次當機的 bucket 都不一樣,更加坐實了「延遲引爆」的判斷。
呼叫堆疊,用 k 系列指令展開。

接著檢查出事位址所在的集區區塊:

!pool <Parameter1 的位址>

!pool 會顯示這個位址所在區塊裡所有配置的標頭,包含每筆配置的大小、是已配置還是已釋放,以及pool tag。輸出中被指定的那一筆會用星號標記。官方說明也提到,Windows XP 之後 !pool 會依據除錯工具安裝目錄 triage 子資料夾下的 pooltag.txt 顯示每個 tag 的擁有者——這份對照表就是把 tag 對回「哪個元件配置的」的關鍵。

如果 !pool 回報集區損毀,官方建議接著用:

!poolval

做進一步查驗。

這一步能拿到最有價值的產出是那個 pool tag。 記下它,方法四會用到。

方法三:Driver Verifier Special Pool——真正能定位兇手的做法

先給結論:Special Pool 的原理是把受測驅動的每一筆配置各自放到獨立頁面上,並把前後頁標記為不可存取,一越界就當場當機——把延遲引爆變成即時引爆。

這是官方對 0xC5 給出的正式建議:「若要對此錯誤除錯,請使用 Driver Verifier 的 special pool 選項。」

它到底做了什麼

依官方 Special Pool 文件,啟用後(預設的 Verify End 對齊):

驅動要求的每一筆配置各自佔一個頁面,並且對齊到頁面尾端。
頁面前半段填入特殊樣式(pattern),前一頁與後一頁都被標記為不可存取。
驅動若讀寫超過配置尾端 → Driver Verifier 立即發出 Bug Check 0xCD(PAGE_FAULT_BEYOND_END_OF_ALLOCATION)。
驅動若寫到配置開頭之前 → 樣式被改動,釋放時被偵測到 → 發出 Bug Check 0xC1(SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION)。
驅動若在釋放後仍讀寫該緩衝區 → 發出 Bug Check 0xCC(PAGE_FAULT_IN_FREED_SPECIAL_POOL)。

官方也註明:Verify End 是預設值,因為在驅動中溢位(overrun)遠比欠位(underrun)常見;要抓欠位才需要改用 Verify Start。

換句話說,你的目標是把 0xC5 換成 0xC1 / 0xCC / 0xCD。這三個停止碼是「當場抓到」的,兇手就在堆疊上。

怎麼開

用 Driver Verifier 管理員(圖形介面):在系統管理員身分的命令提示字元輸入 verifier,選「建立自訂設定(供程式開發人員使用)」→「從完整清單選取個別設定」→ 勾選 Special pool,再選要驗證的驅動,完成後重新啟動。

命令列同樣做得到。官方文件指出,Special Pool 選項在命令列對應 Bit 0(0x1):

verifier /flags 0x1 /driver mydriver.sys

此設定在下次開機後生效。若不想重開機,官方提供 /volatile 參數:

verifier /volatile /flags 0x1 /adddriver mydriver.sys

這個設定立即生效,但關機或重開機後就會消失。Special Pool 也包含在標準設定裡:

verifier /standard /driver mydriver.sys

⚠️ 為什麼你「開了 Verifier 卻什麼都沒抓到」

這是實務上最容易踩的坑,而答案就寫在官方文件裡:不是所有 Special Pool 要求都會被滿足。

每一筆 Special Pool 配置會用掉一頁不可分頁的實體記憶體 + 兩頁虛擬位址空間。
集區耗盡時,系統會改用一般方式配置——而且回傳的仍然是成功狀態,呼叫端完全不知道自己沒被保護到。
官方因此明確建議:啟用 Special Pool 時不要同時驗證多支驅動;一支會做大量小配置的驅動也可能把集區吃乾。
若啟用了 Special Pool 但不到 95% 的集區配置被指派到 Special Pool,Driver Verifier 管理員會在「全域計數器」畫面顯示警告。
官方也提到,Special Pool 的大小隨系統實體記憶體增加,理想上至少要 1 GB 實體記憶體;在 x86 機器上不要使用 /3GB 開機選項,並建議把分頁檔的最小/最大值放大兩到三倍。

所以正確做法是:一次只驗一支或少數幾支驅動,並用 !verifier 或管理員的全域計數器確認命中率。 官方明講,若「Pool Allocations Succeeded in Special Pool」計數器等於「Pool Allocations Succeeded」,代表 Special Pool 足以涵蓋全部配置;前者低於後者,就代表集區至少被耗盡過一次——那一輪測試的結論不可信。

怎麼挑受測名單?從方法二拿到的 pool tag、最近安裝過的第三方核心驅動、以及非微軟簽署的驅動優先。Driver Verifier 本身的完整操作(含「自動選取所有驅動」的代價與各選項含義),站長寫過一篇完整教學:Driver Verifier 完整使用教學 2026|揪出偷偷作亂的驅動程式。

抓到之後

Driver Verifier 偵測到違規時會立即產生錯誤檢查以停止電腦,官方說明這是為了提供最多的除錯資訊。拿到新的 dump 之後,回到 WinDbg 跑:

!analyze -v

!verifier

!verifier 會傾印 Driver Verifier 擷取到的統計資料,用 !verifier -? 可以列出所有可用選項。這一輪的 MODULE_NAME 才是有意義的。

方法四:Gflags 依 pool tag 收網(終極手段)

先給結論:當你不知道該驗哪支驅動,但方法二已經拿到可疑的 pool tag 時,改用 Gflags 針對 tag 開 Special Pool。

官方 Special Pool 文件明確列出:除了 Driver Verifier 針對「指定驅動」開 Special Pool 之外,還有另外兩種用法——依 pool tag(對所有使用該 tag 的配置開)與依配置大小範圍開。要用這兩種方式,必須使用 Gflags(Debugging Tools for Windows 隨附的工具)。0xC5 官方文件的 Resolution 段也寫得很清楚:如果 Special Pool 沒能揪出肇事驅動,就用 Global Flags 工具依 pool tag 啟用 special pool。

兩點要注意:

官方指出 Driver Verifier 的 Special Pool 與 Gflags 的 special pool 可以同時使用,但要記得 special pool 有限、不是所有配置都會成功,而且失敗時 Windows 仍回傳成功狀態。
官方也建議,當單一驅動的小配置太多而耗盡集區時,替該驅動的配置指定 pool tag、一次只把 special pool 專用於一個 tag,會是比較好的做法。

另外,官方在 0xD0 文件中提供了一個替代方法(不是 0xC5 頁面的建議,但同屬集區損毀家族,對長期監控有參考價值):在登錄機碼

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

底下建立或編輯 ProtectNonPagedPool 值,設為 DWORD 1 後重新開機,系統就會把所有已釋放的非分頁集區解除對應,藉此阻止驅動污染集區。官方同時註明:這個做法無法保護集區免於 DMA 硬體造成的損毀。

⚠️ 修改登錄檔前請先備份該機碼(在登錄編輯程式中對機碼按右鍵 →「匯出」),並確認你已建立系統還原點。這個值屬於記憶體管理設定,設錯會影響開機。

✅ 驗證修復結果

先給結論:0xC5 是低頻隨機故障,「今天沒當機」不等於修好了。 驗證要看三件事:

在 Special Pool 仍開啟的狀態下跑壓力測試。官方建議「長時間對驅動施壓,以確保驅動的所有配置都被測到」。如果換掉可疑驅動之後,在 Special Pool 開啟且命中率接近 100% 的狀態下連續跑數天都不再出現 0xC1 / 0xCC / 0xCD,可信度才夠高。
確認命中率。用 verifier /query 查看目前狀態,或在 Driver Verifier 管理員選「顯示目前已驗證驅動程式的相關資訊」;重點看 Special Pool 相關計數器,別在集區早就耗盡的情況下宣告勝利。
確認事件檢視器不再出現新的 BugCheck 1001 記錄,而不是只看有沒有看到藍畫面(有些當機會直接重啟,你未必看得到畫面)。

驗證完成之後,務必把 Driver Verifier 關掉——它會持續帶來效能負擔,官方也只建議在測試/除錯期間使用。

🔙 萬一翻車:回退步驟

啟用 Driver Verifier 之後最常見的翻車情境是:一支問題驅動在開機階段就被抓到違規,系統立刻當機重開,形成開機循環,你根本沒機會進到桌面把 Verifier 關掉。

情境一:還能進到桌面

以系統管理員身分開啟命令提示字元,執行:

verifier /reset

然後重新啟動。也可以在 Driver Verifier 管理員選「刪除現有設定」→「完成」→ 重新啟動,兩者等效。

情境二:進不了桌面(開機循環)

連續中斷開機(開機出現 Windows 標誌時長按電源鍵強制關機)。官方列出五種會自動啟動 Windows RE 的情況,其中之一就是「連續兩次開機失敗」(其餘為:開機完成兩分鐘內連續兩次非預期關機或兩次系統重新開機、Secure Boot 錯誤、觸控裝置的 BitLocker 錯誤),保險起見可以做到三次。系統會進入自動修復,出現「選擇選項」畫面。
依序選:疑難排解 → 進階選項 → 啟動設定 → 重新啟動 → 選擇安全模式(命令提示字元)。
若機器啟用了 BitLocker,這一步可能會要求輸入 Recovery Key。官方說明指出,支援特定 TPM 量測且救援環境未被變更的裝置會自動解鎖;但只要環境被變更(例如 TPM 被停用)或改用修復磁碟手動啟動救援環境,就必須提供金鑰——這就是為什麼開工前要先確認金鑰在手。
進入安全模式後執行 verifier /reset,再正常重新啟動。

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

進入「進階選項」→「系統還原」,還原到啟用 Driver Verifier 之前的還原點。這也是為什麼本文一開始就要求先建立還原點——這是唯一不需要重灌就能脫身的保險。

📌 如果你在情境二成功記下了造成當機的驅動名稱,那其實是好消息:Verifier 已經幫你抓到兇手了,關掉 Verifier 之後改成移除或更新那支驅動即可。

💡 總結:預防再次發生

站長我處理這類集區損毀案件時,一律先問三個問題,而不是先開工具:這台機器最近裝了什麼會掛核心驅動的軟體?這個停止碼是單獨出現還是跟 0xD0/0x4E 交替?記憶體診斷跑過了沒? 這三題的答案決定了後面要花的是三十分鐘還是三天。0xC5 之所以難纏,不是因為技術上多深奧,而是因為它的錯誤訊息在結構上就不指向兇手——想清楚這一點,排查方向就不會走偏。

長期預防的核心動作有三個:

核心驅動類軟體從嚴管理。防毒、VPN、虛擬光碟、反作弊、超頻與硬體監控工具——這些都會掛核心驅動,能不裝就不裝,要裝就只留一套,並且只從原廠官網取得。
驅動更新走官方管道。廠商官網與 Windows Update 之外的「驅動更新精靈」類工具,是集區損毀案件裡的常客。
保留可用的救援路徑。系統還原點、BitLocker Recovery Key、可開機的 Windows 安裝隨身碟——這三樣在平時沒感覺,在 Driver Verifier 把機器搞到開不了機的那一刻價值連城。

最後說一句誠實話,而且這一段是站長我的經驗判斷、不是官方統計:這類集區損毀案件並不保證一定能定位到單一兇手驅動。當所有官方路線都跑完仍抓不到,而機器又是生產工作機時,乾淨重灌加上「只裝必要驅動」的重建策略,往往比繼續追下去更划算。這不是投降,是成本判斷。

❓ 常見問題

Q:DRIVER_CORRUPTED_EXPOOL 0xC5 是記憶體條壞了嗎?要不要直接換 RAM?

不一定,而且不建議直接換。官方對 0xC5 的成因判定是「幾乎可以確定是某支驅動程式損毀了系統集區」,指向的是軟體。但實體記憶體故障會製造出無法區分的症狀,所以正確順序是:先跑 Windows 記憶體診斷排除硬體,再走驅動路線。跳過診斷直接換 RAM,很可能白花錢。

Q:!analyze -v 每次指的模組都不一樣,是工具壞了嗎?

不是。這正是 0xC5 的正常表現。集區損毀是延遲引爆,當機當下的堆疊記錄的是踩到地雷的人,不是埋地雷的人,所以每次踩雷者不同很合理。要抓埋雷的人,必須用 Special Pool 讓越界寫入在發生的當下就引發當機。

Q:0xC5 跟 0xD0 到底差在哪?

差在被踩壞的那筆配置有多大,不是分頁/非分頁的差別。官方文件寫明:損毀小於 PAGE_SIZE 的配置多半報 0xC5,損毀 PAGE_SIZE 或更大的配置則報 0xD0。兩者的四個參數定義與成因描述完全相同,Resolution 則略有出入——0xC5 頁多提了 !analyze,0xD0 頁多了 ProtectNonPagedPool 這個替代做法。

Q:開了 Driver Verifier 之後電腦變超慢,正常嗎?

正常。官方明確說明驗證驅動的程式碼會帶來額外負擔,並建議「盡可能驗證最少數量的驅動」。Special Pool 更會額外消耗不可分頁實體記憶體與虛擬位址空間。所以請一次只驗少數幾支驅動,測完立刻用 verifier /reset 關掉,不要長期開著。

Q:我開了 Special Pool 跑了好幾天,一次都沒抓到,是不是代表那支驅動沒問題?

不能這樣下結論。官方指出 special pool 有限,耗盡時系統會靜默改用一般集區配置,而且仍然回傳成功狀態——你的驅動可能根本沒被保護到。請先確認 Driver Verifier 管理員的全域計數器沒有出現「不到 95% 配置來自 special pool」的警告,或用 !verifier 檢查統計,再判斷這一輪測試是否有效。

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

回到方法二重讀新的 dump,比對 Parameter 3(讀/寫)與 !pool 拿到的 pool tag 是否與上次相同。tag 相同代表同一個嫌疑元件沒清乾淨;tag 不同則可能有第二支問題驅動,或該回頭認真排除實體記憶體與其他硬體因素。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL — 2026-08-06 查證
Bug Check 0xD0: DRIVER_CORRUPTED_MMPOOL — 2026-08-06 查證
Special pool memory corruption detection in Driver Verifier — 2026-08-06 查證
Driver Verifier(How to Use Driver Verifier for Driver Testing) — 2026-08-06 查證
Bug Check 0xC2: BAD_POOL_CALLER — 2026-08-06 查證
Bug Check 0x4E: PFN_LIST_CORRUPT — 2026-08-06 查證
!pool extension command — 2026-08-06 查證

⚠️ 本文核心事實以第一級官方文件為準;文中未包含任何第一手實測數據,屬官方文件整理與機制推導。

📅 本文查證戳記:2026-08-06 依 Microsoft Learn 官方文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。