升级 Windows 11 26H2 踩坑记：0x8000ffff 的真相，只是一次重启

2026-10-11 · Windows 11 25H2 → 26H2
全程不到一小时，其中四十分钟花在排查一个其实”重启一次”就能解决的报错上。

背景：26H2 来了，但它不来找我

Windows 11 26H2 于 9 月底正式推送。和 25H2 一样，它与 24H2 共享同一个服务分支，所以对已经在该分支上的设备来说，所谓”年度大更新”其实只是一个几百 KB 的启用包（enablement package）：装完重启一次即切换版本，不动文件、不动软件，体验和装一次月度补丁差不多。

我的机器是 25H2（Build 26200.9550），条件完全符合。兴冲冲打开 设置 → Windows 更新 → 检查更新——没有。

原因很简单：微软对功能更新采用分阶段推送（staged rollout），按设备硬件兼容性和遥测逐步放量。9 月 30 日开始推送，不代表 10 月初就能轮到每一台机器。

不过先别急着怪微软，确认自己这边没有低级问题：

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings"

关键看两项：更新没有暂停（PauseUpdatesExpiryTime 为空），”尽快获取最新更新”开关已打开（IsContinuousInnovationOptedIn = 1）。配置无懈可击，纯粹是还没轮到我。

强制投放：三条注册表

等不及的话，可以用注册表把目标版本锁定到 26H2，Windows 更新下次扫描时就会直接投放：

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetReleaseVersion /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetReleaseVersionInfo /t REG_SZ /d "26H2" /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ProductVersion /t REG_SZ /d "Windows 11" /f

回到设置里再点检查更新，”Windows 11 26H2 功能更新”立刻出现。点下载，几秒完成（启用包真的很小），点安装——

安装错误 – 0x8000ffff。

翻车：0x8000ffff

0x8000ffff 即 E_UNEXPECTED，”灾难性失败”，一个出了名的没有信息量的错误码。网上的修复清单能拉出十几条：Windows 更新疑难解答、重置 SoftwareDistribution、DISM RestoreHealth、sfc、就地修复安装……

但我先做了一轮取证，而不是直接照单开药：

1. 更新历史里没有 26H2 的任何安装记录，只有 Defender 病毒库更新——说明这次失败压根没有进入安装阶段；
2. CBS.log（服务堆栈日志）里搜不到这个错误码——组件安装根本没开始；
3. C:\$WINDOWS.~BT 不存在——连升级暂存目录都没有建立。

三条证据指向同一件事：失败发生在下载/校验/暂存的早期环节，”安装错误”这个提示语本身就是误导。

那么，什么东西能在早期环节一票否决一次功能更新？再查一个地方：

# 是否存在挂起的重启事务
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -ErrorAction SilentlyContinue).PendingFileRenameOperations -ne $null

两项都是 True。

真相大白：系统里还挂着上一个更新留下的未完成事务。服务堆栈有条铁律——上一个事务没经过重启”清算”之前，不再受理新的组件操作。于是启用包在暂存时被直接拒绝，UI 只甩给你一个 0x8000ffff。

解决：重启，然后一次成功

保存工作，重启。回来再点 26H2 的”下载并安装”——下载、安装、重启、进度条一气呵成。设置 → 系统 → 关于：

项目	升级前	升级后
版本	25H2	26H2
内部版本	26200.9550	26300.9550

注意 UBR 末段（.9550）没变——这正是启用包的本质：仍在同一个服务分支上，只是”启用”了新版本号和新功能。

收尾：别忘了拆掉临时开关

那三条 TargetReleaseVersion 注册表是临时开关，使命完成后必须删除——否则它会一直把系统锁定在 26H2，明年 27H2 出来时这台机器会莫名其妙收不到推送：

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetReleaseVersion /f
reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v TargetReleaseVersionInfo /f
reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ProductVersion /f
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"  :: 返回空即清理干净

另外提醒：升级过程中途不要删这三条。版本锁定是 Windows 更新”持续认定”该版本可用的依据，中途删除可能在下次扫描时让正在下载的功能更新从队列里消失。

经验总结

1. 功能更新刷不出来，先看推送节奏，再怀疑自己。分阶段推送是常态；”尽快获取最新更新”开关 + TargetReleaseVersion 三件套，是”等不及”的标准解法。
2. 0x8000ffff 报在”安装”阶段，不等于错在安装。更新历史、CBS.log、$WINDOWS.~BT 三个证据足以把故障点定位到暂存之前，避免在错误的方向上浪费药方。
3. 有 RebootPending / PendingFileRename 挂起事务时，先重启再谈任何修复。这一步零成本，能省掉重置缓存、DISM 乃至就地修复安装的一整串折腾。
4. 版本锁定注册表是手术刀，不是常驻配置：中途删有风险，装完不删挡后路。

从报错到解决，最终用掉的修复动作是：重启了一次电脑。