五月补丁星期二过后，不少运行 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 的部署优先级提到前面，大概是眼下最稳妥的选择。