文章屬性 :疑難排除(底層除錯) 適用系統 :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 常見情境(站長推論,非官方清單): 拔掉外接裝置(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 的四個參數如下: 這組參數的形狀是 記憶體存取違規型 ,不是資源清單型——它告訴你「誰去碰了哪裡」,不會直接告訴你「哪一支驅動忘了收哪一樣東西」。 參數 3 是判讀主力 :它是發出這次存取的指令位址。站長的實務判斷是,這個位址落在已卸載模組的位址區間時,方向基本上就確定了(官方未針對這點作陳述,這是推論)。 參數 2 是讀或寫,可以拿來分辨是「回呼跳進空位址」還是「還在往已釋放的緩衝區寫資料」,兩者的犯案模式不同。 參數 4 官方標明保留,任何把它解讀成子類型的說法都不要採信。 另外官方有一句對排錯很有用的補充: 若系統能辨識出肇事的驅動,它的名稱會印在藍屏上,並且存放在記憶體中 KiBugCheckDriver (型別為 PUNICODE_STRING)所在的位置。 藍屏畫面上有 .sys 檔名時,不要忽略它——這是系統自己指名的,可信度高於任何猜測。 🧭 與相近錯誤碼比較:0xCE、0xC4、0xCB、0xC5 差在哪 這幾顆碼常被混為一談,但它們問的是完全不同的問題: 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 開啟傾印檔後,先跑官方指定的第一支指令: 官方對 0xCE 的 Resolution 寫的是 !analyze ——這支偵錯延伸模組會顯示這次錯誤檢查的資訊,有助於判定根因;至於上面那個 -v ,官方是在 Driver Verifier 頁示範的:想多印出可協助指認肇事驅動的資訊時,在 kd> 提示字元下加上它。看報告時把三個地方對起來:停止碼是否為 0x000000CE 、藍屏上是否已經指名某個 .sys 、以及參數 3 的位址。 官方文件裡的 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)裡 ,所以實務上一行就夠(請先讀完上面的警語與回退步驟): 若要單獨啟用,官方給的旗標分別是:Miscellaneous Checks 是 Bit 11(0x800) 、Pool Tracking 是 Bit 3(0x8) 。 設定會在下次開機後生效。Windows Vista 之後也支援不重開機的暫時性設定,官方的完整範例是: 請照抄官方寫法——這一行用的是 /adddriver 而不是 /driver 。這種設定立即生效,但在關機或重開機後就會消失。 當機之後,除了 !analyze -v ,官方也指定了偵錯延伸模組 !verifier 來看驗證結果。官方在 Miscellaneous Checks 的範例中用 !verifier 1 顯示目前啟用的選項與統計;要追未釋放的配置則用: 官方說明它可以在驅動卸載之後找出仍未釋放的配置,並且會顯示每一筆配置的 pool tag、大小,以及配置者的位址。 「配置者的位址」是這一步最有價值的輸出 ——它直接指向是誰做的配置。 要提醒的是:0xC4 的參數 1 是子碼, 會隨違規類型不同而不同 (官方在 Miscellaneous Checks 的實例中示範的是 0xD2 ,代表釋放了仍含有作用中 ERESOURCE 的集區配置)。不要預期一定會看到某個特定子碼,以 !analyze -v 的輸出為準。 若要確認目前掛了哪些驅動與設定,官方提供這兩支查詢指令: Driver Verifier 的完整操作流程、選項意義與救援方式,站內另有一篇專文: Driver Verifier 完整使用教學 。同一套工具在別的停止碼上怎麼用,可以對照 MULTIPLE_IRP_COMPLETE_REQUESTS(0x44)的排錯流程 。 修好沒有,不能只看「今天沒當機」。建議用三個訊號一起判斷: Driver Verifier 已經確實關閉 :跑 verifier /querysettings 確認沒有殘留設定。這一步常被跳過,結果是後續每一次當機都被驗證器本身放大,判讀全亂。 重現原本的觸發動作 :0xCE 綁在卸載這個動作上,所以要刻意去做原本會出事的事——反覆拔插那個外接裝置、在裝置管理員停用再啟用、進出睡眠。做十次都沒事,比放著不管一個星期更有說服力。 事件檢視器沒有新的關聯紀錄 :確認同一支驅動沒有再出現載入失敗或裝置異常的記錄。 如果換版之後仍然復發,而且傾印指向同一支驅動,那就不是版本選錯,而是這支驅動本身有問題——該做的是回報給裝置廠商,或評估改用其他裝置。 使用者端無法修好別人的驅動程式碼,這點必須說清楚。 Driver Verifier 最典型的意外,是啟用之後系統一開機就當、進不了桌面。先別急,官方留了關掉它的路。 情境一:還能進得了桌面。 用系統管理員身分開啟命令提示字元,執行官方的重設指令,然後重開機: 也可以開啟 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 這條退路你會用。 先確認 Driver Verifier 已經關閉( verifier /querysettings ),排除是驗證器本身造成的當機。若換版後仍復發、傾印又指向同一支驅動,那就是這支驅動本身的瑕疵,使用者端沒有修改的空間;此時該做的是向裝置廠商回報傾印檔與版本資訊,並在問題修正前避免使用該裝置或改用替代方案。 NO_MORE_IRP_STACK_LOCATIONS(0x35)藍屏怎麼修?揪出插隊裝置堆疊的過濾驅動 DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏怎麼修?用 Special Pool 揪出真兇驅動 DRIVER_VERIFIER_DETECTED_VIOLATION(0xC4)藍屏怎麼修?讀懂 Parameter 1 揪出違規驅動 WinDbg Preview 安裝與符號路徑設定完整教學 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。 若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。