BAD_POOL_CALLER 0xC2 藍屏怎麼修?讀懂 Parameter 1 揪出兇手驅動

⚡ 站長快讀:核心重點

• 文章屬性:疑難排除(A5 底層除錯)
• 適用系統:Windows 11 / Windows 10(皆內建 Driver Verifier 與記憶體診斷)
• 難易度 / 耗時:中高 / 約 30–90 分鐘
• 核心結論:BAD_POOL_CALLER 0xC2 是典型的「呼叫端錯誤」——兇手幾乎都是某支驅動、而非記憶體硬體壞掉,排查方向以揪出問題驅動為主。
• 適用對象:無預警跳 BAD_POOL_CALLER / 0x000000C2 藍屏,想自己揪出兇手驅動的人。

📌 快速答案

一句話答案:BAD_POOL_CALLER 0xC2 代表有驅動對核心記憶體集區做了不合法呼叫(多為重複釋放或錯誤 IRQL);先讀 Parameter 1 定位違規類型,再用 Driver Verifier 揪出兇手驅動,少數情況才是實體記憶體壞掉。

🧰 開始前的準備

• 適用系統:Windows 11 24H2 / 23H2、Windows 10 22H2(所有現行版本都內建 Driver Verifier 與 Windows 記憶體診斷)
• 權限需求:系統管理員(Driver Verifier、記憶體傾印設定、記憶體診斷都需要)
• 需要工具:WinDbg(從 Microsoft Store 安裝)、Windows 記憶體診斷(內建 mdsched.exe)、事件檢視器;先確認已設定好記憶體傾印,藍屏時才有 dump 可查
• 預計耗時:約 30–90 分鐘(Driver Verifier 需重開機並觀察一段時間)

🔍 症狀描述與錯誤訊息

電腦在使用中或開機後不久無預警當機,畫面轉為藍色並顯示:

🙁 你的裝置發生問題,需要重新啟動⋯⋯

停止碼(Stop code):BAD_POOL_CALLER

有時畫面只顯示十六進位停止碼 0x000000C2(簡寫 0xC2)。重新開機後,在事件檢視器的「Windows 記錄 → 系統」中,可以找到來源為 BugCheck、事件 ID 1001 的紀錄,裡面會帶出四個參數(Parameter 1~4)。

這種藍屏最容易被誤判成「記憶體壞了、去換一條 RAM」。但 0xC2 的本質是呼叫端(caller)行為不合法,而不是記憶體本身壞掉——換 RAM 在多數案例根本不會解決問題,得先讀懂參數才知道方向。

🔎 問題根因

Windows 核心把記憶體集區(pool)的配置與釋放交由核心的記憶體管理員統一管理。當某個執行緒(在使用者電腦上幾乎都是核心模式驅動程式)對 pool 發出一個「不合法」的請求時,記憶體管理員會在當下就攔截並觸發 Bug Check 0xC2,把違規的種類寫進 Parameter 1。

依微軟官方 Bug Check 0xC2 文件,最典型的成因是:在不允許的 IRQL 層級操作 pool,或重複釋放同一塊已經釋放過的記憶體(double free)。換句話說,錯的是「驅動怎麼呼叫」,不是「記憶體是好是壞」。少數屬於 pool 標頭(header)被寫壞的類型,才可能牽涉到實體記憶體或驅動越界寫入。

下表整理官方 Parameter 1 的常見值與對應違規(完整清單以官方文件為準):

看懂這張表,你就能一眼分辨「這次藍屏該查驅動,還是該查記憶體」。

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

Windows 核心把可動態配置的核心記憶體分成兩種集區:paged pool(分頁集區,閒置時可被換出到分頁檔)與 nonpaged pool(非分頁集區,永遠常駐實體記憶體,供 DISPATCH_LEVEL 以上的高 IRQL 程式碼使用)。驅動程式用 ExAllocatePool2 / ExAllocatePoolWithTag 之類的 API 配置、用 ExFreePool / ExFreePoolWithTag 釋放。每一塊 pool 前面都有一個「pool header」記錄它的大小、type 與 tag。

當呼叫端做出違反規則的動作——重複釋放、釋放一段根本不屬於自己或從未配置的位址、在錯誤的 IRQL 操作、或用錯 tag 釋放別人的記憶體——記憶體管理員在處理這個請求的當下就會發現不對勁,直接觸發 0xC2,並把違規種類編碼進 Parameter 1(官方文件也註明:_POOL_TYPE 中 0 代表 nonpaged pool、1 代表 paged pool)。

這正是 0xC2 幾乎都指向「某支驅動」而非記憶體本身的原因:它抓的是「呼叫的方式」不合法。這也是它和 BAD_POOL_HEADER 0x19 的關鍵差別——0x19 是 pool 標頭「已經被寫壞」後才在事後被發現,0xC2 則是不合法呼叫「當下」就被擋下;兩者常常同源(都是驅動亂搞 pool),但抓法互補,先分清楚是哪一種,才不會走冤枉路。

🛠️ 解決方案

⚠️ 高風險警語:本文方法二會用到 Driver Verifier。官方明言「執行 Driver Verifier 可能導致電腦當機,只應在你用於測試與除錯的電腦上執行」。開始前務必:① 備份重要資料;② 確認能進入安全模式(見回退步驟);③ 若有 BitLocker,先備妥還原金鑰。不確定就先只做方法一。

方法一:先讀 Bug Check 的四個參數(門檻最低)

先別急著動手改任何設定。用 WinDbg 開啟 minidump 分析,在命令列輸入:

!analyze -v

輸出裡的 Arg1 就是 Parameter 1,對照上面那張表即可判斷違規類型;!analyze -v 通常也會在 MODULE_NAME / IMAGE_NAME 直接點名可疑的模組(某個 .sys)。如果 Parameter 1 落在 0x06~0x0A、0x40、0x41 這類「呼叫端錯誤」,方向就是驅動;若是 0x01/0x02/0x04/0x99 這類標頭損毀型,就同時把記憶體列入嫌疑(方法三)。

方法二:用 Driver Verifier 揪出兇手驅動

當 dump 指不出明確模組,或你想強制讓兇手現形時,再上 Driver Verifier。它會即時監控驅動,一發現違規就故意觸發 bug check 把該驅動抓包。詳細操作見 Driver Verifier 完整使用教學,重點步驟:

1. 以系統管理員開啟命令提示字元,輸入 verifier 開啟 Driver Verifier 管理員。
2. 選「建立標準設定」→ 下一步。
3. 選「從清單選擇驅動程式名稱」,只勾選非微軟、或近期才更新/安裝的驅動,一次挑少量(官方指出 Special Pool 這類選項一次只驗一支或少數幾支最有效,全選會耗盡資源並拖慢系統)。
4. 完成後重新開機,正常使用讓它跑。

若某支驅動違規,系統會觸發 bug check(常見是 0xC4 DRIVER_VERIFIER_DETECTED_VIOLATION,或 0xC1 / 0xC6 這類 pool 相關碼),而 dump 會直接點名那支 .sys——那就是兇手。

也可以用命令列直接針對單一驅動:

verifier /standard /driver suspect.sys

測完務必關掉:抓到兇手(或想停手)後,一定要執行 verifier /reset 再重開機,否則系統會一直帶著檢查跑、又慢又容易當。

方法三:排除實體記憶體並更新/移除可疑驅動

如果 Parameter 1 是標頭損毀型(0x01/0x02/0x04/0x99),先排除硬體:執行 mdsched.exe 跑 Windows 記憶體診斷(官方建議在 pool 損毀情境用它隔離實體記憶體),測完到事件檢視器看 MemoryDiagnostics-Results;要更嚴謹可另跑 MemTest86(見延伸閱讀)。

確認記憶體沒問題後,回頭處理驅動:到裝置管理員對可疑驅動選「更新驅動程式」或「回復驅動程式」,或到硬體廠商官網抓最新版。近期才安裝的防毒、VPN、磁碟加密、虛擬機這類會掛在系統底層的第三方核心驅動,是最常見的疑犯,可先移除測試;最後用 Windows Update 把驅動補齊。

✅ 驗證修復結果

• 更新或移除可疑驅動、並執行 verifier /reset 關閉 Driver Verifier 後,連續正常使用數天不再跳 0xC2。
• 到事件檢視器「系統」記錄確認不再出現新的 BugCheck(事件 ID 1001)紀錄。
• 若仍偶發,回方法一重看 Parameter 1 是否改變:同一個值代表同類問題還在,換了值則可能是另一支驅動,回方法二改驗其他驅動。

🔙 萬一翻車:回退步驟

*(針對方法二 Driver Verifier 的高風險情境)*

情境:開了 Driver Verifier 後一直藍屏、甚至開不了機(boot loop)。

1. 讓電腦在開機途中失敗 3 次,第 4 次會自動進入 Windows 修復環境(WinRE);或在登入畫面按住 Shift 再點「重新啟動」。
2. WinRE →「疑難排解」→「進階選項」→「啟動設定」→ 重新啟動 → 選「安全模式」。
3. 進安全模式後,以系統管理員開啟命令提示字元,執行:

verifier /reset

1. 重新開機,系統就會回到沒有 Driver Verifier 的正常狀態。
2. 若連安全模式都進不去:WinRE →「進階選項」→「系統還原」,還原到啟用 Driver Verifier 之前的還原點。

停止條件(符合任一,請先不要動 Driver Verifier):不確定哪些是關鍵驅動、尚未完成備份、BitLocker 已啟用但手邊沒有還原金鑰、公司/學校控管設備且無 IT 授權。

💡 總結:預防再次發生

BAD_POOL_CALLER 幾乎都是驅動惹的禍,務實的預防重點就三個:

1. 驅動只從裝置廠商官網或 Windows Update 取得,別用來路不明的「驅動更新軟體」一次亂刷一堆——那是 0xC2 的溫床。
2. 安裝防毒、VPN、磁碟加密、虛擬機這類底層工具時一次裝一套,裝完留意系統有沒有開始不穩,方便日後對照是哪一套。
3. 平常就先把記憶體傾印設定好(見延伸閱讀),真的藍屏時才有 dump 可查,不必等它再當一次才後悔沒開。

站長的經驗法則是:0xC2 這種「呼叫端錯誤」很少靠重灌就根治——因為重灌後你多半又會把同一支驅動裝回去。先照方法一、方法二揪出兇手,再對症處理,才不會白忙一場。

❓ 常見問題

Q:BAD_POOL_CALLER 到底是什麼意思?

它代表目前執行緒(在一般電腦上通常是某支驅動程式)對核心記憶體集區(pool)發出了不合法的請求,例如重複釋放、在錯誤的 IRQL 操作、或釋放不屬於自己的位址,核心因此觸發 Bug Check 0x000000C2。

Q:0xC2 藍屏怎麼判斷是哪個驅動造成的?

兩步:先用 WinDbg 跑 !analyze -v 讀 Parameter 1 與被點名的模組;若不夠明確,再用 Driver Verifier 針對可疑驅動強制驗證,讓它違規時現形。

Q:跟 BAD_POOL_HEADER 0x19、其他記憶體藍屏差在哪?

0xC2 是「呼叫的方式」不合法、當下被擋;0x19 是 pool 標頭已被寫壞、事後才發現。兩者常同源(驅動亂搞 pool),但 Parameter 1 與抓法不同,先分清楚再處理。

Q:一定要用 Driver Verifier 嗎?有沒有風險?

不一定,但它最能點名兇手。風險在於它會故意讓有問題的驅動當機,官方要求只在測試/除錯機上跑;務必先備份、一次驗少量驅動,並記得用 verifier /reset 關閉。

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

回方法一重看 Parameter 1:值沒變代表同類問題仍在,可能還有其他同型驅動;值變了就改驗其他驅動。若一直是標頭損毀型(0x01/0x02/0x04/0x99),把實體記憶體也徹底測一輪。

🔗 延伸閱讀

• KERNEL_MODE_HEAP_CORRUPTION(0x13A)藍屏怎麼修?讀懂官方參數,先分清 heap 與 pool
• PFN_LIST_CORRUPT 0x4E 藍屏怎麼修?讀懂官方八個參數,分流驅動或硬體
• 當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手
• MemTest86 vs Windows 記憶體診斷:內建初篩還是第三方深驗?

📎 參考資料來源

📖 第一級|廠商官方:

• Bug Check 0xC2: BAD_POOL_CALLER — Microsoft Learn — 2026-07-18 查證
• Driver Verifier — Microsoft Learn — 2026-07-18 查證

⚠️ 本文核心事實以第一級官方文件為準;停止碼參數、Driver Verifier 指令與風險警語均引自 Microsoft Learn。

📅 本文查證戳記:2026-07-18,依 Microsoft 官方文件(Bug Check 0xC2、Driver Verifier)整理撰寫,非第一手實測。若你在後續 Windows 版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。