DRIVER_VERIFIER_DETECTED_VIOLATION(0xC4)藍屏怎麼修?讀懂 Parameter 1 揪出違規驅動

⚡ 站長快讀:核心重點

• 屬性 / 系統:疑難排除(底層除錯)/ Windows 10、11
• 難易度 / 耗時:⭐⭐⭐ / 約 40–60 分鐘
• 核心結論:看到這顆藍屏別急著重灌——它代表除錯已經成功一半,現場證據都被完整凍結下來了。
• 適用對象:開了 Driver Verifier 後開始跳藍屏的人。

📌 快速答案

一句話答案:DRIVER_VERIFIER_DETECTED_VIOLATION 0xC4 是 Driver Verifier 抓到驅動違規後主動觸發的藍屏,先讀 Parameter 1 判違規類型,再用 WinDbg 定位兇手驅動。

🧰 開始前的準備

• 適用系統:Windows 10、Windows 11(Verifier.exe 位於 %WinDir%\system32\;Windows 10 S 未內含 Driver Verifier)
• 權限需求:系統管理員(官方明訂必須是 Administrators 群組成員才能使用 Driver Verifier)
• 需要工具:命令提示字元(系統管理員)、WinDbg、記憶體傾印檔(%SystemRoot%\Minidump\)
• 預計耗時:約 40–60 分鐘
• 事前必做:確認重要資料已備份、確認手上有可開機的救援 USB 或還原點,並且知道怎麼進安全模式(本文最後一節有回退步驟)

🔍 症狀描述與錯誤訊息

最典型的情境是這樣:某台機器偶爾當機抓不到兇手,你照著標準流程開了 Driver Verifier,重開機之後——電腦反而當得更兇,而且藍屏訊息從原本五花八門的停止碼,多半會固定成 0xC4 這一種(官方另列 0xC1、0xC6、0xC9、0xD6、0xE6 等也是 Driver Verifier 常見的停止碼)。畫面上會出現:

🙁 您的電腦發生問題,需要重新啟動。

停止碼:DRIVER_VERIFIER_DETECTED_VIOLATION

如果你有接核心偵錯器,中斷入偵錯器時會看到更完整的一行(以下數值取自官方範例,非站長實測):

\*\*\* Fatal System Error: 0x000000c4

(0x0000000000020005, 0xFFFFF88000E16F50, 0x0000000000000000, 0x0000000000000000)

很多人到這裡的第一反應是「慘了,我把系統搞壞了」,然後急著重灌。先別動。 這個停止碼跟你平常遇到的 0x50、0x1A、0xD1 在性質上完全不同:它不是系統自己踩到地雷,而是你安裝的檢查員站在旁邊,看到某支驅動違反規則,當場把系統停下來,好把最完整的現場資訊留給你。這正是為什麼下一步該做的不是重灌,而是去讀 Parameter 1。

🔎 問題根因

官方對 Bug Check 0xC4 的定義只有一句話,但這句話就是全部的關鍵:DRIVER_VERIFIER_DETECTED_VIOLATION 的值為 0x000000C4,是 Driver Verifier 找到致命錯誤時的「通用」停止碼。所謂通用,意思是它底下涵蓋了上百種完全不同的違規行為——從「驅動要求配置 0 位元組的集區記憶體」、「在 IRQL 高於 DISPATCH_LEVEL 時配置 nonpaged 記憶體」,一路到「驅動卸載時沒有先釋放自己的集區配置」都共用這一個代碼。

所以 0xC4 本身不帶診斷資訊,真正的資訊全在 Parameter 1。官方文件寫得很清楚:Parameter 1 identifies the type of violation(Parameter 1 標示違規的種類),而 Parameter 2、3、4 的意義會隨著 Parameter 1 的值而改變。這一點是本篇最重要的觀念:你不能拿別人 0xC4 的參數解讀套到自己身上,因為兩者的 Parameter 2 可能一個是 IRQL、一個是 MDL 位址,毫無關係。

另外一點是站長的實務判讀提醒(這不是官方立場,官方傾向直接把違規驅動視為問題來源):Driver Verifier 抓到問題,不必然代表它抓到的那支驅動就是你原本那個症狀的兇手。Verifier 會依你啟用的檢查選項,對被監測驅動呼叫的相關核心 API 逐一加上包裝與規則檢查,有些長年存在、平常不會致命的小違規也會被抓出來。判讀時要分清楚「這是不是我原本那個症狀的根因」與「這是不是一個真的該修的違規」——它們常常是兩件事。

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

要理解 0xC4,得先知道 Driver Verifier 在核心裡到底做了什麼。你在 verifier 裡勾選一支驅動並重開機之後,系統會把該驅動註冊為「可疑」,核心接著對它啟用大量額外檢查——官方在 !analyze -v 的輸出中就是這樣描述的:因為該驅動被管理員在登錄檔中指定為可疑,核心對它啟用了大量檢查;若驅動試圖破壞系統,0xC4、0xC1 與 0xA 會是最常見的當機類型。

實作上,核心會把被驗證驅動呼叫的核心 API 包一層。從官方範例的呼叫堆疊可以看得很清楚,一次違規的完整路徑長這樣:

MyDriver!OnInterrupt
  → nt!VerifierExAcquireFastMutex
  → nt!ViExAcquireFastMutexCommon
  → VerifierExt!ExAcquireFastMutex_wrapper
  → VerifierExt!SLIC_ExAcquireFastMutex_entry_irqlexapclte1
  → VerifierExt!SLIC_abort
  → nt!KeBugCheckEx

(上列已依呼叫順序重排,官方 STACK_TEXT 的排列方向與此相反。)由上往下讀:驅動呼叫的不是原始的 ExAcquireFastMutex,而是 Verifier 的包裝函式(VerifierExt!..._wrapper);包裝函式內嵌了規則檢查(SLIC_..._entry_irqlexapclte1),一旦條件不成立就走 SLIC_abort,最後直接叫 KeBugCheckEx 停機。這就是「0xC4 是被主動觸發、不是被動崩潰」在程式碼層面的證據——停機是檢查邏輯的正常出口,不是意外。

也因為是 Verifier 主動停機,官方才會在文件開頭加上那三行警告:執行 Driver Verifier 可能導致電腦當機、只該在用於測試與偵錯的電腦上執行、必須是 Administrators 群組成員。這不是免責聲明,是描述它真正的行為。

Parameter 1 有兩套讀法(這一段是本文的重點)

這是實務上最容易卡住的分岔:Parameter 1 的數值會落在完全不同的命名空間裡,讀法不一樣。本節先講最常遇到的兩種,其餘家族列在本節末。

第一種:傳統子碼(約 0x00 ~ 0x141;官方小節標題寫到 0x140,但該表最後一列實為 0x141)。這些值直接查官方 Bug Check 0xC4 頁面的參數表就能對到原因,而且大多會標明它屬於哪一個 Verifier 選項。例如:

第三欄要特別說明:官方原表只有 Parameter 1–4 與 Cause of Error 五欄,「前提選項」不是官方欄位,而是把官方寫在原因欄尾的那句「A bug check with this parameter occurs only when the … option of Driver Verifier is active」抽出來成欄。官方沒寫的就是「未標註」——不要自行腦補成某個選項,那會誤導你去關錯的檢查項。

注意最後三列:0xA0、0xA1 與 0xB7 的矛頭指向的不是驅動,而是硬碟或主機板韌體。這也是為什麼「先讀 Parameter 1」比「先看兇手模組名」更重要。

第二種:DDI 合規性檢查的規則 ID(0x200nn 形式)。官方明講:DDI compliance checking 的所有規則 ID 都是 0x200nn 的形式,而規則 ID 永遠是這個停止碼的第一個引數。所以當你看到 Parameter 1 是 0x20005 這種五位數的值,別在上面那張子碼表裡繼續找——它被收在官方同一頁的另一張「DDI Compliance Rule Violations」表(小節標題寫 0x00020002–0x00020022,實際列到 0x00020025)。以官方 IrqlExApcLte1(0x20005)這個範例來說,Parameter 2 是指向「違規條件描述字串」的指標——官方 0xC4 參數頁的 0x0002xxxx 各列幾乎一律如此,與偵錯器範例的 Arg2 一致。真正會隨規則 ID 改變的是 Parameter 3 / 4(同一張表就出現三種寫法:指向規則狀態變數的選用指標、內部規則狀態位址〔!ruleinfo 的第二個引數〕、Reserved 未使用),仍須回查官方對應列。最快的查法是在偵錯器裡下 !ruleinfo 加上該 ID。

官方範例正好示範了這條路徑:Arg1: 0000000000020005, ID of the 'IrqlExApcLte1' rule that was violated,!analyze -v 直接把違規條件翻成人話印出來——ExAcquireFastMutex should only be called at IRQL <= APC_LEVEL,而 BUGCHECK_STR 也會變成 0xc4_IrqlExApcLte1_XDV 這種帶規則名的形式。官方範例中 DDI 規則違規的 BUGCHECK_STR 呈現為 0xc4_<規則名>_XDV 的形式,實務上可當辨識線索——但要注意官方文件並未定義 _XDV 尾綴的正式含義,別把它當成規格。

還有第三種:其他規則家族。 官方 0xC4 參數頁其實是由多張表組成的,除了上面兩類,還有 0x1000 起(Deadlocks 死結)、0x2000 起(Code Integrity 程式碼完整性)、0xA001 起(VM Switch)、0x00040003 起(官方標題同樣是 DDI Compliance Rule Violations;其中 CriticalRegions、QueuedSpinLockRelease、SpinlockRelease 三條屬「DDI compliance checking (additional)」選項〔官方註明自 Windows 10 build 19042 起已 deprecated〕,同表其餘規則則屬基本的 DDI compliance checking 選項)、0x00081001 起(AVStream)、0x00091001 起(NDIS)等規則違規區段。這裡有個官方自身的小矛盾要留意:driver-verifier 頁寫「所有 DDI 規則 ID 都是 0x200nn」,但 0xC4 參數頁另有 0x00040003 起那張同名的 DDI 表——所以判讀原則是:先看你的 Parameter 1 落在哪個數值區間,再去對應那張表,不要只翻第一張、也不要用 0x200nn 這條通則反推家族歸屬。

🛠️ 解決方案

⚠️ 執行前務必詳讀(⭐⭐⭐ 高風險操作)

Driver Verifier 會刻意讓系統當機以取得診斷資訊,官方也明確建議只在測試與偵錯用的電腦上執行。開始之前:

1. 完整備份重要資料,並建立一個系統還原點;

2. 確認你有筆電/主機的電源穩定供應(當機重開時斷電容易帶出檔案系統問題);

3. 若該機器啟用了 BitLocker,先確認你手上有復原金鑰;

4. 準備好一支可開機的 Windows 安裝/修復 USB。

停止條件清單(符合任一,請立刻停手、不要繼續往下做):

– 你不確定這台機器目前的 Windows 版本或版次;

– 尚未完成備份;

– BitLocker 已啟用但你手上沒有復原金鑰;

– 這是公司或學校控管的設備,而你沒有 IT 部門授權;

– 手邊沒有救援 USB,而機器已經出現無法正常開機的徵兆;

– 指令輸出與本文描述明顯不符。

方法一:先確認「這是誰開的」,再讀 Parameter 1

結論先講:在動任何刀之前,先確認 Driver Verifier 現在是不是還開著、開在哪幾支驅動上。 這一步能省掉九成的冤枉路。

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

verifier /querysettings

verifier /query

/querysettings 會列出「下次開機後」會啟用的選項與被驗證的驅動清單;/query 則顯示 Driver Verifier 目前的活動摘要。如果兩者都顯示沒有任何驅動被驗證,那麼你這顆 0xC4 很可能來自別人交接的機器設定、或是某套測試工具留下的殘留設定——這時第一件事是先確認來源,而不是急著重灌。

接著讀 Parameter 1。從藍屏畫面上通常看不到參數,要從 dump 檔取得:預設 minidump 會落在 %SystemRoot%\Minidump\。如果你的機器連 dump 都沒產生,請先把傾印設定補上——這部分站長在〈當機藍屏一閃就重開?先關自動重新啟動、設好記憶體傾印再抓兇手〉裡寫得比較完整,先把現場保存下來再往下走。

拿到 Parameter 1 之後,照上一節的分岔判讀:五位數的 0x200nn 走 DDI 規則那條線,兩位數的子碼查官方參數表。

方法二:用 WinDbg 把違規條件與兇手模組讀出來

結論先講:!analyze -v 會直接把違規規則的名稱與條件翻成英文句子印出來,不需要你自己去對表。

用 WinDbg 開啟 dump 後,在 kd> 提示字元輸入:

!analyze -v

重點看四個欄位:

• Arg1:也就是 Parameter 1。若是 DDI 規則,這行後面會直接標出規則名稱(例如官方範例的 ID of the 'IrqlExApcLte1' rule that was violated)。
• DV_VIOLATED_CONDITION:違規條件的白話描述,例如 ExAcquireFastMutex should only be called at IRQL <= APC_LEVEL。
• BUGCHECK_STR:形如 0xc4_IrqlExApcLte1_XDV,帶規則名,方便你直接拿去搜官方規則頁。
• IMAGE_NAME / MODULE_NAME / FAILURE_BUCKET_ID:指向實際違規的驅動模組。

如果 !analyze -v 給的資訊還不夠,官方另外提供三個專屬於 Driver Verifier 的偵錯器擴充命令:

!verifier

!deadlock

!iovirp <address>

!verifier 傾印 Verifier 收集到的統計資料(加 -? 可看全部選項);!deadlock 用於死結偵測選項所追蹤的鎖與物件;!iovirp 則顯示 I/O Verifier 追蹤中的某個 IRP。另外,當 Parameter 1 是 DDI 規則 ID 時,可以直接下 !ruleinfo 加上該 ID 查規則說明。

不熟 WinDbg 基本操作的讀者,可以先看站長這篇〈WinDbg 藍畫面 minidump 分析教學〉把符號檔與基本指令搞定,再回來處理 0xC4。

方法三:縮小驗證範圍,然後收工

結論先講:確認違規驅動之後,要做的是「處理那支驅動」與「把 Verifier 關掉」,不是繼續讓機器一直當。

• 範圍太大就縮小:官方明確提到,選擇「驗證這台電腦上所有已安裝的驅動」可能耗盡 Special Pool 與部分資源追蹤可用的資源,也可能對系統效能造成負面影響;Special Pool 與 I/O Verification 這兩個選項一次只驗一支驅動時最有效。所以請改成逐支或少量驗證:

verifier /standard /driver 可疑驅動名稱.sys

• 處理違規驅動:優先到裝置製造商官網更新該驅動;若該驅動來自已經不再維護的舊軟體,考慮移除該軟體。這一步屬於一般驅動更新,不需要動登錄檔。
• 暫時略過單一規則(進階):官方的 verifier /rules disable <ID> 可停用特定規則,而該 ID 就是 Bug Check 0xC4 的 Parameter 1 值;verifier /rules reset 則把所有規則還原成預設狀態。這招適合「已知某規則是誤報、但你還要繼續驗其他項目」的情境,別當成關掉問題的方法。
• 收工:診斷完成後務必關閉:

verifier /reset

然後重新開機。官方對 /reset 的定義是「清除所有 Driver Verifier 設定,下次開機後不會驗證任何驅動」——它不會刪掉你的驅動、也不會改動系統檔案,只是把 Verifier 的設定清空。

補充一個容易踩到的坑:官方註記,在 Windows 版本 20150 到 25126 之間,如果在驅動清單中選了 ntoskrnl,可能會收到 invalid state 錯誤;解法是不要勾 ntoskrnl,或升級到 build 25126 之後的版本。

✅ 驗證修復結果

確認問題真的解決,而不是暫時消失,請照這個順序檢查:

1. 確認 Verifier 已關閉:重開機後再跑一次 verifier /querysettings,應顯示沒有任何驅動會被驗證(官方對 /reset 的說明即為「下次開機後不驗證任何驅動」)。
2. 確認 0xC4 不再出現:正常使用一段時間,並重跑原本會觸發問題的操作情境。
3. 確認原本的症狀也一起好了:這一步最常被跳過。0xC4 消失只代表 Verifier 關了,不代表你最初那個當機的根因被修掉;若原症狀還在,請回到 %SystemRoot%\Minidump\ 看最新的 dump 是什麼停止碼,重新走一次分析。
4. 保留證據:把這次的 dump 與 !analyze -v 輸出存檔,之後若同一支驅動再犯,可以直接比對 FAILURE_BUCKET_ID 是否相同。

🔙 萬一翻車:回退步驟

Driver Verifier 最麻煩的情況是:啟用之後系統在開機途中就違規當機,於是進不了桌面、也就沒機會下 verifier /reset。 依嚴重程度分三段處理。

情境一:還進得了桌面,只是很不穩

以系統管理員執行 verifier /reset,重新開機即可回到原狀。

情境二:進不了一般桌面,但進得了安全模式

Driver Verifier 的設定是持久性的(官方預設 bootmode 為 persistent,會跨多次重開機持續生效),所以必須主動清除:

1. 讓系統自動進入修復環境——官方列出五種自動觸發 WinRE 的條件,與本情境相關的是這三種:連續兩次 Windows 啟動失敗、開機完成兩分鐘內連續兩次非預期關機、開機完成兩分鐘內連續兩次系統重開;也可以直接用救援 USB 開機;
2. 選擇「疑難排解 → 進階選項 → 啟動設定 → 重新啟動」,開機後選官方清單第 6 項「安全模式(含命令提示字元)」(原文 Safe Mode with Command Prompt;官方說明以數字鍵或 F1–F9 功能鍵選取);
3. 在命令提示字元執行 verifier /reset;
4. 重新開機。

情境三:上述都不通

使用系統還原點回到啟用 Verifier 之前的狀態(這就是為什麼「開始前的準備」要你先建立還原點)。若連還原點都沒有,請把資料備份出來後再考慮重裝——此時已超出本文範圍,建議尋求原廠或專業維修協助。

更好的做法:把救援變成預防

官方提供了 /bootmode 參數,可以在啟用 Verifier 的當下就先決定「萬一開不了機怎麼辦」:

要變更 /bootmode 必須重新開機才會生效。另外 Windows 11 語法還提供 verifier /bc <重開機次數>,用來指定驗證要持續幾次重開機,這個選項會自動套用 resetonunusualshutdown 模式。

站長的建議很簡單:一般除錯用途,啟用 Verifier 時就順手把 bootmode 設成 resetonbootfail 或 oneboot,等於幫自己預先裝了一個保險絲——真的開不了機時,系統會自己把 Verifier 關掉,你連安全模式都不用進。

💡 總結:預防再次發生

站長我看過太多人把 0xC4 當成「新的災難」,急著重灌,結果把唯一一份能指出兇手的證據一起格式化掉。我自己的判讀習慣是:看到停止碼裡有 DRIVER_VERIFIER 這幾個字,第一個動作不是修,是先確認 Verifier 是誰開的、開了哪些選項——因為這顆藍屏是被「請」出來的,它的價值在於它把違規現場完整地凍結下來了。這跟處理 0x50、0x1A 那種被動崩潰的心態完全相反。

要避免下次再手忙腳亂,三件事就夠:

1. 啟用前先設 bootmode:用 resetonbootfail 或 oneboot,把「開不了機」這個最壞情況先關掉。
2. 一次只驗少數驅動:官方已經說明,全選可能耗盡 Special Pool 的資源、也可能拖慢系統,而 Special Pool 與 I/O Verification 在單一驅動上最有效——診斷精度反而更高。
3. 診斷完立刻 verifier /reset:Verifier 不是防護工具,是壓力測試工具。留著它,只會讓機器在日常使用中持續被人為地推向極限。

最後提醒一句,官方的定位講得很直白:Driver Verifier 是給開發與測試環境用的工具。在生產機器上長期掛著跑,得到的不是穩定,是計畫外的當機。

❓ 常見問題

Q:跳 0xC4 是不是代表我的電腦壞了?

多半不是。0xC4 是 Driver Verifier 找到致命錯誤時的通用停止碼——先確認 Verifier 是不是開著。若確實開著,那這是工具照設計運作的結果,不是硬體損壞。

Q:Parameter 1 是 0x20005,我在官方的參數表裡找不到,為什麼?

其實查得到,只是不在 0x00–0x140 那幾張子碼表——官方同一頁另有「DDI Compliance Rule Violations」專表——小節標題寫 0x00020002–0x00020022,實際列到 0x00020025。官方也明訂規則 ID 永遠是這個停止碼的第一個引數,所以更快的做法是用 !analyze -v 讀 DV_VIOLATED_CONDITION,或用 !ruleinfo 加上該 ID 查詢。

Q:我沒有開 Driver Verifier,為什麼也跳 0xC4?

先用 verifier /querysettings 確認——常見來源是二手機或公司機沿用了前一位使用者的設定、或某些驅動安裝程式/測試工具留下了殘留設定。確認之後執行 verifier /reset 再重開機。

Q:啟用 Verifier 之後開不了機,是不是只能重灌?

不是。先進入安全模式執行 verifier /reset;進不了安全模式就用還原點。下次啟用時記得先把 /bootmode 設成 resetonbootfail,系統會在啟動失敗後自動停用 Driver Verifier。

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

比對新舊 dump 的 FAILURE_BUCKET_ID 與 IMAGE_NAME 是否相同。相同表示同一支驅動、同一條規則又犯,請往驅動版本回退或改用其他版本;不同則是另一個違規,要重新從 Parameter 1 判讀。

🔗 延伸閱讀

• BAD_POOL_CALLER 0xC2 藍屏怎麼修?讀懂 Parameter 1 揪出兇手驅動
• KERNEL_MODE_HEAP_CORRUPTION(0x13A)藍屏怎麼修?讀懂官方 21 種參數
• PFN_LIST_CORRUPT 0x4E 藍屏怎麼修?讀懂官方八個參數,分流驅動或硬體
• THREAD_STUCK_IN_DEVICE_DRIVER(0xEA)藍屏排錯教學
• BSOD 跳 PAGE_FAULT_IN_NONPAGED_AREA(0x50)?別急著換 RAM

📎 參考資料來源

📖 第一級|廠商官方:

• Microsoft Learn:Bug Check 0xC4 DRIVER_VERIFIER_DETECTED_VIOLATION — 2026-07-26 查證
• Microsoft Learn:Driver Verifier(工具總覽與使用方式) — 2026-07-26 查證
• Microsoft Learn:Handling a Bug Check When Driver Verifier is Enabled — 2026-07-26 查證
• Microsoft Learn:Driver Verifier Command Syntax — 2026-07-26 查證
• Microsoft Learn:Small Memory Dump(minidump 預設路徑) — 2026-07-26 查證
• Microsoft Learn:Windows Recovery Environment (Windows RE) 技術參考 — 2026-07-26 查證
• Microsoft Support:Windows 啟動設定(安全模式選項清單) — 2026-07-26 查證

⚠️ 本文核心事實以第一級為準,第二級為補充。

📅 本文查證戳記:2026-07-26 依據 Microsoft 官方文件(Bug Check 0xC4、Driver Verifier、Driver Verifier Command Syntax)整理撰寫,非站長第一手實測。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。