UNMOUNTABLE_BOOT_VOLUME(0xED)開機卡死?先讀 Parameter 2 再決定救法

⚡ 站長快讀:核心重點

• 文章屬性:疑難排除(底層除錯)
• 適用系統:Windows 11 / Windows 10
• 難易度 / 耗時:中高 / 20 分鐘起,chkdsk /r 視碟況可能數小時
• 核心結論:UNMOUNTABLE_BOOT_VOLUME 是掛載開機磁碟區失敗,決定救法的是 Parameter 2(內附官方讀取路徑)。
• 適用對象:開機就跳這個停止碼、不想直接重灌的人

📌 快速答案

一句話答案:UNMOUNTABLE_BOOT_VOLUME(0xED)是 Windows 掛載開機磁碟區失敗,先讓自動修復跑一次,再進 WinRE 用 chkdsk /r 修檔案系統,無效才重建開機記錄或換碟。

🧰 開始前的準備

• 適用系統:Windows 11、Windows 10;WinRE 疑難排解流程亦適用支援中的 Windows Server 版本
• 權限需求:系統管理員(WinRE 命令提示字元本身即為高權限環境)
• 需要工具:可開機的 Windows 安裝媒體或修復隨身碟、BitLocker 復原金鑰(48 位數字)、另一台可上網的電腦
• 預計耗時:約 20 分鐘起;chkdsk /r 在大容量傳統硬碟上可能要數小時

⚠️ 先確認你手上有 BitLocker 復原金鑰再往下做。 依 Microsoft 官方說明,如果自動修復無法自行啟動、你改用修復磁碟手動開 WinRE,就必須提供 BitLocker 復原金鑰才能解鎖磁碟。現在的 Windows 11 消費機多半預設開了裝置加密,金鑰通常綁在你的 Microsoft 帳戶;公司機則可能在 Entra ID 或 AD。沒有金鑰就動手,你會卡在復原畫面進退不得。

🔍 症狀描述與錯誤訊息

直接結論:這個錯誤發生在開機的最後一哩路——核心已經起來了,但它掛不上要拿來跑 Windows 的那顆磁碟區。

典型情境是這樣:電腦按下電源後,廠商 logo 正常出現,Windows 轉圈也可能跑了兩三秒,然後畫面一切,跳出停止碼:

Your PC ran into a problem and needs to restart.

Stop code: UNMOUNTABLE_BOOT_VOLUME

重開機之後同樣的畫面再來一次,形成迴圈。有些機器會在幾次失敗後自動進入「自動修復」或「選擇選項」畫面。它的 bugcheck 值是 0x000000ED,官方定義寫得非常直接:I/O 子系統嘗試掛載開機磁碟區,而它失敗了。

值得注意的是,這個停止碼幾乎不會在你正常使用到一半時跳出來——它的發生位置就在開機序列裡。如果你的藍色/黑色當機畫面是在使用中隨機跳的,那你要找的多半不是這一篇,而是另一類 bugcheck。

與它相鄰、最容易搞混的是 INACCESSIBLE_BOOT_DEVICE(0x7B)。兩者都是「開機開不起來」,重心也確實不同——0xED 的官方定義聚焦在「掛載這個動作失敗」,0x7B 的成因則更常指向儲存驅動程式、控制器模式與硬體那一層。但請不要把它當成乾淨的二分法:這兩個停止碼的成因有實際重疊,官方對 0x7B 的說明裡也涵蓋了部分檔案系統無法辨識開機裝置資料的情境。實務上的原則很簡單:以你螢幕上真正跳出來的那個停止碼為準,不要用「我覺得應該是哪一類」去反推。如果你拿到的是 0x7B,請走 INACCESSIBLE_BOOT_DEVICE(0x7B)的排查流程。

🔎 問題根因

直接結論:0xED 只是「掛載失敗」這個結果,真正的原因藏在 Parameter 2。

常見的教學看到 0xED 就直接叫你跑 chkdsk,這在不少案例會有效,但它跳過了一個關鍵問題:為什麼掛不上? Windows 其實有把答案交出來,就在四個參數裡。依 Microsoft Learn 官方的參數表:

重點摘要:

• 只有 Parameter 2 帶有診斷價值,它是檔案系統回報上來的 NTSTATUS 碼。
• Parameter 1 對一般使用者意義有限(要配合除錯器才看得出是哪顆裝置)。
• Parameter 3、4 官方標明保留,網路上任何「第三參數代表某某」的說法都沒有官方依據。

那 Parameter 2 常見的兩個值分別代表什麼?查 Microsoft 官方的 NTSTATUS 規格文件可以對到:

這個區分是本文最重要的一段:同樣是 0xED,0xC0000032 你跑 chkdsk 修好的機率不低;但如果是 0xC000009C,那代表碟片上已經有讀不出來的實體壞軌——這時候一直反覆跑 chkdsk /r,不但未必修得好,還會讓一顆本來就在衰退的碟持續高負載讀取,把「還能救資料」的窗口愈關愈小。碟已經在報壞軌,正確動作是先想辦法把資料鏡像出來,而不是繼續修。

那你這台的 Parameter 2 要去哪裡讀?

直接結論:停止碼畫面本身不會列出四個參數,你得從當機傾印檔或事件記錄回頭撈。以下三條路,由易到難。

先講一個很多文章不願意講的實話:現在的停止畫面預設只給你一行 Stop code,不會把 Parameter 1~4 印在螢幕上(這是官方的預設行為;雖然官方另有登錄值可讓停止畫面顯示參數,但那要在當機前就先設好,對已經開不了機的你沒有幫助)。所以「先看 Parameter 2」不是叫你盯著螢幕看,而是要你去把它撈出來。

路徑一:從事件記錄查(能進系統時最快)

如果你的機器還能偶爾開進桌面(例如 0xED 只是間歇發生),官方疑難排解流程的第一步就是:在事件記錄裡查看你拿到的停止碼。事件檢視器(eventvwr.msc)→「Windows 記錄」→「系統」,找當機時間點附近由 BugCheck 記下的那筆——官方文件明講,該 bug check 的事件屬性會列出四個停止碼參數,Parameter 2 就在裡面。

路徑二:從當機傾印檔用 WinDbg 讀(最準,但要另一台電腦)

這是官方文件寫得最完整的一條。傾印檔的預設位置依類型而定:

因為你的機器開不了機,官方的做法是:把當機那台電腦 Windows 目錄裡的 memory.dmp 複製到另一台電腦(你可以在 WinRE 的命令提示字元裡複製到隨身碟),然後在另一台電腦上:

1. 下載 Windows SDK,安裝時勾選 Debugging Tools for Windows(WinDbg 就在裡面)。

2. 開 WinDbg,File →「Symbol File Path」設為官方公用符號伺服器:https://msdl.microsoft.com/download/symbols

3. Open Crash Dump,開啟你複製出來的 memory.dmp。

4. 在「Bugcheck Analysis」底下執行 !analyze -v(官方 0xED 頁面點名的就是這個命令)。

輸出裡的 Arguments 段(Arg1 / Arg2 / Arg3 / Arg4)、或摘要區的 BUGCHECK_P1~BUGCHECK_P4,就是你要的四個參數——Arg2 / BUGCHECK_P2 那個值,就是本文一直在講的 Parameter 2。 拿它回頭對前面那張 status code 表。

路徑三:讀不到,怎麼辦?

說實話,不是每個人都撈得到:傾印檔可能根本沒產生(碟壞到寫不進去)、或是你手邊沒有第二台電腦可以裝 WinDbg。這種情況請直接承認讀不到,照下面的通用順序做,但把 chkdsk 的回報當成替代訊號:如果 chkdsk /r 過程中大量回報壞軌、或在有下 /r 的前提下結束代碼回 3(無法檢查/錯誤無法修復),那它給你的資訊其實跟 0xC000009C 指向同一個方向——往硬體層想,先保資料。

📌 所以本文的判讀順序是:撈得到 Parameter 2 → 依上表分流(0xC0000032 走檔案系統修復、0xC000009C 走備份與換碟);撈不到 → 照方法一到方法三的順序做,但在任何一步看到壞軌或結束代碼 3 就停手改走備份路線。

那個「非 0xC0000032 就是 UDMA 控制器問題」的說法可信嗎?

你在網路上很容易搜到這句:「Parameter 2 若為 0xC0000032 表示檔案系統毀損,若不是,則是 UDMA 硬碟控制器的問題。」

這個二分法出自 Windows XP 時代的舊知識庫敘述,現行 Microsoft Learn 的 0xED 官方頁面裡並不存在。 官方現在對 Parameter 2 的定義就是一句話:檔案系統回傳、描述掛載失敗原因的 status code——沒有任何「不是 0xC0000032 就等於 UDMA」的分流。而且 UDMA 是並列式 ATA 時代的傳輸模式,對今天 NVMe / SATA AHCI 的機器來說,拿它當現行判準並不合適。

站長的建議是:把 Parameter 2 當成一個要去查表的 NTSTATUS 碼,而不是套一個二十年前的二分法。 查到什麼碼,就照那個碼的官方語意走。

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

直接結論:0xED 是 I/O 管理員在「掛載」這個動作上收到檔案系統的失敗回覆,而且失敗的偏偏是開機卷,核心無路可退,只能停下來。

把開機流程拆開來看,大致是這樣的順序:

1. UEFI 韌體交棒給 Windows Boot Manager,Boot Manager 依 BCD(開機設定資料)找到要載入的 OS 項目。

2. Winload 把核心與必要的開機起始(boot-start)驅動程式載入記憶體。

3. 核心初始化,儲存驅動程式接手,裝置被列舉出來。

4. I/O 子系統要求檔案系統驅動程式(NTFS)去掛載那個開機磁碟區——也就是把磁區上的檔案系統結構解析成一個可用的卷。

5. 掛載成功,系統才拿得到 \Windows,才能繼續起服務、進登入畫面。

0xED 卡在第 4 步。這也是它跟 0x7B 在重心上的差別:0x7B 的成因更常落在第 3 步那一帶(儲存驅動程式、控制器模式、裝置存取),而 0xED 的官方定義直接指名第 4 步的掛載動作失敗。話說回來,前面提過,這兩者成因有重疊,別拿這個分層當成鐵律去反推自己是哪一種——分層是用來理解機制的,判斷還是看你實際拿到的停止碼與 Parameter 2。

而 NTFS 為什麼會掛不上?常見的是這幾類:$MFT 或開機磁區這類關鍵中繼資料損壞、日誌($LogFile)狀態不一致到無法重放、分割表被改動、或者最物理的一種——要讀取這些結構的磁區讀不出資料。這也是為什麼官方在同一頁把話講得很白:這個 bugcheck 通常與開機儲存裝置本身的故障有關;如果修復步驟都無效,那有可能硬碟已經壞了。

順帶一提,如果你的碟是 NVMe SSD,而在藍屏之前系統事件裡就已經零星出現儲存控制器層的警告,那「硬體在衰退」的權重要往上調——這類徵兆可以參考 stornvme Event 129 的排查思路。至於掛載成功之後才在使用中爆出來的 NTFS 檔案系統錯誤,則屬於 NTFS_FILE_SYSTEM(0x24) 的範圍,兩者根因常常重疊,但發生的時機不同。

🛠️ 解決方案

⚠️ 高風險操作警語(務必讀完再動手)

– 以下步驟涉及檔案系統修復與開機記錄重建,存在資料遺失的可能。chkdsk /f / /r 在修復過程中可能改動檔案系統結構;重建開機記錄會改寫開機設定。

– 開始前請確認電源穩定(筆電請接上變壓器),修復過程中斷電風險最高。

– 手上要有 BitLocker 復原金鑰。

– 如果碟裡有你賠不起的資料,而症狀又指向壞軌(Parameter 2 = 0xC000009C),請先停手,把碟接到另一台機器做映像備份或送資料救援,再談修復。

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

– 不確定自己的 Windows 版本或機器型號

– 尚未完成備份,而碟內資料無可取代

– BitLocker/裝置加密已啟用,但你沒有復原金鑰

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

– 沒有可開機的救援 USB

– 指令輸出與本文描述不符(例如找不到磁碟區、代號對不上)

方法一:先讓 Windows 自己修一次(Startup Repair)

直接結論:官方建議的第一步就是啟動修復,而且它多半會自己找上你,不需要你去凹它。

依 Microsoft 官方 BitLocker 文件的說明,裝置在連續兩次開機失敗之後,啟動修復(Startup Repair)會自動啟動。所以如果你已經連撞了兩次 0xED,第三次開機時大概率會直接進入「自動修復 / 選擇選項」畫面。

網路上盛傳的做法是「開機到一半按住電源鍵強制關機,重複三次逼出自動修復」。這招的原理就是製造開機失敗次數,但它不是官方文件裡的步驟,而且每一次強制斷電都是對一顆可能已經在生病的碟再補一刀。你的機器既然已經在跳 0xED,失敗次數本來就在累積,通常不需要自己再去斷電湊數。

進到 WinRE 後:

1. 選擇「疑難排解」→「進階選項」→「啟動修復」。

2. 讓它跑完,不要中途重開。

3. 跑完後嘗試正常開機。

另外要有心理準備:官方也說明了,自動觸發的啟動修復,只在開機記錄或當機傾印指向某個特定損毀檔案時,才會執行作業系統與驅動程式檔案的修復。 換句話說,它擅長的是「某個檔案壞了」這種情境;如果你的問題是檔案系統結構整個不一致,它跑完跟你說修不好,是很正常的,直接進方法二。

方法二:在 WinRE 手動跑 chkdsk(先確認磁碟機代號)

直接結論:這是 0xED 最值得先試的一招,但不少教學會略過最關鍵的前置動作——在 WinRE 裡,你的系統碟通常不是 C:。

進入「疑難排解」→「進階選項」→「命令提示字元」後,先不要急著打 chkdsk C: /r。WinRE 是一個獨立載入的環境,它有自己的磁碟機代號指派;在 WinRE 底下,C: 很可能是系統保留磁碟區或修復磁碟區,而你真正的 Windows 卷可能被指到 D:。對錯的卷跑 chkdsk /r,結果就是你在那邊等了三個小時,修的卻是一個幾百 MB 的分割區,問題原封不動。

官方的 WinRE 疑難排解流程明確要求先做這一步:

BCDEdit

在輸出的 Windows Boot Loader 段落裡,找到 osdevice 這一行,它後面顯示的磁碟機代號才是你的系統磁碟區(官方文件裡舉的例子就是 D:)。

確認代號之後,再對那個代號跑檔案系統修復。以官方範例的 D: 為例:

chkdsk /f D:

官方 0xED 頁面則建議使用 /r,它涵蓋 /f 的功能,並且額外分析實體磁碟錯誤:

chkdsk /r D:

兩者怎麼選? 依官方 chkdsk 文件:

• /f = 修復磁碟上的錯誤(邏輯層),磁碟必須能被鎖定。
• /r = 定位壞軌並救回可讀取的資訊,包含 /f 的功能,外加實體磁碟錯誤分析。
• 不加參數 = 只顯示狀態、不修任何東西。

如果你懷疑是實體問題(或 Parameter 2 是 0xC000009C),/r 才看得到壞軌;如果只是想快速處理邏輯結構、時間又緊,/f 快得多。要有心理準備的是,官方明講:大容量傳統硬碟跑 /r 或 /b 會花上相當長的時間,因為它要讀過每一個磁區。

跑的過程中請不要手癢中斷。不過萬一真的斷了,官方的說法可以讓你稍微安心:不建議中斷 chkdsk,但取消或中斷它,不應該讓磁碟區變得比執行前更糟;再跑一次 chkdsk 會檢查並修復剩下的損壞。

方法三:重建開機記錄(最後手段)

直接結論:如果 chkdsk 修完檔案系統仍然開不起來,官方的下一步是用 bootrec 修復主開機記錄與開機記錄。

Microsoft Learn 的 0xED 頁面把處置寫成三步,第三步就是:使用 bootrec 命令修復 master 與 boot records。這一步改動的是開機設定層,風險高於前兩步,請務必確認前面的停止條件都已排除。

在 WinRE 命令提示字元中,依序執行(一行一個指令,逐行確認輸出):

bootrec /scanos

bootrec /rebuildbcd

這裡要誠實說明來源分際:官方 0xED 頁面只寫到「使用 bootrec 命令修復 master 與 boot records」這一句,並沒有指定要用哪些子命令,也沒有給對應的判讀規則。以下 /scanos 先行的做法與判讀,屬於站長的經驗性建議,非官方步驟,請自行斟酌:先用 /scanos 掃描系統上的 Windows 安裝,如果它連一個安裝都掃不到,依站長的經驗這通常不是 BCD 的問題,而是該回頭看檔案系統或硬體層——這時候硬去 /rebuildbcd 意義不大,建議回頭看方法二的結果與 Parameter 2。

🔐 BitLocker 提醒:官方文件明列,對磁碟上 NTFS 分割表的變更與對開機管理員的變更都會觸發 BitLocker 復原模式。也就是說,這一步做完之後,下次開機被要求輸入 48 位數的復原密碼是預期中的行為,不是你又搞壞了什麼——前提是你手上真的有那組金鑰。

如果三個方法都無效,請正視官方那句話:「如果這些步驟都不成功,有可能是硬碟已經故障了。」 部分硬碟廠商提供診斷工具可協助確認硬體故障。與其繼續在一顆壞碟上重灌,不如先把資料救出來。

✅ 驗證修復結果

直接結論:「開得起來」不等於「修好了」,要看 chkdsk 自己回報的結果。

很多人跑完 chkdsk、電腦開起來就當作結案,結果過幾天又跳一次。要確認修復到底發生了什麼,有兩個層次:

第一層:看 chkdsk 的結束代碼。 官方文件列出四個:

第二層:回到 Windows 之後查 chkdsk 記錄。 官方提供的做法是開事件檢視器(eventvwr.msc)→ 展開「Windows 記錄」→ 對「應用程式」按右鍵 →「篩選目前的記錄」→ 在「事件來源」下拉選單裡勾選 Chkdsk 與 Wininit 兩個來源。這裡會留下完整的掃描報告,包含它到底修了什麼。

另外一個容易被忽略的訊號:如果你的碟很大,而 chkdsk /r 快得不合理地就跑完了,那不一定是好消息。 官方明白列出幾個可能:磁碟區被 OS 或其他程序鎖住、chkdsk 實際上沒有掃過每一個磁區、硬碟可能有讀取頭故障之類的硬體問題導致 chkdsk 行為異常,或者它只做了線上掃描而沒有真的離線掃。碰到這種情況,不要慶祝,要懷疑。

🔙 萬一翻車:回退步驟

情境一:chkdsk 跑完,系統仍然跳 0xED

代表檔案系統層修不動這個問題。不要一直重跑 /r——尤其在懷疑壞軌時,反覆全碟讀取只是消耗碟的殘命。回到 Parameter 2 的判讀:若是 0xC000009C(壞軌),優先把碟接到另一台機器做映像備份。

情境二:做完 bootrec 之後被要求輸入 BitLocker 復原密碼

如前所述,這是官方文件裡的預期行為(開機管理員/分割表變更會觸發復原)。輸入你的 48 位數復原密碼即可。金鑰位置:個人裝置多半在 Microsoft 帳戶(用另一台裝置登入帳戶的裝置頁面查),公司/學校裝置在 Entra ID、AD DS 或由 IT 保管。

情境三:BCDEdit 找不到 osdevice,或磁碟區代號完全對不上

停手。這代表系統連開機設定都讀不出來,已經超出「照步驟修」的範圍,硬體故障的機率顯著上升。此時最該做的是保住資料,而不是繼續試指令。

情境四:最壞情況——碟已經認不到

如果 WinRE 裡連磁碟都列舉不出來,那已經不是 0xED 的討論範圍了(那會走向 0x7B 那條線),請把重點放在資料救援與硬體更換。

💡 總結:預防再次發生

直接結論:0xED 很少是憑空發生的,它通常是碟在衰退或檔案系統長期被粗暴對待的結算日。

站長我處理這類開機不能的案子,習慣先問一句:「在跳這個畫面之前,有沒有發生過非正常關機?」——強制斷電、電池直接耗盡、當機時長按電源鍵,這些動作對 NTFS 的中繼資料一致性都是壓力測試。單次通常沒事,累積起來就會在某天早上變成一個掛不上的卷。這也是為什麼我對「按住電源鍵斷電三次逼出自動修復」這個網路偏方一直有意見:它把一個本來就在生病的碟,再多凌遲三次。

幾個實際有用的預防動作:

1. 正視早期訊號。 事件檢視器裡儲存控制器層的零星警告、開機偶爾變慢、檔案總管偶爾卡住——這些是碟在跟你講話。等到跳 0xED 才處理,選項會少很多。

2. 不要用強制斷電當作關機方式。 系統卡住時,先給它時間;真的要斷,也要知道你在拿檔案系統一致性換時間。

3. 備份策略要能對付「開不了機」這個情境。 很多人的備份放在同一顆碟的另一個分割區——0xED 打的就是整顆碟,分割區救不了你。

4. BitLocker 復原金鑰,現在就去確認你查得到。 這是所有預防動作裡成本最低、關鍵時刻價值最高的一個。等到卡在復原畫面才發現金鑰沒備份,前面所有排錯技巧都用不上。

最後一句實話:0xED 的官方處置流程只有三步,但判斷「該不該修」比「怎麼修」更重要。Parameter 2 就是那個判斷點——它告訴你這是一場檔案系統的手術,還是一顆碟的臨終通知。

❓ 常見問題

Q:UNMOUNTABLE_BOOT_VOLUME 一定是硬碟壞了嗎?

不一定,但官方確實把它歸類為「通常與開機儲存裝置的故障有關」。檔案系統結構毀損(0xC0000032)這種情況,chkdsk 修好的機會不低,碟本身還能用;但如果 Parameter 2 指向壞軌(0xC000009C),那硬體因素的權重就很高了。先看 Parameter 2 再下結論。

Q:我進不了桌面,要怎麼看到 Parameter 2?

停止畫面不會印出四個參數,要從當機傾印檔撈。官方做法是把當機那台電腦 Windows 目錄下的 memory.dmp(或 %SystemRoot%\Minidump 裡的小型傾印)複製到另一台電腦,裝 Windows SDK 裡的 Debugging Tools for Windows(WinDbg),設好官方符號伺服器後開啟傾印檔,執行 !analyze -v,看輸出的 Arg2 / BUGCHECK_P2。若機器還能偶爾開進系統,也可以在事件檢視器的系統記錄裡找 BugCheck 那筆。真的撈不到就照通用順序做,並把 chkdsk 是否回報壞軌當替代訊號。

Q:chkdsk 跑了六個小時還沒完,可以中斷嗎?

官方立場是「不建議中斷」,但也說明取消或中斷 chkdsk,不應該讓磁碟區變得比執行前更糟,再跑一次會檢查並修復剩餘的損壞。另外,官方也提醒大容量傳統硬碟跑 /r 本來就要讀過每一個磁區,慢是正常的。真的要中斷,請確保電源穩定的情況下操作,不要靠拔電源。

Q:我可以直接跳過 chkdsk 去 bootrec 嗎?

不建議。官方的順序是啟動修復 → CHKDSK /r → bootrec,這個順序是有道理的:bootrec 動的是開機設定層,風險更高,而且如果根因是檔案系統結構壞掉,重建 BCD 也救不回來。照順序做,失敗的資訊本身就是診斷線索。

Q:為什麼要先跑 BCDEdit?直接 chkdsk C: 不行嗎?

因為在 WinRE 裡,C: 常常不是你的 Windows 磁碟區。官方流程明確要求先用 BCDEdit 從 Windows Boot Loader 段的 osdevice 取得系統磁碟區代號,官方範例給的就是 D:。跳過這步,你很可能花好幾個小時修錯了卷。

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

復發是強烈訊號,代表根因沒被解決,硬體衰退的可能性要往上調。這時候的優先順序是:先完整備份 → 再用硬碟廠商提供的診斷工具確認硬體狀態 → 確認是碟的問題就換碟,而不是再修一次檔案系統。官方也直言,如果這些步驟都不成功,有可能硬碟已經故障。

📎 參考資料來源

📖 第一級|廠商官方:

• Bug Check 0xED: UNMOUNTABLE_BOOT_VOLUME — Microsoft Learn — 2026-07-15 查證
• [[MS-ERREF]: NTSTATUS Values — Microsoft Learn](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55) — 2026-07-15 查證
• Use WinRE to troubleshoot common startup issues(KB 4026030)— Microsoft Learn — 2026-07-15 查證
• chkdsk 命令參考 — Microsoft Learn — 2026-07-15 查證
• BitLocker recovery overview — Microsoft Learn — 2026-07-15 查證
• Advanced troubleshooting for stop code errors — Microsoft Learn — 2026-07-15 查證
• Blue Screen Data(事件記錄中的 bug check 參數)— Microsoft Learn — 2026-07-15 查證

⚠️ 本文核心事實以第一級為準,第二級為補充。本文為官方文件與規格交叉查證之整理(證據等級 E3),非第一手實測。

📅 本文查證戳記:2026-07-15 依據 Microsoft Learn 現行官方文件撰寫。

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