MULTIPLE_IRP_COMPLETE_REQUESTS(0x44)藍屏怎麼修?揪出重複完成 IRP 的兇手驅動

⚡ 站長快讀:核心重點

• 文章屬性:疑難排除(底層除錯)
• 適用系統:Windows 10 / Windows 11
• 難易度 / 耗時:⭐⭐⭐ / 判讀約 20 分鐘
• 核心結論:MULTIPLE_IRP_COMPLETE_REQUESTS 0x44 是「有驅動把一個已完成的 I/O 要求封包(IRP)再完成一次」。官方明講,最常見的不是某支驅動自己完成兩次,而是兩支驅動都以為自己擁有這個封包。官方界定的成因在軟體層,所以絕大多數情況下該查的是驅動,不是記憶體。
• 適用對象:藍屏顯示停止碼 0x00000044、換過記憶體卻照樣當機的人

📌 快速答案

一句話答案:MULTIPLE_IRP_COMPLETE_REQUESTS 0x44 的排錯路線是先用 !irp 攤開藍屏參數指向的封包、反推經過哪些驅動,再用 Driver Verifier 的 I/O 驗證讓違規驅動當場停機。

🧰 開始前的準備

• 適用系統:Windows 10、Windows 11(Windows 11 另有 /dif ... /now 免重開機的新語法)
• 權限需求:系統管理員(Driver Verifier 與傾印檔設定都需要)
• 需要工具:WinDbg、內建的 verifier.exe(Driver Verifier)、事件檢視器
• 必備前置:建議把系統設定為產生核心記憶體傾印(Kernel memory dump)。官方對兩種傾印的定義是:核心記憶體傾印包含核心當時使用中的所有記憶體,小型傾印(small memory dump)則固定為 64 KB、只收錄特定頁面,官方並註明其資訊量有限、非當下執行緒直接造成的錯誤可能無法被分析出來。0x44 要查的是封包內容與整串裝置堆疊,站長的實務判斷是:只有小型傾印時常常不夠用(這是推論,官方未針對 !irp 作此陳述)
• 預計耗時:讀傾印約 20 分鐘;開 Driver Verifier 後需等待問題復現,可能數小時到數天

🔍 症狀描述與錯誤訊息

先說明底下這份症狀清單的性質:官方的 Bug Check 0x44 頁面只寫參數、成因與排查方向,沒有列舉任何症狀,以下是站長從這顆碼的成因(過濾式驅動的 IRP 所有權錯亂)往回推、加上維修現場常見情境整理的,請當成比對用的線索,不是官方判準。

典型情況是電腦在做 I/O 的當下藍屏——複製大檔案、掛載虛擬光碟、外接硬碟讀寫、防毒即時掃描、備份軟體跑排程、VPN 連線的瞬間。重開機後看起來一切正常,過幾天又來一次,而且每次當機的「時機」很像,但每次指向的模組卻不一定相同。

藍屏畫面上會顯示「發生問題,需要重新啟動」之類的字樣(各版本用語略有差異),下方附上停止代碼:

停止代碼:MULTIPLE_IRP_COMPLETE_REQUESTS

在 WinDbg 裡跑 !analyze -v,則會看到這樣的抬頭:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)

Arg1: 位址(the address of the IRP)

Arg2 / Arg3 / Arg4: Reserved

這裡就藏著本題最要命的地方:官方文件對 0x44 只定義了一個有意義的參數。根據 Microsoft Learn 的 Bug Check 0x44 頁面,Parameter 1 是 IRP 的位址,Parameter 2、3、4 全部標示為 Reserved(保留,無意義)。換句話說,別的停止碼可以靠四個參數交叉推理,0x44 只給你一個門牌號碼——那個被重複完成的封包在哪裡。

更麻煩的是,!analyze -v 猜出來的 MODULE_NAME 在這顆藍屏上特別容易指錯人。這句是站長依官方那句「第一支驅動的痕跡已被第二支蓋掉」推導出來的實務結論,不是官方原話——官方只講追查困難,沒有針對 MODULE_NAME 這個欄位作任何陳述。原因在下一節,而這也是本文和多數「換記憶體、跑 sfc」型解法最大的差別。

🔎 問題根因

先講結論:0x44 是驅動程式的所有權混亂,不是硬體故障。

Microsoft Learn 對 0x44 的成因寫得很直白:某支驅動呼叫 IoCompleteRequest 要求完成一個 IRP,但這個封包已經被完成過了。

接著官方補上一段對排錯至關重要的話:這是個很難找的臭蟲,因為「最單純的情況——某支驅動試圖把自己的封包完成兩次——通常不是問題的來源」;更常見的是兩支不同的驅動各自認為自己擁有這個封包,而且各自都試著完成它。第一次要求成功,第二次失敗,於是觸發這顆藍屏。

官方接著解釋為什麼追兇困難:「要追出是系統中哪些驅動造成這個錯誤很困難,因為第一支驅動的痕跡已經被第二支蓋掉了。」

這句話請讀兩次。它的意思是:當機當下的呼叫堆疊(call stack)上,站著的是第二個、也就是踩到地雷的那一支;真正先動手完成封包、讓封包提早「死掉」的那一支,早就結束離場了。所以看 !analyze -v 指的模組去 Google、去更新那支驅動,經常是抓錯人——那支很可能只是倒楣的發現者。

那該從哪裡下手? 官方在同一頁給了方向:「不過,目前這個要求的 driver stack 可以透過檢視每一個 stack location 中的 device object 欄位找出來。」也就是說,線索不在呼叫堆疊,而在那顆 IRP 自己身上——它經過哪些裝置、哪些驅動在上面掛了完成常式,全部都寫在封包裡。

這就是 0x44 正確的排錯路線:不追模組,追封包。

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

要讀懂 0x44,得先知道「完成一個 IRP」在 Windows 核心裡到底是什麼動作。

Windows 的 I/O 是分層的。一個讀取請求從應用程式下來,會依序經過檔案系統驅動、磁碟區管理員、分割區管理員、磁碟類別驅動、連接埠驅動……每一層都是一個裝置物件(device object),整串疊起來叫做 device stack。這個請求本身被包成一個 IRP,而 IRP 內部帶著一疊 stack location——每一層驅動有自己的一格,用來放它那一層的參數。

Microsoft Learn 的〈Completing IRPs〉這樣定義:「完成一個 IRP」是個簡稱,意思是「讓 driver stack 中的所有成員都完成這個 I/O 操作」;IRP 被完成之後,I/O 管理員會通知發起請求的應用程式操作已結束。當一支驅動處理完 IRP,它呼叫 IoCompleteRequest,I/O 管理員就會回頭檢查有沒有上層驅動替這個 IRP 設定了完成常式(IoCompletion routine),有的話就逐一往上呼叫,直到整串分層驅動都完成這個 IRP 為止。

關鍵在於:這個「往回走」的動作,設計上只能發生一次。

封包一旦被完成,I/O 管理員就把結果交還給發起者,這個 IRP 的生命週期就結束了——它可能被釋放、被回收、記憶體被拿去做別的事。此時如果有第二支驅動還握著這個位址、以為自己還可以處理它,再呼叫一次 IoCompleteRequest,核心就會發現這個封包狀態不對,直接停機發出 0x44。

那「兩支驅動都以為自己擁有封包」是怎麼發生的?最常見的是過濾式驅動(filter driver)的配對邏輯出錯。過濾驅動掛在原有的 device stack 中間,把 IRP 往下傳、同時掛上自己的完成常式,等下層完成時再回頭做後處理。防毒的檔案系統過濾驅動、磁碟加密、備份快照、虛擬光碟、VPN 的網路過濾驅動,全部屬於這一類。這類驅動要正確處理的邊界情況很多:下層回傳 STATUS_PENDING 時該不該自己完成?取消(cancel)路徑上誰負責收尾?自己配置的 IRP 由誰釋放?任何一個環節寫錯,就會出現「我以為對方會完成,結果我也完成了」的雙重完成。

官方在〈Completing IRPs〉裡特別提醒了其中一個經典陷阱:上層驅動如果自己建立了 IRP,就必須提供一個完成常式來釋放它。這個責任歸屬只要弄錯,雙重完成或記憶體洩漏就會跟著來。

所以 0x44 的本質是:IRP 的所有權契約被違反了。 而契約是寫在程式碼裡的,不是寫在你的記憶體條上——這也是為什麼換 RAM、重灌系統通常不會讓 0x44 消失。

🧭 與相近錯誤碼比較:0x44、0x35、0xC5、0xC9 差在哪

站內已經寫過幾顆 IRP 家族的藍屏,很多讀者會混在一起。它們的共同點是「都跟驅動處理 IRP 有關」,但觸發條件完全不同,排錯路線也不一樣:

三點值得注意:

1. 0x35 比 0x44 更糟。 官方對 0x35 的描述是「這是災難性的狀況」——上層驅動以為自己填好了下層的參數,實際上已經寫到封包尾端之外,代表其他記憶體也一併被破壞了。0x44 至少還停在「所有權錯亂」,0x35 已經在踩踏記憶體。站內對這顆碼另有專文:NO_MORE_IRP_STACK_LOCATIONS(0x35)藍屏怎麼修。
2. 0xC5 是集區被寫壞的後果,不是 IRP 本身的問題。 官方指出,多數情況下是驅動破壞了小於 PAGE_SIZE 的配置才會得到 0xC5,更大的配置則會變成 0xD0(DRIVER_CORRUPTED_MMPOOL),而官方建議的除錯手段是 Driver Verifier 的 special pool。
3. 0xC9 不是「壞事」,是好消息。 它代表你開的檢查員抓到現行犯了。下一節會說明:讓 0x44 變成 0xC9,正是排錯要達成的目標。

🛠️ 解決方案

⚠️ ⭐⭐⭐ 高風險操作警語:本節方法二會啟用 Driver Verifier。Driver Verifier 的設計就是一旦抓到違規立刻停機,因此開啟後系統藍屏頻率會明顯上升,嚴重時可能無法正常開機。動手前請先完成下列準備:

– 備份重要資料,並確認你有可開機的 Windows 安裝或修復 USB

– 建立系統還原點

– 如果裝置啟用了 BitLocker,先確認你手上有復原金鑰(進 WinRE 可能會要求輸入)

停止條件(符合任一,請不要往下做):不確定自己在跑哪個 Windows 版本或版次、沒有完成備份、BitLocker 已啟用但拿不到復原金鑰、公司或學校管控的設備且未取得 IT 授權、手邊沒有救援 USB、指令輸出與本文描述不符。

方法一:先讀傾印,從 IRP 反推 device stack(建議所有人先做)

這是成本最低、也最不容易抓錯人的一步:別急著開 Driver Verifier,先把手上的傾印讀完。

步驟 1|取出 Parameter 1。 在 WinDbg 載入傾印後執行:

!analyze -v

從輸出中抄下 Arg1——那就是被重複完成的 IRP 位址。

步驟 2|把封包攤開。 用 !irp 檢視這顆 IRP。官方文件的語法是 !irp Address [Detail],而且明講:只要 Detail 帶入任意值(例如 1),輸出就會包含 IRP 的狀態、MDL 位址、所屬執行緒,以及所有 I/O stack 的堆疊資訊:

!irp <Arg1 位址> 1

步驟 3|讀那張表。 !irp 的輸出每一列代表一個 stack location,欄位依序是 cmd(主要功能碼)、flg、cl、Device、File、Completion-Context;> 符號標示目前正在處理的那一層。裝置物件下方那行會印出裝置或驅動名稱(例如 \FileSystem\Ntfs、\Driver\disk),而完成常式那一欄印的是設定它的驅動——這正是官方所說「透過每個 stack location 的 device object 欄位找出 driver stack」的實作方式。

步驟 4|找不速之客。 把這串 device stack 從上到下讀一遍,問自己一個問題:這裡面有哪一層不是系統原生的? 防毒、磁碟加密、備份快照、虛擬光碟、遊戲反作弊、VPN、硬碟廠商的最佳化工具,只要出現在這串裡面,就是第一批嫌疑犯。Windows 10 之後 !irp 會直接顯示 IRP 主要功能碼的名稱(例如 IRP_MJ_FILE_SYSTEM_CONTROL),判讀比以前輕鬆很多。

!irp、!process、!thread 的完整讀法,站內另有一篇進階指令教學:用 !process、!irp、!thread 追出卡死的驅動程式與 I/O 請求。

步驟 5|先做便宜的處置。 名單出來後,先更新或暫時移除嫌疑最大的那一支(通常是最近才安裝、或最近才更新的那一支),觀察數天。很多案例到這裡就結束了,不必動用 Driver Verifier。

方法二:用 Driver Verifier 的 I/O 驗證把兇手當場逮住

如果方法一名單太長、或移除後照樣藍屏,才進到這一步。

先建立正確期待:Driver Verifier 不會「修好」0x44,它是把當機點往前搬。 開啟 I/O 驗證後,違規行為會在發生的當下就被抓到並停機,而不是等到第二支驅動踩雷才爆。此時藍屏代碼通常會從 0x44 變成 0xC9 或 0xC4,而這兩顆碼的參數會直接告訴你違規內容與模組——這正是我們要的:用一顆講得更清楚的藍屏,換掉一顆什麼都不肯說的藍屏。

官方在〈I/O Verification〉頁面列出了 Level 1 會抓的違規行為,其中就包含:「把狀態無效、或仍設有取消常式(cancel routine)的 IRP 傳給 IoCompleteRequest」、「試圖釋放仍與執行緒關聯的 IRP」、「把無效的裝置物件傳給 IoCallDriver」。Level 1 一旦抓到,就會發出 Bug Check 0xC9,而第一個參數指出違規類型。

設定命令(先確認再貼)。 以系統管理員身分開啟命令提示字元。官方文件指出,I/O 驗證在命令列上以 Bit 4(0x10) 表示:

verifier /flags 0x10 /driver MyDriver.sys

把 MyDriver.sys 換成你的嫌疑犯檔名。設定會在下次開機後生效。

⚠️ 這一步最重要的一句提醒,官方寫在同一頁:「由於特殊 IRP 集區(special IRP pool)的大小有限,I/O 驗證在一次只驗一支驅動時最有效。」——這就是為什麼「把全部驅動一起勾起來」不但不會比較快,反而容易因為集區耗盡而抓不到真正的違規。請一支一支來,從方法一名單裡嫌疑最大的開始。(注意這裡指的是 Level 1 用來追蹤 IoAllocateIrp 配置之封包的特殊 IRP 集區,不是 Driver Verifier 選項清單裡那個 Special Pool〔旗標 0x1〕。)

如果你想連同標準檢查項目一起開,可以改用官方的標準設定(其中已包含 I/O 驗證):

verifier /standard /driver MyDriver.sys

免重開機的版本(⚠️ 這裡有版本差異,而且官方兩份文件寫得不一致)。 〈I/O Verification〉頁提供的免重開機範例是:

verifier /volatile /flags 0x10 /adddriver MyDriver.sys

但〈Using Volatile Settings〉頁把可用於 /volatile 的旗標依版本列了兩份清單:Windows 10 的清單包含 0x10(I/O verification),而 Windows 11 的清單只剩 0x4、0x20、0x80、0x200、0x400 五項,已不含 0x10。也就是說,上面那道指令在 Windows 11 上不能當成 I/O 驗證的免重開機作法。

Windows 11 的正解是官方的替代選項:規則類別 5 = I/O verification,而〈Driver Verifier Command Syntax〉的 Windows 11 規則類別表把它的「/now」欄標為 yes(可免重開機啟用):

verifier /dif 5 /now /driver MyDriver.sys

官方同時註明:/volatile 參數將在未來版本的 Windows 中淘汰,/dif ... /now 只在目前沒有任何規則類別正在執行時才有效。這兩頁互相矛盾的地方請以你的 Windows 版本為準——Windows 10 走 /volatile /flags 0x10,Windows 11 走 /dif 5 /now;任一版本都可以退回最保守的作法:verifier /flags 0x10 /driver ... 然後重開機。

Driver Verifier 的完整操作(包含 Manager 圖形介面路徑、各檢查項目的意義),站內有專文:Driver Verifier 完整使用教學 2026。

方法三:開 IRP Logging,看這支驅動到底對哪些封包動了手

前兩招都沒收斂到單一兇手時,才動用這招——它會產生大量記錄,適合已經縮小到兩三支候選的情況。

Driver Verifier 的 IRP Logging 功能會監看驅動對 IRP 的使用並留下記錄,記錄以 WMI 形式保存;WDK 內附的 DC2WMIParser(dc2wmiparser.exe)可以把它轉成文字檔。

官方明列了兩個必須注意的限制:

• 必須同時啟用 I/O 驗證。 官方指出,要啟用 IRP Logging 就必須一併啟用 I/O 驗證;IRP Logging 在命令列上是 0x400(Bit 10),所以實務上要下的旗標值是 0x410(0x10 + 0x400)。
• 記錄會被覆蓋、也會消失。 WMI 記錄對每個裝置最多只留 20 筆 IRP,第 21 筆進來就把第一筆蓋掉;而且記錄存在記憶體裡,電腦一重開就沒了。因此官方建議用 DC2WMIParser 把資訊存成檔案。

verifier /flags 0x410 /driver MyDriver.sys

存檔則使用 DC2WMIParser 的 /f(輸出檔名)與 /t(持續分鐘數)參數;/t 為 0 時,它會把 Driver Verifier 已經記下的資訊寫出後結束。

到這一步若確認違規來自某支第三方驅動,實務上的終點就是三選一:更新到廠商修正版、改用替代軟體、或永久移除。使用者端無法修正別人的驅動程式碼——這點必須誠實說清楚。

✅ 驗證修復結果

「連續幾天沒藍屏」不算修好,那可能只是還沒踩到。建議依序確認三件事:

1. 在 Driver Verifier 仍開啟的狀態下,把原本會觸發的操作重跑一遍。 這才是真正的壓力測試:如果違規還在,檢查員會立刻停機;什麼事都沒發生,才有意義。復現操作請比照當初的當機情境(大量檔案複製、掛載、備份、掃描)。
2. 查一次目前設定,確認你以為開著的東西真的開著。 官方提供兩個查詢指令:verifier /querysettings 顯示下次開機後會啟用的選項與受驗驅動(不含 /volatile 加入的項目),verifier /query 則顯示 Driver Verifier 目前的活動狀態。

verifier /querysettings

1. 確認沒有新的傾印檔產生。 觀察期間到事件檢視器看「系統」記錄,確認沒有新的 BugCheck 事件;若還有,把新傾印再跑一次方法一,比對 device stack 是不是同一串。

三項都過,才把 Driver Verifier 關掉(見下一節),再觀察一至兩週。

🔙 萬一翻車:回退步驟

Driver Verifier 最經典的翻車情境,是開啟後系統開不了機——因為違規在開機階段就被抓到,於是每次開機都藍屏。事前與事後各有一套處置:

事前預防(強烈建議在啟用前就先設定)。 官方提供 /bootmode 參數控制設定是否在重開機後仍然生效,其中 resetonbootfail 的官方說明是:若系統啟動失敗,則在後續重開機時停用 Driver Verifier。

verifier /bootmode resetonbootfail

官方同時註明:要設定或變更 /bootmode 選項,必須重新開機。另外 oneboot 只讓設定在下次開機時生效、之後自動停用,也是保守的選擇;預設值則是 persistent(跨多次重開機持續生效)。

事後救援(已經開不了機時)。 站長的實務作法是進入安全模式或 Windows 修復環境(WinRE)的命令提示字元(這條進入路徑是實務作法,官方該頁只寫指令、沒有寫在哪個環境執行),執行官方的清除指令:

verifier /reset

官方對 /reset 的說明是:清除所有 Driver Verifier 設定;下次開機後不會驗證任何驅動。 執行後重新開機即可回到原本狀態。

還原點與備份。 如果連安全模式都進不去,就使用啟用前建立的系統還原點,或以修復 USB 開機後還原。這也是本文一開始要求先做備份與還原點的原因——這一步不是形式,是這類操作真正的退路。

⚠️ 誠實的邊界:回退只能還原「你開了 Driver Verifier」這件事,不會修好那支有臭蟲的驅動。回退之後藍屏若又變回 0x44,代表根因仍在,要回到方法一重新縮小名單。

💡 總結:預防再次發生

站長我處理這類 I/O 相關藍屏,最大的心得是一句話:0x44 這種碼,不要相信 !analyze -v 指給你的名字。

多數停止碼的排錯邏輯是「看堆疊、找模組、更新驅動」,而 0x44 的官方描述已經先把這條路封死了——第一支驅動的痕跡被第二支蓋掉,你在現場看到的是發現者,不是兇手。我看過太多人在這顆碼上反覆更新同一支被誤指的驅動、甚至重灌兩三次,問題原封不動,因為根本沒動到真正雙重完成封包的那一支。真正有效的動作只有兩個:把 IRP 攤開來看它經過誰,以及讓 Driver Verifier 在違規當下就停機。

至於預防,主動能做的其實不多,但都很有效:

• 同類型的過濾式軟體不要疊。 兩套防毒、防毒加磁碟加密加備份快照全部掛在同一條檔案系統堆疊上,就是雙重完成最肥沃的土壤。同一功能只留一套。
• 驅動更新看來源,不看數字。 用裝置廠商官方頁面或 Windows Update,不要用來路不明的「驅動更新工具」——那類工具最愛裝上與你硬體不完全相符的版本。
• 平常就把核心記憶體傾印設定好。 0x44 是機率型當機,錯過一次現場,下次可能要等好幾天。傾印設定只要花一分鐘,卻決定了你有沒有東西可以查。
• 裝完新的系統層軟體,記一下日期。 排錯時「最近裝了什麼」往往比任何工具都準。

❓ 常見問題

Q:MULTIPLE_IRP_COMPLETE_REQUESTS 0x44 是記憶體壞掉嗎?要不要先換 RAM?

依官方定義,0x44 的成因是「驅動呼叫 IoCompleteRequest 要求完成一個已經完成的封包」,屬於軟體層的所有權錯誤,不是記憶體故障的專屬徵兆。跑記憶體測試當然無害,但把它當第一順位通常是浪費時間;先讀傾印、看 device stack 才是正路。

Q:一定要用 Driver Verifier 嗎?有沒有比較溫和的做法?

有。方法一整段都不需要 Driver Verifier——只讀傾印、攤開 IRP、看 device stack 裡有哪些第三方驅動,再逐一更新或移除。只有在名單收斂不了、或移除後仍藍屏時,才需要動用 Driver Verifier。

Q:0x44 跟 0x35 到底差在哪?兩個看起來都跟 IRP 有關。

差在錯的環節不同。0x44 是同一個封包被完成兩次(所有權錯亂);0x35 是上層驅動呼叫下層時,封包裡已經沒有剩餘的 stack location 可用,官方形容為災難性狀況,因為上層等於寫到了封包之外、連帶破壞其他記憶體。0xC5 則是另一回事——它是驅動寫壞系統集區後,在 IRQL 過高時存取到無效記憶體。

Q:開了 Driver Verifier 之後藍屏變得更頻繁,是不是弄壞了?

不是,這是預期行為。Driver Verifier 的作用就是把原本要拖到很後面才爆的違規,提前到發生當下攔截。頻率上升代表它正在工作;此時的藍屏代碼(0xC9 / 0xC4)反而會給你更明確的違規資訊。真的受不了時,依回退步驟執行 verifier /reset 即可。

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

先確認新傾印的 Arg1 攤開後,device stack 是不是同一串。同一串代表兇手沒抓對或廠商修正版沒解決,回到方法二換下一個嫌疑犯驗證;不同串代表這是另一支驅動的獨立問題,得重跑整套流程。另外也要確認 Driver Verifier 是否在某次更新後被重設——用 verifier /querysettings 查一次最快。

🔗 延伸閱讀

• DRIVER_VERIFIER_DETECTED_VIOLATION(0xC4)藍屏怎麼修?讀懂 Parameter 1 揪出違規驅動
• DRIVER_CORRUPTED_EXPOOL 0xC5 藍屏怎麼修?用 Special Pool 抓寫壞集區的驅動
• DRIVER_IRQL_NOT_LESS_OR_EQUAL(0xD1)藍屏怎麼修
• BAD_POOL_CALLER 0xC2 藍屏怎麼修?讀懂 Parameter 1 揪出兇手驅動

📎 參考資料來源

📖 第一級|廠商官方:

• Bug Check 0x44: MULTIPLE_IRP_COMPLETE_REQUESTS(Microsoft Learn) — 2026-08-12 查證
• Completing IRPs(Microsoft Learn) — 2026-08-12 查證
• I/O Verification(Microsoft Learn) — 2026-08-12 查證
• IRP Logging(Microsoft Learn) — 2026-08-12 查證
• Driver Verifier Command Syntax(Microsoft Learn) — 2026-08-12 查證
• Using Volatile Settings(Microsoft Learn) — 2026-08-12 查證
• Kernel Memory Dump(Microsoft Learn) — 2026-08-12 查證
• Small Memory Dump(Microsoft Learn) — 2026-08-12 查證
• !irp extension command(Microsoft Learn) — 2026-08-12 查證
• Bug Check 0x35: NO_MORE_IRP_STACK_LOCATIONS(Microsoft Learn) — 2026-08-12 查證
• Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL(Microsoft Learn) — 2026-08-12 查證

⚠️ 本文核心事實以第一級為準;文中所有停止碼定義、參數意義、Driver Verifier 旗標值與指令語法,均取自上列 Microsoft 官方文件。

📅 本文查證戳記:2026-08-12 依 Microsoft 官方文件現行版本撰寫。

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