五月补丁星期二过后,不少运行 Windows 11 24H2 和 25H2 的用户发现,本该例行安装的安全更新突然成了"绊脚石"。系统重启到三分之一处直接卡住,进度条僵在 35% 到 36% 之间,最终抛出一个并不陌生的错误代码——0x800f0922。这个问题并非个案,而是集中爆发在 EFI 系统分区剩余空间不足 10MB 的设备上。微软在接到大量反馈后,于 2026 年 5 月 26 日紧急推送了累积更新 KB5089573,算是给这场更新风波画上了句号。
故障的症结藏在启动分区里
很多用户可能从没留意过硬盘里那个只有几百兆的 EFI 系统分区。它平时安静得几乎隐形,却在系统更新时扮演着关键角色。五月安全更新 KB5089549 在部署阶段需要向这个分区写入新的启动文件,如果可用空间被压缩到 10MB 以下,写入操作就会失败。表象上看,更新流程能正常走完下载和初始安装,可一旦重启进入第二阶段,系统尝试更新引导环境时立刻崩溃,轻则回滚,重则让设备陷入不稳定状态。
微软最初的应对分为两条线。面向普通消费者和非托管企业设备,团队通过 Known Issue Rollback(KIR)自动下发缓解策略,让受影响的机器暂时绕过严格的磁盘空间检查。而企业 IT 管理员则拿到了一份注册表变通方案:在HKLM\SYSTEM\CurrentControlSet\Control\Bfsvc下调整EspPaddingPercent相关数值,手动为安装程序争取更多缓冲空间。这两种方法都能应急,但终究只是"治标"。
KB5089573 带来了什么
这次累积更新把 Windows 11 25H2 和 24H2 的系统版本号分别拔高到 26200.8524 与 26100.8524,核心任务就是彻底修复 ESP 空间不足导致的安装失败。微软在更新日志里明确确认,安装 KB5089573 之后,此前所有临时 workaround 都可以撤掉了。
作为一次生产级累积更新,KB5089573 的推送分两步走:先是面向部分设备的分批交付,随后才是全量开放。除了最引人注目的 ESP 修复,包里还塞进了几个值得关注的组件升级。AI 相关模块——包括图像搜索、内容提取、语义分析和设置模型——统一更新到 1.2605.856.0 版本,能看出微软仍在持续往设备端 AI 功能里加码。5 月 28 日逐步推送的个性化改进也打包在内。更底层的是服务堆栈更新 KB5092734(版本 26100.8519),它直接加固了 Windows Update 自身的安装基础设施,减少未来打补丁时出错的概率。
获取更新的几种路径
如果你的设备已经在 Windows 11 24H2 或 25H2 上,安装 KB5089573 没有任何额外门槛。最省事的办法自然是走系统自带的 Windows Update:打开设置,进入 Windows 更新,检查可选更新列表,看到 KB5089573 后直接下载安装即可。心急的用户也可以直奔 Microsoft 更新目录,用知识库编号搜到独立安装包手动部署。企业环境里,WSUS 管理员同样可以把这批补丁同步下来批量推送。
微软目前确认该更新在发布时没有任何已知问题,这在近期补丁里算是比较少见的状态。
关于卸载的冷知识
万一后续真的需要回退,这里有个坑得避开。很多人习惯双击独立安装包后调用wusa.exe /uninstall来卸载更新,但对 KB5089573 这招行不通。原因是它属于合并包,内部集成了服务堆栈更新(SSU),而 SSU 一旦装上就无法通过传统方式移除。正确的做法是用 DISM 命令行:先执行DISM /online /get-packages找到准确的包名,再运行DISM /Remove-Package指定 LCU 包名完成卸载。不过微软的态度很明确——安全更新涉及系统底层防护,随意移除风险极高,除非遇到极端兼容性问题,否则不建议折腾。
对于企业 IT 运维来说,这次 EFI 分区故障的波及面足够广,消费级笔记本和商用台式机都未能幸免。下个维护窗口里,把 KB5089573 的部署优先级提到前面,大概是眼下最稳妥的选择。