老森常谈 IT 帮助

Windows 更新遇到 0x80070306 错误

最近在处理一台香港的 Windows Server 2025，原本只是 Windows Update 安装 KB5120233 失败，没想到最后连续研究了三天，从 DISM 组件存放区、语言包、PSFX 水合，一路追到 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 人员，所以也没办法很豪迈地直接重装，Haha。

【最初的错误】

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 日志显示在处理几个 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 记账状态。

【最后解决方法：就地修复升级】

研究到这里后，继续逐一修 CBS 已经有点像打地鼠，因此最后决定改用 Windows Server 的 就地修复升级。

Microsoft 官方文件说明，In-place Upgrade 可以从 Windows Server 安装媒体执行 setup.exe，并保留文件、设置、应用程序与 Server 角色。这次不是直接使用原始 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 / 验证、IIS 与 DNS 备份、启用本地管理员、暂时移除 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 数据库、停止 SQL 服务，最后才手动重新启动。这两个参数都有 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，一路從缺檔、语言包、PSFX、Hydration，最後追到 CSI / TLC 的狀態不一致。

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

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

《相关链接》