DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS 0xCE 藍屏怎麼修

⚡ 站長快讀:核心重點

文章屬性:疑難排除(底層除錯)
適用系統:Windows 10 / Windows 11
難易度 / 耗時:⭐⭐⭐ / 判讀約 20 分鐘
核心結論:DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS 0xCE 官方定義是驅動卸載前沒取消擱置中的操作,漏收的是 lookaside list、DPC 與工作執行緒。當機那一刻,肇事的驅動早就離場了。
適用對象:藍屏跳 0x000000CE,或拔裝置、換驅動、移除軟體後開始隨機當機的人

📌 快速答案

一句話答案:DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS 0xCE 的排錯路線,是先從傾印檔的已卸載模組清單找出剛離場的那支驅動,再用 Driver Verifier 的標準設定把違規的當機時間點提前到卸載當下。

🧰 開始前的準備

適用系統:Windows 10、Windows 11。官方說明 Driver Verifier 內建於大多數 Windows 版本的 %WinDir%\system32\,檔名為 Verifier.exe,不另外提供下載安裝包(Windows 10 S 未內含)
權限需求:系統管理員。官方明訂使用 Driver Verifier 必須是該電腦 Administrators 群組的成員
需要工具:WinDbg、內建的 verifier.exe、事件檢視器、裝置管理員
必備前置:先確認系統會留下傾印檔。已卸載模組清單是這顆碼的重要線索(站長實務判斷),沒有傾印檔就只能靠猜
預計耗時:讀傾印約 20 分鐘;開了 Driver Verifier 之後要等問題復現,可能數小時到數天

🔍 症狀描述與錯誤訊息

先講清楚底下這份症狀清單的性質:官方的 Bug Check 0xCE 頁面只寫參數、成因與排查方向,沒有列舉任何症狀。以下是站長從這顆碼的成因(驅動卸載時沒有取消擱置中的操作)往回推、再加上維修現場常見情境整理的,請當成比對用的線索,不是官方判準。

藍屏畫面上會出現這樣的字樣:

🙁 你的電腦發生問題,需要重新啟動⋯⋯
停止碼:DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
失敗的項目:某某.sys

常見情境(站長推論,非官方清單):

拔掉外接裝置(USB 音效卡、擷取卡、外接網卡、加密狗)之後幾秒鐘藍屏
更新、回滾或解除安裝某支驅動並重開機後,系統在閒置時隨機當機
解除安裝安全軟體、VPN、虛擬網卡、螢幕錄影工具之後開始不穩定
從睡眠或休眠喚醒後藍屏,而且不是每次都發生
記憶體診斷、硬碟檢測全部正常,換過記憶體照樣復發

最後一項特別值得注意。0xCE 的官方成因寫在軟體層,它不是拿來指控記憶體模組的碼;維修現場最常見的浪費,就是看到藍屏參數裡有記憶體位址就直接送修記憶體。

🔎 問題根因

先給結論:0xCE 幾乎都是驅動品質問題,而且是「善後沒做完」這一類的問題,不是硬體壞掉。

官方對成因只寫了一句話,但這句話的資訊密度很高:這支驅動在卸載前,沒有取消 lookaside list、DPC(延遲程序呼叫)、工作執行緒或其他類似項目。拆開來看有三個重點:

第一,出問題的動作是「卸載」。 驅動被卸載的時機比多數人以為的多——裝置被拔除、使用者在裝置管理員停用裝置、軟體解除安裝、驅動更新換版,或是最後一個裝置物件被移除、系統不再有參考的時候(最後這項是站長的經驗歸納)。這也是為什麼 0xCE 常常「不是當下」發作,而是在一次拔插或一次解除安裝之後才開始。

第二,漏掉的不是記憶體,是「還會回頭找它的東西」。 官方列的三樣——lookaside list、DPC、工作執行緒——共同點是:它們都會在未來某個時間點,由系統主動呼叫回驅動的程式碼。驅動走了、程式碼所在的映像被釋放,這些預約卻還留在核心的排程佇列裡。

第三,官方用的動詞是 cancel(取消),不是 free(釋放)。 這個用字差異很關鍵:0xCE 要求的不是「把記憶體還回去」,而是「把已經預約出去的回呼取消掉、並且確認正在跑的那一輪跑完」。只釋放記憶體、卻沒有取消計時器與 DPC,反而會讓情況更糟——系統之後不但會呼叫到不存在的程式碼,還可能拿到一塊已經被別人重用的緩衝區。

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

結論先講:0xCE 是一顆「延遲引爆」的碼,爆點與犯案點之間隔著一段時間差,這正是它難查的原因。

官方對卸載常式的要求

Microsoft 對 Unload 常式的規定寫得很直接:任何可以在系統執行中被替換、或被卸載後重新載入的驅動,都必須有 Unload 常式,而所有 WDM 驅動都必須有 Unload 常式;非 WDM 驅動的 Unload 常式雖然是選用的,但官方註明 Driver Verifier 會讓沒有提供 Unload 常式的驅動不通過檢驗。

至於這個常式要做什麼,官方的描述是:非 PnP 驅動的 Unload 常式必須釋放裝置物件、釋放驅動配置的資源,簡單說就是把 DriverEntry 與 Reinitialize 常式在初始化時做過的事情全部還原。0xCE 就是這條規定沒被履行時,系統事後開出的罰單。

為什麼會有時間差

以 DPC 為例。DPC 是驅動把「等一下再做」的工作排進核心佇列的機制,實際執行的時機由系統決定。如果驅動在卸載時沒有把已排入的 DPC 收乾淨,佇列裡就留著一個指向該驅動程式碼的函式位址;等系統真的輪到執行這個 DPC,那段程式碼所在的映像已經被卸載,系統就跳進一塊不再屬於任何模組的位址。

官方提供給驅動開發者收尾的工具之一是 KeFlushQueuedDpcs。它的行為官方寫得很清楚:這個常式會在所有處理器上目前已排入佇列的 DPC 都執行完畢之後才返回;而且只保證呼叫之前排入的 DPC 執行完成,呼叫期間新排進來的不在保證範圍內。官方同時提醒它可能要很久才會返回,不應該放在任何關鍵程式路徑上。這幾句話反過來讀,正好說明了 0xCE 的成因:收尾這件事有明確的先後順序,先停止產生新工作,再等既有工作跑完,最後才可以讓映像離開記憶體。 順序做錯,就是 0xCE。

藍屏參數怎麼讀

官方給 0xCE 的四個參數如下:

參數	官方說明	白話解讀
1	Memory address referenced	被存取的那個記憶體位址
2	0:Read / 1:Write	這次存取是讀還是寫
3	Address that referenced memory(if known)	發出這次存取的指令位址(若已知)
4	Reserved	保留欄位,不用判讀

重點摘要:

這組參數的形狀是記憶體存取違規型,不是資源清單型——它告訴你「誰去碰了哪裡」,不會直接告訴你「哪一支驅動忘了收哪一樣東西」。
參數 3 是判讀主力:它是發出這次存取的指令位址。站長的實務判斷是,這個位址落在已卸載模組的位址區間時,方向基本上就確定了(官方未針對這點作陳述,這是推論)。
參數 2 是讀或寫,可以拿來分辨是「回呼跳進空位址」還是「還在往已釋放的緩衝區寫資料」,兩者的犯案模式不同。
參數 4 官方標明保留,任何把它解讀成子類型的說法都不要採信。

另外官方有一句對排錯很有用的補充:若系統能辨識出肇事的驅動,它的名稱會印在藍屏上,並且存放在記憶體中 KiBugCheckDriver(型別為 PUNICODE_STRING)所在的位置。 藍屏畫面上有 .sys 檔名時,不要忽略它——這是系統自己指名的,可信度高於任何猜測。

🧭 與相近錯誤碼比較:0xCE、0xC4、0xCB、0xC5 差在哪

這幾顆碼常被混為一談,但它們問的是完全不同的問題:

停止碼	官方一句話	通常什麼時候爆	先查什麼
0xCE	驅動卸載前未取消擱置中的操作	驅動離場後,系統回頭呼叫時	已卸載模組清單
0xC4(參數 1 = 0x62)	Driver Verifier 偵測到違規	驅動卸載當下,由 Pool Tracking 攔截	該驅動未釋放的配置
0xCB	驅動或 I/O 管理員在 I/O 結束後未釋放鎖定頁面	I/O 完成後	鎖定中的 MDL
0xC5	系統在過高的 IRQL 存取無效記憶體	池被寫壞之後的任意時點	小於一個分頁的配置是否被寫爆

重點摘要:

0xCE 與 0xC4(0x62)相關,但不等價:官方定義前者是「卸載前未取消 lookaside list、DPC、工作執行緒」,後者是「卸載時仍有未釋放的記憶體配置」。兩件事可以各自單獨發生——DPC 收乾淨卻漏了 free,傾向只出 0x62;free 得乾乾淨淨卻漏了 cancel,傾向只出 0xCE。實際會開出哪一顆碼,取決於當時啟用了哪些 Driver Verifier 選項;把 Driver Verifier 掛上去的價值在於把當機時間點往前挪到卸載當下,而不是保證會出現哪一個子碼。
0xCB 管的是鎖定頁面,官方定義是驅動或 I/O 管理員在 I/O 操作結束後沒有釋放鎖定的頁面;官方另註明,啟用 Pool Tracking 時 Driver Verifier 也會開出這顆碼。
0xC5 是池被寫壞,官方直指問題根源幾乎必然是某支驅動破壞了系統池,排錯手段是 Driver Verifier 的 Special Pool,與 0xCE 的排查方向不同。
排錯起點不是同一支指令:0xCE 與 0xC5 官方 Resolution 都指向 !analyze,0xCB 官方指定的則是 !lockedpages(列出目前程序所有鎖定中的 MDL)。先讀傾印、確認是哪一顆碼,再決定用哪支延伸模組,不要一開始就亂槍打鳥。

🛠️ 解決方案

⚠️ 執行前務必先看:方法三會啟用 Driver Verifier。官方明白警告——執行 Driver Verifier 可能導致電腦當機,並建議只在用於測試與偵錯的電腦上執行。請先做好資料備份、建立系統還原點,並確認筆電接上電源或桌機電源穩定。開始之前,請先把下面的回退步驟讀完再動手。

停止條件清單(符合任何一項,請先停手):

不確定自己的 Windows 版本或裝置型號
尚未完成資料備份
已啟用 BitLocker 但手邊沒有修復金鑰
這台是公司或學校的管控裝置,且沒有 IT 授權
沒有可開機的救援 USB,而這是唯一一台可用的電腦
指令輸出與本文描述明顯不符

方法一:先讀傾印,把「剛離場」的模組抓出來(建議所有人先做)

這一步的目標只有一個:找出當機瞬間剛被卸載的那支驅動。

用 WinDbg 開啟傾印檔後,先跑官方指定的第一支指令:

!analyze -v

官方對 0xCE 的 Resolution 寫的是 !analyze——這支偵錯延伸模組會顯示這次錯誤檢查的資訊,有助於判定根因;至於上面那個 -v,官方是在 Driver Verifier 頁示範的:想多印出可協助指認肇事驅動的資訊時,在 kd> 提示字元下加上它。看報告時把三個地方對起來:停止碼是否為 0x000000CE、藍屏上是否已經指名某個 .sys、以及參數 3 的位址。

接著列出模組清單:

lm

官方文件裡的 lm 示範輸出,在 kd> 提示字元下,清單末尾會另外列出一段 Unloaded modules:,逐筆給出起始位址、結束位址與模組檔名(該頁的文字說明是就使用者模式程序而言,核心模式這段清單以官方示範輸出與 !analyze -v 報告中的同名區段為準)。這段清單就是 0xCE 的關鍵證物:把參數 3 的位址拿去對照,如果落在某個已卸載模組的位址區間裡,那支驅動就是第一嫌疑人。

如果報告裡的模組名稱是空的、或者指向 ntoskrnl.exe 這類系統核心模組,不要就此收工。0xCE 的性質決定了開槍的是系統、扣扳機的是別人,系統模組出現在堆疊上是預期內的結果。關於 !analyze -v 各欄位的完整讀法,可以參考站內的 WinDbg !analyze -v 完整教學。

方法二:回滾最近變動過的驅動(門檻最低,實務成功率最高)

如果傾印指向某支第三方驅動,或者根本讀不到傾印,就從「最近改了什麼」下手。

0xCE 的觸發條件與「卸載」綁在一起,所以它跟時間軸的關聯性,比多數藍屏都強。建議照這個順序做:

開啟事件檢視器,把當機時間點前後的「系統」記錄拉出來,特別看有沒有驅動安裝、裝置移除、服務啟停的紀錄。
在裝置管理員找到對應裝置,開啟內容 →「驅動程式」頁籤 → 如果「回復驅動程式」是可以按的,直接回上一版。這是官方內建、風險最低的做法。
如果按鈕是灰色的,改用系統還原點回到問題發生前的狀態。
外接裝置的驅動,優先到裝置原廠網站抓對應型號的版本,不要只靠 Windows Update 派送的通用版。

站長的實務判斷是:這一步能解掉的比例比大家想像的高。0xCE 是驅動程式碼層級的瑕疵,一般使用者無法修改別人的驅動,能做的就是換一個沒有這個瑕疵的版本;而「換版本」本來就是這顆碼最務實的解法。

方法三:用 Driver Verifier 的標準設定逮現行犯

當你有嫌疑名單、但無法確認是哪一支時,才輪到這一步。

Driver Verifier 的價值在於,它會把違規行為的當機時間點提前到犯案當下。官方說明:所有被 Driver Verifier 偵測到的違規都會產生錯誤檢查,而且典型就是 Bug Check 0xC4。

這裡有一個很多人搞混的地方,先講清楚:0xCE 官方成因裡的 lookaside list 與工作項目這一類,對得上的選項是 Miscellaneous Checks,不是 Pool Tracking。官方對 Miscellaneous Checks 的描述是,它會監看「釋放了仍含有作用中核心物件的記憶體」這類常見錯誤,明列的行為包含:釋放仍含有已排入工作項目(work item)的集區區塊、釋放仍含有作用中 lookaside list 的集區區塊、以及驅動嘗試卸載卻沒有取消註冊 WMI 回呼。而 Pool Tracking 官方的定義是「在驅動被卸載的時間點,確認這支驅動的所有配置都已經釋放」,未釋放時開出 0xC4 且參數 1 等於 0x62——那是記憶體洩漏,不是沒取消回呼。要注意兩個選項都沒有直接涵蓋 DPC 這一項,所以請把 Driver Verifier 當成縮小範圍的工具,不是 0xCE 的一鍵解答。

好消息是,兩個選項官方都註明已包含在標準設定(standard settings)裡,所以實務上一行就夠(請先讀完上面的警語與回退步驟):

verifier /standard /driver 嫌疑驅動.sys

若要單獨啟用,官方給的旗標分別是:Miscellaneous Checks 是 Bit 11(0x800)、Pool Tracking 是 Bit 3(0x8)。

verifier /flags 0x800 /driver 嫌疑驅動.sys

設定會在下次開機後生效。Windows Vista 之後也支援不重開機的暫時性設定,官方的完整範例是:

verifier /volatile /flags 0x800 /adddriver 嫌疑驅動.sys

請照抄官方寫法——這一行用的是 /adddriver 而不是 /driver。這種設定立即生效,但在關機或重開機後就會消失。

當機之後,除了 !analyze -v,官方也指定了偵錯延伸模組 !verifier 來看驗證結果。官方在 Miscellaneous Checks 的範例中用 !verifier 1 顯示目前啟用的選項與統計;要追未釋放的配置則用:

!verifier 0x3

官方說明它可以在驅動卸載之後找出仍未釋放的配置,並且會顯示每一筆配置的 pool tag、大小,以及配置者的位址。「配置者的位址」是這一步最有價值的輸出——它直接指向是誰做的配置。

要提醒的是:0xC4 的參數 1 是子碼,會隨違規類型不同而不同(官方在 Miscellaneous Checks 的實例中示範的是 0xD2,代表釋放了仍含有作用中 ERESOURCE 的集區配置)。不要預期一定會看到某個特定子碼,以 !analyze -v 的輸出為準。

若要確認目前掛了哪些驅動與設定,官方提供這兩支查詢指令:

verifier /query

verifier /querysettings

Driver Verifier 的完整操作流程、選項意義與救援方式,站內另有一篇專文:Driver Verifier 完整使用教學。同一套工具在別的停止碼上怎麼用,可以對照 MULTIPLE_IRP_COMPLETE_REQUESTS(0x44)的排錯流程。

✅ 驗證修復結果

修好沒有,不能只看「今天沒當機」。建議用三個訊號一起判斷:

Driver Verifier 已經確實關閉:跑 verifier /querysettings 確認沒有殘留設定。這一步常被跳過,結果是後續每一次當機都被驗證器本身放大,判讀全亂。
重現原本的觸發動作:0xCE 綁在卸載這個動作上,所以要刻意去做原本會出事的事——反覆拔插那個外接裝置、在裝置管理員停用再啟用、進出睡眠。做十次都沒事,比放著不管一個星期更有說服力。
事件檢視器沒有新的關聯紀錄:確認同一支驅動沒有再出現載入失敗或裝置異常的記錄。

如果換版之後仍然復發,而且傾印指向同一支驅動,那就不是版本選錯,而是這支驅動本身有問題——該做的是回報給裝置廠商,或評估改用其他裝置。使用者端無法修好別人的驅動程式碼,這點必須說清楚。

🔙 萬一翻車:回退步驟

Driver Verifier 最典型的意外,是啟用之後系統一開機就當、進不了桌面。先別急,官方留了關掉它的路。

情境一:還能進得了桌面。 用系統管理員身分開啟命令提示字元,執行官方的重設指令,然後重開機:

verifier /reset

也可以開啟 Driver Verifier 管理員(在命令提示字元輸入 verifier),選「刪除現有設定」再按「完成」,同樣需要重開機。

情境二:進不了桌面、開機就藍屏。 進安全模式,在安全模式下執行同一條 verifier /reset 再重開機。多數情況下 Driver Verifier 的檢查在安全模式不會把系統打掛,因為載入的驅動少很多(這是站長的實務作法,官方未針對安全模式作此陳述)。

情境三:連安全模式都進不去。 用救援 USB 進入 Windows 修復環境,以系統還原點回到啟用 Driver Verifier 之前的狀態。這也是為什麼前面的警語要求先建立還原點——還原點是這一步唯一低成本的退路。

情境四:啟用 BitLocker 的裝置。 上述任何一種救援都可能要求輸入修復金鑰。沒有金鑰就不要開始,這條沒有例外。

💡 總結:預防再次發生

站長我處理 0xCE 這類碼的時候,習慣先做一件事:把「這台電腦最近多了什麼、少了什麼」問清楚,再開 WinDbg。原因很現實——這顆碼的觸發條件是卸載,而卸載幾乎都跟一次人為動作有關:插了新裝置、裝了新軟體、更新了驅動、把某個工具解除安裝。問清楚時間軸,常常比讀十分鐘傾印更快縮小範圍。這是判讀習慣的分享,不是實測數據。

日常能做的預防,大概是這三件:

驅動不要一有新版就衝。0xCE 是驅動品質問題,而剛釋出的版本正是這類瑕疵最容易出現的時候。等一兩週再更新,成本很低。
解除安裝要走原廠的移除工具。虛擬網卡、安全軟體、擷取卡這類會裝核心驅動的軟體,用控制台隨手移除常常留下半截狀態,而半截狀態正是卸載相關錯誤的溫床。
留著傾印檔。已卸載模組清單是這顆碼的重要線索,而它是核心的記憶體內結構,重開機後不保證還在(官方文件未直接陳述其保留期限,這是結構性質的推論)。當機後把傾印檔先複製一份出來,比事後回想有用得多。

最後提醒一件觀念上的事:看到藍屏參數裡有記憶體位址,不代表記憶體壞了。0xCE 的官方成因寫在軟體層,它從頭到尾指的都是驅動的收尾行為。

❓ 常見問題

Q:0xCE 藍屏是不是記憶體壞掉?要不要換 RAM?

官方對 0xCE 的成因描述完全落在軟體層——驅動卸載前沒有取消 lookaside list、DPC、工作執行緒等項目,沒有任何一句指向記憶體模組故障。參數 1 是「被存取的記憶體位址」,那是存取行為的目標,不是「這顆記憶體壞了」的意思。建議先照方法一、方法二走,記憶體診斷可以做,但不該是第一順位。

Q:是不是我剛更新的驅動造成的?

有相當高的機率是,但要對得上時間軸才能下結論。0xCE 的觸發點是驅動卸載,而更新驅動的過程本身就包含一次卸載。請用事件檢視器把當機時間與驅動安裝時間對起來;對得上,就先用裝置管理員的「回復驅動程式」回上一版驗證。

Q:0xCE 跟 0xC4、0xCB、0xC5 到底差在哪?

它們都跟驅動有關,但問的問題不同:0xCE 問的是卸載時有沒有把已預約的回呼取消掉,爆點在驅動離場之後;0xC4 是 Driver Verifier 偵測到違規時開的碼,參數 1 為 0x62 時官方定義是卸載時仍有未釋放的配置;0xC5 官方定義是系統在過高的 IRQL 存取無效記憶體,根源是池被寫壞;0xCB 是 I/O 結束後沒有釋放鎖定頁面,官方指定用 !lockedpages 追。同樣是驅動出包,取證工具與觀察時機都不一樣,不能套用同一份流程。

Q:要怎麼用 Driver Verifier 抓出兇手驅動?會不會把電腦搞壞?

用 verifier /standard /driver 嫌疑驅動.sys 掛上標準設定(官方註明 Pool Tracking 與 Miscellaneous Checks 都已含在其中),等它在卸載當下開出 0xC4——參數 1 這個子碼會隨違規類型不同,不要預設一定是某個值,以 !analyze -v 輸出為準;要追未釋放的配置再用 !verifier 0x3 看 pool tag 與配置者位址。風險必須講清楚:官方明白警告執行 Driver Verifier 可能導致電腦當機,並建議只在測試與偵錯用的電腦上執行。務必先備份、建還原點,並確認 verifier /reset 這條退路你會用。

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

先確認 Driver Verifier 已經關閉(verifier /querysettings),排除是驗證器本身造成的當機。若換版後仍復發、傾印又指向同一支驅動,那就是這支驅動本身的瑕疵,使用者端沒有修改的空間;此時該做的是向裝置廠商回報傾印檔與版本資訊,並在問題修正前避免使用該裝置或改用替代方案。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

Bug Check 0xCE: DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS — 2026-08-13 查證
Driver Verifier — 2026-08-13 查證
Pool Tracking — 2026-08-13 查證
Miscellaneous Checks — 2026-08-13 查證
Writing an Unload Routine — 2026-08-13 查證
Unload Routine Functionality — 2026-08-13 查證
KeFlushQueuedDpcs function (wdm.h) — 2026-08-13 查證
lm (List Loaded Modules) — 2026-08-13 查證
Bug Check 0xCB: DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS — 2026-08-13 查證
Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL — 2026-08-13 查證

⚠️ 本文核心事實以第一級為準。全篇無第一手實測數據,標示為站長推論之處均已於正文逐處註明。

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