老森常譚 IT Help

Windows 更新遇到 0x80070306 錯誤

　　最近在處理一台香港的 Windows Server 2025，原本只是 Windows Update 安裝 KB5120233 失敗，沒想到最後連續研究了三天，從 DISM 元件存放區、Language Pack、PSFX hydration，一路追到 CBS / CSI，最後才靠 In-place Repair Upgrade（就地修復升級） 解決。

　　這次過程主要搭配 ChatGPT 與 Claude Code 協助分析 CBS Log 及建立離線測試環境，中間做了不少假設，也推翻了好幾個原本看起來很合理的方向，因此把比較重要的過程記錄下來，希望能幫到遇到類似問題的人。

【系統環境】

Windows Server 2025 Standard Desktop Experience
原始版本：26100.2033 / 24H2
Servicing Stack：26100.33288
失敗更新：KB5120233
Windows Update 原始錯誤：0x80070306（Error 774）
目標版本：26100.33296
系統語言：en-US，另有 zh-TW 語言元件
實體伺服器，主要服務為 SQL Server、IIS、WMS
透過 WSUS 更新

　　這台伺服器放在香港，當地沒有 IT 人員，所以也沒辦法很豪邁地直接重裝，呵。

【最初的錯誤】

Windows Update 安裝 KB5120233 時持續出現：

0x80070306

一開始先檢查 Windows Component Store：

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

結果確實發現元件存放區損壞，RestoreHealth 又出現：

0x800f0915
CBS_E_REPAIR_CONTENT_MISSING

從 CBS Log 往下追，找到幾個舊版元件 payload 缺失，包含 zh-TW Boot Manager MUI、fsutil.exe.mui、kernel32.dll.mui 等。後來另外建立一份含歷史更新版本的 WIM，作為 Repair Source：

DISM /Online /Cleanup-Image /RestoreHealth /Source:"&lt;Mount&gt;\Windows" /LimitAccess

這次終於修復成功，ScanHealth 也變成 Healthy。Microsoft 官方也有說明，可透過 /Source 指定良好的 Windows 映像作為 RestoreHealth 的修復來源。

原本以為事情到這裡就結束了，結果重新安裝 KB5120233，還是 0x80070306。

【繼續追 CBS / PSFX】

CBS Log 顯示更新在處理幾個 zh-TW 元件時失敗：

Microsoft-Windows-MTF-CHT-Extra
ChtAdvancedDS.dll

Microsoft-Windows-Spelling-Dictionaries-Chinese-Latin-Main
datamap.0404.dat
ExpressiveInput.0404.lex

錯誤集中在：

Forward Delta
DeltaDecompressBuffer
Error 774
0x80070306

因此一開始懷疑 zh-TW Language Basic 元件有問題，也建立了多份離線 WIM 做 A/B 測試。後來甚至逐一比對 WinSxS payload SHA256、Manifest、MUM/CAT、COMPONENTS Hive、DerivedData、CanonicalData、TrustedInstaller、Servicing Stack 與 Hardlink。

但很有趣的是：LIVE 主機會失敗，幾乎所有離線映像都可以成功更新，而且靜態內容比對幾乎全部一致。

這時已經可以確定，問題不是單純某一個 DLL 壞掉。

【Language Pack 與 LCU 的安裝順序】

調查過程中另外注意到 Microsoft 對 Language Pack 的 servicing 順序有明確建議：先安裝語言，再安裝更新與應用程式。如果是在已經整合 SSU / LCU 的 Windows 映像上才加入 Language Pack，Microsoft 建議重新套用相關更新；尤其安裝 Language Pack 後，要重新安裝最新 LCU，否則可能發生錯誤，而且如果該 LCU 原本已經安裝過，Windows Update 不一定會再次提供，需要手動重新安裝。

這裡所說的是新增／安裝 Language Pack，不是單純在 Windows 介面切換顯示語言。這項官方建議也是我們一度懷疑更新順序與語言元件修訂鏈的原因之一。

【幾個被推翻的假設】

Parallel hydration failed 就是根因
後來在一次完整成功的離線更新裡，也看到大量 Hydration failed，因此這比較像 CBS 的預先最佳化流程失敗，並不一定致命。
只是 zh-TW Language Pack 壞掉
移除 Language Basic / OCR / Speech / TextToSpeech 後，原本的 hydration error 確實消失，但 KB5120233 接著改成：
```
0x800736B3
STATUS_SXS_ASSEMBLY_NOT_FOUND
CCSDirectTransaction::MarkTlcUnstaged
```
而且失敗元件先後出現在 IIS 的 en-US LanguagePack 與其他 zh-TW LanguagePack，因此無法再解釋成單一繁中套件問題。
SFC / DISM 顯示 Healthy 就代表 CBS 完全正常
這次實際證明並非如此。SFC、ScanHealth、RestoreHealth、StartComponentCleanup 後期都無法處理這個問題。

最後能確認的是：這台伺服器的 Component Store 裡，部分 *-Deployment-LanguagePack 的 CSI / TLC 記帳狀態存在不一致；但這已經超出一般 DISM 健康檢查能修復的範圍。

【也試過往前裝、往回拆 LCU】

為了確認是不是只有最新的 KB5120233 有問題，我們後來也直接在 LIVE 環境測試較舊、且仍被系統判定 Applicable 的 KB5046617（26100.2314）：

DISM /Online /Add-Package /PackagePath:"KB5046617.msu" /NoRestart

ExitCode = 14003
0x800736B3
STATUS_SXS_ASSEMBLY_NOT_FOUND

KB5046617 比 KB5120233 早了一年以上，仍然在相同類型的 CSI / TLC 流程失敗，因此可以排除「只是最新 LCU 本身帶進壞元件」的假設。

反方向也做過測試：系統 Store 裡還殘留一個舊的 KB5043080 / RollupFix 26100.1742，狀態為 Staged，於是嘗試將它移除：

DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10 /NoRestart

Error 14003
0x800736B3
STATUS_SXS_ASSEMBLY_NOT_FOUND

結果連「安裝較舊 LCU」與「移除既有舊 LCU」都會失敗，而且都碰到相同家族的 CSI 錯誤。這個驗證很重要，因為它表示問題已經不是單一 KB，而是本機 Component Store 的 servicing 記帳狀態。

【最後解決方法：In-place Repair Upgrade】

研究到這裡後，繼續逐一修 CBS 已經有點像打地鼠，因此最後決定改用 Windows Server 的 就地修復升級。

Microsoft 官方文件說明，In-place Upgrade 可以從 Windows Server 安裝媒體執行 setup.exe，並保留檔案、設定、應用程式與 Server Roles。這次不是直接使用原始 26100.2033 媒體，而是另外建立：

WS2025-LangRepair

其中 install.wim 使用先前建立的 LangTest.wim，已整合：

Windows Server 2025 Standard Desktop Experience
zh-TW Language Pack / Basic
KB5044284
KB5120233
Build 26100.33296

目的就是讓 Repair Upgrade 直接落地到 26100.33296，而不是修回 2033 後，再走一次目前已經確定會出錯的 CBS 更新流程。

正式執行前先做 Compatibility Scan：

setup.exe /auto upgrade /compat scanonly /dynamicupdate disable

結果：

0xC1900210
CompatHardBlockedProviders = 0

依 Microsoft 的 Windows Setup 文件，使用 /Compat ScanOnly 且沒有相容性問題時，回傳 0xC1900210 是正常結果。

因為這是一台遠端 Production Server，正式執行前另外完成 SQL Database Backup / Verify、IIS 與 DNS 備份、啟用 Local Administrator、暫時移除 ESET、確認 RAID 開機驅動，以及預先確認 RDP / WinRM。

正式執行：

WS2025-LangRepair\setup.exe /Auto Upgrade /DynamicUpdate Disable /MigrateDrivers All /ShowOOBE None /Telemetry Disable /NoReboot

/DynamicUpdate Disable 是避免 Setup 再下載新的更新；/NoReboot 則讓線上階段完成後先停住，再自行停止 IIS、CHECKPOINT Database、停止 SQL Service，最後才手動重新開機。這兩個參數都有 Microsoft 官方文件可查。

16:47  開始 Repair Upgrade
17:25  線上階段完成
17:35  手動重新啟動
17:38  新系統開機

離線階段意外地不到三分鐘，修復後版本：

26100.2033 → 26100.33296

SQL 17 個 Database 全部 ONLINE，IIS、WMS、DNS、Domain Trust 與網路設定也都正常。

另外遇到兩個小問題：

TermService 升級後變成 Manual 且沒有啟動，造成 RDP 一度無法連線，手動啟動並改回 Automatic 即可。
Windows 啟用狀態掉了，表示 0xC004F057；重新輸入伺服器機身貼紙上的 Product Key 後即恢復啟用。推測是自製映像內的 Key 與原機授權不符。

【最後驗證】

Repair Upgrade 完成後，再讓 Windows Update 自己重新檢查更新。這次 KB5120233 由 Windows Update 正常下載並安裝：

ID 19
Windows 已成功安裝：
2026-08 安全性彙總更新 KB5120233

新的 CBS Log 中：

0x80070306                    = 0
0x800736b3                    = 0
Hydration failed              = 0
STATUS_SXS_ASSEMBLY_NOT_FOUND = 0

也就是說這次不只是用新版映像把 Build 蓋過去，而是 Windows 本身的 CBS / Windows Update servicing 能力真的恢復正常了。

【結論】

　　這次花了三天，最初只是 0x80070306，一路從缺檔、Language Pack、PSFX、Hydration，最後追到 CSI / TLC 的狀態不一致。

　　如果未來再遇到類似情況：多個不相干元件都在 MarkTlcUnstaged 出現 STATUS_SXS_ASSEMBLY_NOT_FOUND，而 SFC、DISM、ComponentCleanup 都正常或無效，我大概不會再花三天逐一修元件，而會更早評估 In-place Repair Upgrade。

　　當然，Production Server 做 Repair Upgrade 前，備份、開機磁碟驅動、遠端登入方式，以及失敗後的救援方案，都還是要先準備好。

《相關連結》