Windows server 2019系统安装补丁KB5075904，下载完成后显示需要重启完成安装，重启过后依旧提示重启

吴彦玲

你的部署映像维护和管理工具报告运行成功，但进度条却突然停在正好5.0%的位置。这意味着基于组件的服务引擎只是暂时准备更新文件，并将实际安装推迟到启动序列，启动过程中过程会无声地遇到致命错误并回滚，且不会向用户界面发出明显警报。由于标准的在线系统维修未能解决这一根深蒂固的腐败问题，您必须检查系统的内部维护记录，以确定具体的故障组件。进入C：\Windows\Logs\CBS\，打开CBS.log文件，然后搜索与你上次重启尝试时间戳完全匹配的“Error”或“Failed”这两个词，找到阻止该交易的特定十六进制代码。

要强制绕过当前拒绝该补丁的激活操作系统锁和后台服务，你需要离线注入机柜文件。将服务器启动到Windows恢复环境，或使用Windows Server 2019安装ISO访问恢复命令提示符。进入恢复环境后，验证你的主操作系统驱动器代号，离线模式下驱动器经常从C切换到D，并执行命令DISM /Image：D：\ /Add-Package /PackagePath：C：\update\KB5075904\Windows10.0-KB5075904-x64.cab，将更新直接集成到休眠文件系统中。这种离线服务方式完全绕过了损坏的本地更新代理，迫使组件直接写入磁盘而不干扰。

副总统

吴**延玲好，**

你的问题进展如何？问题解决了吗？如果有，请考虑 接受这个答案 ，因为它也帮助了其他有相同问题的人。谢谢你:)

副总统

吴彦玲

这种现象在服务器运维中确实比较反常，它表明离线安装包虽然在系统运行阶段成功完成了更新文件的初步释放和挂载，但在重启进入预启动阶段时，Windows 模块安装服务由于某种底层冲突或资源受限，直接跳过了核心文件的替换环节。这通常意味着引导加载层或组件服务清单存在更深层次的逻辑断层，导致系统为了防止无法开机而静默取消了更新部署。

您现在需要直接排查组件基础架构服务的核心日志来定位具体的拦截原因。请打开 C:\Windows\Logs\CBS\CBS.log 文件，并搜索重启时间点附近的错误字段，这里通常会记录诸如 0x800f0922 这一类的确切错误代码。此外，这种情况极大概率与服务器的系统保留分区（System Reserved）空间不足有关。当该隐藏引导分区的可用空间过低时，系统将无法写入预启动阶段所需的更新指令，您可以通过磁盘管理工具为该分区分配一个临时盘符，清理掉内部堆积的冗余日志或多余字体文件来释放所需空间。

系统内部也可能存在陈旧的挂起文件重命名任务阻塞了更新通道。您可以打开注册表编辑器，定位到 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 路径，查看右侧是否存在 PendingFileRenameOperations 键值。如果该键值内部堆积了大量无效的历史文件路径，建议您在备份该注册表项后将其内容清空，这能有效疏通被堵塞的启动期任务队列。如果排查后发现底层组件和引导空间均正常，考虑到先前的代码修复可能未能完全覆盖受损的系统核心堆栈，直接加载 Windows Server 2019 的官方 ISO 镜像并在系统内运行安装程序进行覆盖升级（选择保留文件和应用程序），将是重建整个更新机制且不破坏现有业务的最有效方案。

Hi 吴彦玲,

Your troubleshooting steps effectively cleared the standard Windows Update cache, but the update is likely trapped in a Component-Based Servicing loop. When an installation fails mid-process, Windows Server tracks the incomplete tasks in a specific file, forcing the operating system into a continuous restart cycle. You can break this loop by navigating to C:\Windows\WinSxS and locating the pending.xml file. Because the TrustedInstaller service heavily protects this directory, you will need to right-click the file, adjust the security properties to take ownership, and grant your administrator account full control. Once you have permissions, renaming the file to pending.old will safely neutralize the stuck boot instructions without deleting system history.

Even with the file system cleared, the graphical interface might still cache the restart notification in the system registry. You can resolve this by opening the Registry Editor and navigating to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update to locate the RebootRequired subkey. Deleting this specific subkey severs the notification link and clears the persistent alert from your server dashboard. Checking the nearby HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing path for RebootPending or RebootInProgress keys and deleting them will also ensure the system's internal servicing queue is completely flushed.

Since your system file checker command did not resolve the issue, there is a strong chance of underlying corruption in the server component store preventing the patch from applying. You should open an elevated Command Prompt and execute DISM /Online /Cleanup-Image /RestoreHealth so the system can fetch healthy replacement files directly from Microsoft servers to repair the core image. Once the repair completes and you restart the server, you can bypass the local update agent entirely by downloading the standalone installer for your specific patch directly from the Microsoft Update Catalog.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP