注意
- 原始发布日期： 2026 年 3 月 19 日
- KB ID： 5085046
本文内容
- 概述
- 安全启动证书服务的工作原理
- 排除故障时从何处开始
- 安全启动-更新计划任务
- 为什么要使用计划任务
- AvailableUpdates 注册表位掩码
- 与 OEM 固件集成
- 常见故障场景和解决方法
- 参考和内部
- AvailableUpdates 位用于证书服务
- AvailableUpdates) (预期进度
- 修正过程
- 在固件中启用安全启动
- 禁用或已删除安全启动计划任务
概述
本页指导管理员和支持专业人员诊断和解决 Windows 设备上的安全启动相关问题。 主题包括安全启动证书更新失败、安全启动状态不正确、意外的 BitLocker 恢复提示以及安全启动配置更改后的启动失败。
本指南说明了如何验证 Windows 服务和配置、查看相关注册表值和事件日志，以及确定固件或平台限制何时需要 OEM 更新。 此内容用于诊断现有设备上的问题。 它并不用于规划新部署。 本文档将在确定新的故障排除方案和指南时进行更新。
安全启动证书服务的工作原理
Windows 上的安全启动证书服务是操作系统与设备的 UEFI 固件之间的协调过程。 目标是更新关键信任密钥，同时保留在每个阶段启动的能力。
此过程由 Windows 计划任务、基于注册表的更新操作序列以及内置日志记录和重试行为驱动。 这些组件共同确保安全启动证书和 Windows 启动管理器以受控、有序的方式更新，并且仅在前提步骤成功后才更新。
排除故障时从何处开始
当设备在应用安全启动证书更新方面似乎没有取得预期进展时，请首先确定问题的类别。 大多数问题属于以下四个方面之一：Windows 服务状态、安全启动更新机制、固件行为或平台或 OEM 限制。
从下面的检查开始，按顺序排列。 在许多情况下，这些步骤足以解释观察到的行为并确定后续操作，而无需进行更深入的调查。
确认 Windows 服务和平台资格
- 验证设备是否满足接收安全启动证书更新的基本要求：
- 设备运行的是受支持的 Windows 版本。
- 已安装最新必需的 Windows 安全更新。
- UEFI 固件中启用了安全启动。
- 如果不满足上述任何条件，请先解决这些问题，然后再继续进行进一步的故障排除。
-
- 确认负责应用安全启动证书更新的 Windows 机制存在并正常运行：
- 存在 Secure-Boot-Update 计划任务。
- 该任务已启用并作为本地系统运行。
- 自安装最新的 Windows 安全更新以来，该任务已至少运行一次。
- 如果任务已禁用、删除或未运行，则无法应用安全启动证书更新。 在调查其他原因之前，故障排除应侧重于还原任务。
检查注册表设置以了解预期进度
在注册表中查看设备的安全启动服务状态：- 检查 UEFICA2023Status、 UEFICA2023Error 和 UEFICA2023ErrorEvent。
- 检查 AvailableUpdates 并将其与预期进度进行比较 (请参阅参考和内部) 。
这些值共同指示服务是正常进行、重试操作还是在特定步骤停止。
将注册表状态与安全启动事件相关联
查看系统事件日志中与安全启动相关的事件，并将其与注册表状态相关联。 事件数据通常确认设备是向前推进、是由于暂时性情况而重试，还是被固件或平台问题阻止。
注册表和事件日志通常共同指示行为是预期行为、临时行为还是需要纠正措施。
安全启动-更新计划任务
安全启动证书服务是通过名为 Secure-Boot-Update 的 Windows 计划任务实现的。 该任务在以下路径注册：
注意
\Microsoft\Windows\PI\Secure-Boot-Update
任务作为本地系统运行。 默认情况下，它在系统启动时运行，此后每 12 小时运行一次。 每次运行时，它都会检查安全启动更新操作是否处于挂起状态，并尝试按顺序应用这些操作。
如果禁用或缺少此任务，则无法应用安全启动证书更新。 安全启动更新任务必须保持启用状态，安全启动服务才能正常运行。
为什么要使用计划任务
安全启动证书更新需要 Windows 和 UEFI 固件之间的协调，包括编写存储安全启动密钥和证书的 UEFI 变量。 计划任务允许 Windows 在系统处于可以修改固件变量的状态时尝试这些更新。
如果上一次尝试失败或设备在未重启的情况下保持开机状态，则定期的 12 小时计划提供了重试更新的额外机会。 这种设计有助于确保向前推进，而无需人工干预。
AvailableUpdates 注册表位掩码
Secure-Boot-Update 任务由 AvailableUpdates 注册表值驱动。 此值是一个 32 位位掩码，位于：
注意
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
值中的每个位表示特定的安全启动更新操作。 当 Windows 自动或由管理员显式将 AvailableUpdates 设置为非零值时，更新过程开始。 例如，诸如 0x5944 之类的值指示多个更新操作处于挂起状态。
运行 Secure-Boot-Update 任务时，它会将设置的位解释为挂起的工作，并按定义的顺序处理它们。
顺序更新、日志记录和重试行为
安全启动证书更新按固定顺序应用。 每个更新操作都设计为可安全重试，并独立完成。 在当前操作成功并且其对应位从 AvailableUpdates 中清除之前，Secure-Boot-Update 任务不会继续到下一步。
每个操作都使用标准 UEFI 接口更新安全启动变量（如 DB 和 KEK）或安装更新的 Windows 启动管理器。 Windows 在系统事件日志中记录每个步骤的结果。 成功事件确认向前进度，而失败事件指示无法完成操作的原因。
如果更新步骤失败，则任务将停止处理、记录错误并保留关联的位集。 下次运行任务时，将重试该操作。 此重试行为允许设备从临时状况中自动恢复，例如缺少固件支持或延迟 OEM 更新。
管理员可以通过将注册表状态与事件日志条目相关联来跟踪进度。 注册表值（如 UEFICA2023Status、 UEFICA2023Error 和 UEFICA2023ErrorEvent）以及 AvailableUpdates 位掩码指示哪个步骤处于活动状态、已完成或已阻止。
此组合显示设备是正常进展、重试操作还是已停止。
与 OEM 固件集成
安全启动证书更新取决于设备 UEFI 固件中的正确行为和支持。 当 Windows 协调更新过程时，固件负责强制实施安全启动策略并维护安全启动数据库。
OEM 提供了两个启用安全启动证书服务的关键元素：
- 平台密钥签名的密钥交换密钥 (KEK) 授权安装新的安全启动证书。
- 在更新期间正确保留、追加和验证安全启动数据库的固件实现。
如果固件不完全支持这些行为，安全启动更新可能会停止、无限期重试或导致启动失败。 在这些情况下，如果不更改固件，Windows 无法完成更新。
Microsoft 与 OEM 合作，确定固件问题并提供更正的更新。 当故障排除指示固件限制或缺陷时，管理员可能需要先安装设备制造商提供的最新 UEFI 固件更新，然后才能成功完成安全启动证书更新。
常见故障场景和解决方法
安全启动更新由 Secure-Boot-Update 计划任务根据 AvailableUpdates 注册表状态应用。
在正常情况下，这些步骤会自动发生，并在每个阶段完成时记录成功事件。 在某些情况下，固件行为、平台配置或服务先决条件可能会阻碍进度或导致意外的启动行为。
以下部分介绍最常见的故障场景、如何识别它们、发生故障的原因以及恢复正常运行的适当后续步骤。 场景按最常遇到的情况到影响启动的更严重情况排序。
安全启动更新未应用 (无进度)
当安全启动更新显示没有进度时，通常意味着更新过程从未启动。 因此，缺少预期的安全启动注册表值和事件日志，因为更新机制从未触发。
发生的变化
安全启动更新过程未启动，因此未将安全启动证书或更新的启动管理器应用到设备。
如何识别它
- 不存在安全启动服务注册表值，例如 UEFICA2023Status。
- 预期的安全启动事件 (例如，系统事件日志中缺少 1043、1044、1045、1799、1801) 。
- 设备继续使用较旧的安全启动证书和启动组件。
发生原因
当以下一个或多个条件为 true 时，通常会发生这种情况：
- Secure-Boot-Update 计划任务已禁用或缺失。
- UEFI 固件中已禁用安全启动。
- 设备不符合 Windows 服务先决条件，例如运行受支持的 Windows 版本或安装了所需的更新。
下一步操作
- 验证设备是否满足 Windows 服务和平台资格要求。
- 确认固件中已启用安全启动。
- 确保 SecureBootUpdate 计划任务存在并已启用。
如果计划任务已禁用或缺失，请按照“安全启动”中的指南禁用 或删除计划任务 来还原它。 还原任务后，重新启动设备或手动运行任务以启动安全启动服务。
安全启动更新后，设备启动到 BitLocker 恢复
在某些情况下，与安全启动相关的更新可能会导致设备进入 BitLocker 恢复。 该行为可以是暂时性的，也可以是持久性的，具体取决于根本原因。
方案 1：安全启动更新后一次性 BitLocker 恢复
发生的情况
设备在安全启动更新后的第一次启动时进入 BitLocker 恢复，但在后续重启时将正常启动。
发生原因
在更新后的第一次启动期间，当 Windows 尝试重新封装 BitLocker 时，固件尚未报告更新的安全启动值。 这会导致测量的启动值暂时不匹配并触发恢复。 下次启动时，固件将正确报告更新的值，BitLocker 将成功重新封装，并且此问题不会再次出现。
如何识别它
- BitLocker 恢复执行一次。
- 输入恢复密钥后，后续启动不会提示恢复。
- 不存在正在进行的启动顺序或 PXE 参与。
下一步操作
- 输入 BitLocker 恢复密钥以恢复 Windows。
- 检查固件更新。
方案 2：由于 PXE 首次启动配置而重复 BitLocker 恢复
发生的情况
设备在每次启动时进入 BitLocker 恢复。
发生原因
设备配置为 首先尝试 PXE (网络) 启动。 PXE 启动尝试失败，固件随后回退到磁盘上的 Windows 启动管理器。
这会导致 在单个启动周期中测量两个不同的签名机构：
- PXE 启动路径由 Microsoft UEFI CA 2011 签名。
- 磁盘上的 Windows 启动管理器由 Windows UEFI CA 2023 签名。
由于 BitLocker 在启动过程中观察到不同的安全启动信任链，因此它无法建立一组稳定的 TPM 度量值来重新封装。 因此，BitLocker 在每次启动时都会进入恢复状态。
如何识别它
- 每次重启时都会触发 BitLocker 恢复。
- 输入恢复密钥将允许 Windows 启动，但下次启动时会返回提示。
- PXE 或网络启动在固件启动顺序中在本地磁盘之前进行配置。
下一步操作
- 配置固件启动顺序，以便磁盘上的 Windows 启动管理器首先运行。
- 如果不需要，则禁用 PXE 启动。
- 如果需要 PXE，请确保 PXE 基础结构使用 2023 签名的 Windows 启动加载程序。
重置安全启动后设备无法启动
发生的变化
这反映的是固件级别的更改，而不是 Windows 问题。 安全启动更新已成功完成，但在稍后重启后，设备不再启动进入 Windows。
如何识别它
- 设备无法启动 Windows，并且可能显示指示安全启动冲突的固件或 BIOS 消息。
- 将 安全启动设置重置为固件默认值后，会发生此故障。
- 禁用安全启动可能允许设备再次启动。
发生原因
将安全启动重置为固件默认值将清除存储在固件中的安全启动数据库。 在已转换到 Windows UEFI CA 2023 签名的启动管理器的设备上，此重置将删除信任该启动管理器所需的证书。
因此，固件不再将已安装的 Windows 启动管理器识别为受信任，并阻止启动过程。
这种情况不是由安全启动更新本身导致的，而是由删除更新的信任定位点的后续固件操作导致的。
下一步操作
- 使用安全启动恢复实用程序还原所需的证书，以便设备可以再次启动。
- 恢复后，请确保设备安装了设备制造商提供的最新可用固件。
- 避免将安全启动重置为固件默认值，除非 OEM 固件包含信任 2023 证书的更新安全启动默认值。
安全启动恢复实用工具
要恢复系统，请执行以下操作：
- 在安装了 2024 年 7 月或更高版本的 Windows 更新的第二台 Windows 电脑上，从 C：\Windows\Boot\EFI\ 复制 SecureBootRecovery.efi。
- 将文件置于 FAT32 格式的 U 盘上的 \EFI\BOOT\ 下，并将其重命名为 bootx64.efi。
- 从 U 盘启动受影响的设备，并允许恢复实用程序运行。 该实用工具会将 Windows UEFI CA 2023 添加到数据库。
还原证书且系统重启后，Windows 应正常启动。
重要提示： 此过程只会重新应用其中一个新证书。 设备恢复后，请确保重新应用了最新证书，并考虑将系统的 BIOS/UEFI 更新到可用的最新版本。 这有助于防止安全启动重置问题再次发生，因为许多 OEM 已经针对此特定问题发布了固件修补程序。
由于固件覆盖数据库，设备在安全启动更新后无法启动
发生的变化
应用安全启动证书更新并重启后，设备无法启动，无法访问 Windows。
如何识别它
- 安全启动更新要求的重启后，设备立即出现故障。
- 可能会显示固件或安全启动错误，或者系统可能会在 Windows 加载之前停止。
- 禁用安全启动可能允许设备启动。
发生原因
此问题可能是由设备的 UEFI 固件实现中的缺陷引起的。
当 Windows 应用安全启动证书更新时，固件应将新证书 附加 到现有的安全启动允许的签名数据库 (DB) 。 某些固件实现错误地 覆盖 了数据库，而不是附加到数据库。
发生这种情况时，
- 以前信任的证书（包括 Microsoft 2011 启动加载程序证书）将被删除。
- 如果此时系统仍在使用使用 2011 证书签名的启动管理器，则固件将不再信任它。
- 固件拒绝启动管理器并阻止启动过程。
在某些情况下，DB 也可能损坏而不是完全覆盖，从而导致相同的结果。 已在特定固件实现上观察到此行为，在符合的固件上预计不会出现此行为。
下一步操作
- 进入固件设置菜单并尝试重置安全启动设置。
- 如果设备在重置后启动，请检查设备制造商的支持网站，以获取可更正安全启动数据库处理的固件更新。
- 如果固件更新可用，请先安装它，然后再重新启用安全启动并重新应用安全启动证书更新。
如果重置安全启动无法恢复启动功能，进一步恢复可能需要特定于 OEM 的指导。
由于缺少 OEM 签名的 KEK，安全启动更新被阻止
发生的变化
安全启动证书更新未完成，并且在密钥交换密钥 (KEK) 更新阶段仍受阻止。
如何识别它
- AvailableUpdates 注册表值保持使用 KEK 位 (0x0004) 设置，不会被清除。
- UEFICA2023Status 不会进展为已完成状态。
- 系统事件日志反复记录 事件 ID 1803，指示无法应用 KEK 更新。
- 设备继续重试更新，而没有向前进展。
发生原因
更新安全启动 KEK 需要从设备的 平台密钥 (PK) （由 OEM 拥有）进行授权。
要使更新成功，设备制造商必须为该特定平台向 Microsoft 提供 PK 签名的 KEK 。 此 OEM 签名的 KEK 包含在 Windows 更新中，并允许 Windows 更新固件 KEK 变量。
如果 OEM 未为设备提供 PK 签名的 KEK，则 Windows 无法完成 KEK 更新。 处于此状态下：
- 安全启动更新被设计阻止。
- Windows 无法解决缺少授权的问题。
- 设备可能永久无法完成安全启动证书服务。
这可能发生在 OEM 不再提供固件或密钥更新的较旧或不受支持的设备上。 对于此情况，没有支持的手动恢复路径。
安全启动证书更新事件和失败指示器
当安全启动证书更新无法应用时，Windows 会记录诊断事件，以解释为何阻止进度。 更新安全启动签名数据库时写入这些事件 (DB) 或密钥 (交换 由于固件、平台状态或配置条件导致无法安全完成的 KEK) 。 本节中的方案引用这些事件来识别常见的故障模式并确定适当的修正措施。 本节旨在支持对先前描述的问题的诊断和解释，而不是引入新的故障方案。
有关事件 ID、说明和示例条目的完整列表，请参阅 安全启动数据库和 DBX 变量更新事件 (KB5016061) 。
KEK 更新失败 (DB 更新成功，但 KEK 不)
设备可以成功更新安全启动数据库中的证书，但在 KEK 更新期间失败。 发生这种情况时，无法完成安全启动更新过程。
症状
- DB 证书事件指示进度，但 KEK 阶段未完成。
- AvailableUpdates 仍设置为 0x4004，并且在运行多个任务后不会清除0x0004位。
- 可能存在事件 1795 或 1803 。
解释
- 1795 通常指示在尝试更新安全启动变量时固件失败。
- 1803 指示无法授权 KEK 更新，因为平台没有所需的 OEM PK 签名 KEK 有效负载。
后续步骤
- 对于 1795，请检查 OEM 固件更新并验证固件对安全启动变量更新的支持。
- 对于 1803，请确认 OEM 是否已向 Microsoft 提供了设备型号所需的 PK 签名的 KEK。
Hyper-V 上托管的来宾 VM 上的 KEK 更新失败
在 Hyper-V 虚拟机上，安全启动证书更新需要在 Hyper-V 主机和来宾操作系统上安装 2026 年 3 月 Windows 更新。
更新失败是 从来宾内部报告的，但该事件指示需要修正的位置：
- 来宾中报告的事件 1795 (例如“媒体受写保护”) 指示 Hyper-V 主机缺少 2026 年 3 月更新，必须进行更新。
- 来宾中报告的事件 1803 指示来宾虚拟机本身缺少 2026 年 3 月更新，必须进行更新。
参考和内部
本部分包含用于故障排除和支持的高级参考信息。 它不适用于部署规划。 它扩展了之前总结的安全启动服务机制，并提供了解释注册表状态和事件日志的详细参考资料。
注意 (IT 托管部署) ：通过 组策略 或 Microsoft Intune 配置时，不应混淆两个类似的设置。 AvailableUpdatesPolicy 值表示配置的策略状态。 同时， AvailableUpdates 反映正在进行的位清除工作状态。 两者可以带来相同的结果，但它们的行为不同，因为政策会随着时间的推移重新应用。
AvailableUpdates 位用于证书服务
以下位用于本文档中所述的证书和启动管理器操作。 “ 顺序” 列反映了 Secure-Boot-Update 任务处理每个位的顺序。
| Order | 位设置 | 用法 |
|---|---|---|
| 1 | 0x0040 | 此位指示计划任务将 Windows UEFI CA 2023 证书添加到安全启动数据库。 这允许 Windows 信任由此证书签名的启动管理器。 |
| 2 | 0x0800 | 此位指示计划任务将 Microsoft 选项 ROM UEFI CA 2023 应用于 DB。 条件行为：设置 0x4000 标志后，计划任务将首先检查数据库以获取 Microsoft Corporation UEFI CA 2011 证书。 仅当 2011 证书存在时，它才会应用 Microsoft Option ROM UEFI CA 2023 证书。 |
| 3 | 0x1000 | 此位指示计划任务将 Microsoft UEFI CA 2023 应用于数据库。 条件行为：设置 0x4000 标志后，计划任务将首先检查数据库以获取 Microsoft Corporation UEFI CA 2011 证书。 仅当存在 2011 证书时，它才会应用 Microsoft UEFI CA 2023 证书。 |
| 修饰符 (行为标志) | 0x4000 | 此位修改 0x0800 位和 0x1000 位的行为，以便仅当数据库已包含 Microsoft Corporation UEFI CA 2011 时，才应用 Microsoft UEFI CA 2023 和 Microsoft 选项 ROM UEFI CA 2023。 为了帮助确保设备的安全配置文件保持不变，仅当设备信任 Microsoft Corporation UEFI CA 2011 证书时，此位才应用这些新证书。 并非所有 Windows 设备都信任此证书。 |
| 4 | 0x0004 | 此位指示计划任务查找由设备的平台密钥 (PK) 签名的密钥交换密钥。 PK 由 OEM 管理。 OEM 使用其 PK 签署 Microsoft KEK，并将其发送到 Microsoft，将其包含在每月累积更新中。 |
| 5 | 0x0100 | 此位指示计划任务将由 Windows UEFI CA 2023 签名的启动管理器应用于启动分区。 这将替换 Microsoft Windows 生产 PCA 2011 签名的启动管理器。 |
注意：
- 处理所有其他位后，0x4000 位将保持设置。
- 每个位都由 Secure-Boot-Update 计划任务按上面所示的顺序处理。
- 如果由于缺少 PK 签名的 KEK 而无法处理0x0004位，则计划的任务仍将应用位 0x0100 指示的启动管理器更新。
AvailableUpdates) (预期进度
当操作成功完成时，Windows 将从 AvailableUpdates 中清除关联位。 如果操作失败，Windows 将记录事件并在任务再次运行时重试。
下表显示了每个安全启动更新操作完成时 AvailableUpdates 值的预期进度。
| 步骤 | 已处理的位 | 可用汇报 | 说明 | 记录的成功事件 | 可能的错误事件代码 |
|---|---|---|---|---|---|
| 开始 | 0x5944 | 安全启动证书服务开始之前的初始状态。 | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 已添加到安全启动数据库。 | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | 如果设备以前信任 Microsoft UEFI CA 2011，请将 Microsoft 选项 ROM UEFI CA 2023 添加到数据库。 | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | 如果设备以前信任 Microsoft UEFI CA 2011，则会将 Microsoft UEFI CA 2023 添加到数据库。 | 1045 | 1032, 1795, 1796, 1802 |
| 4 | 0x0004 | 0x4104 → 0x4100 | 应用由 OEM 平台密钥签名的新 Microsoft KEK 2K CA 2023。 | 1043 | 1032, 1795, 1796, 1802, 1803 |
| 5 | 0x0100 | 0x4100 → 0x4000 | 已安装由 Windows UEFI CA 2023 签名的启动管理器。 | 1799 | 1797 |
注意
- 与某位关联的操作成功完成后，将从 AvailableUpdates 中清除该位。
- 如果其中一个操作失败，将记录事件，并在下次运行计划任务时重试该操作。
- 0x4000位是修饰符，不会清除。 最终的 AvailableUpdates 值为 0x4000 指示已成功完成所有适用的更新操作。
- 事件 1032、1795、1796、1802 通常指示固件或平台限制。
- 事件 1803 指示缺少 OEM PK 签名的 KEK。
修正过程
本节提供了修正特定安全启动问题的分步过程。 每个程序的范围都限于明确定义的条件，并且仅在初始诊断确认问题适用后才遵循。 使用这些过程还原预期的安全启动行为，并允许证书更新安全地继续进行。 不要广泛或先发制人地应用这些程序。
在固件中启用安全启动
如果在设备的固件中禁用了安全启动，请参阅 Windows 11 和安全启动，了解有关启用安全启动的详细信息。
禁用或已删除安全启动计划任务
Windows 应用安全启动证书更新需要安全 启动更新 计划任务。 如果任务已禁用或缺失，则安全启动证书服务将不会进行。
任务详细信息
| 任务名称 | Secure-Boot-Update |
|---|---|
| 任务路径 | \Microsoft\Windows\PI\ |
| 完整路径 | \Microsoft\Windows\PI\Secure-Boot-Update |
| 运行身份 | SYSTEM (Local System) |
| 触发器 | 启动时和每 12 小时一次 |
| 必需状态 | 已启用 |
如何检查任务状态
从提升的 PowerShell 提示符运行：
schtasks.exe /query /TN “\Microsoft\Windows\PI\Secure-Boot-Update” /FO LIST /V
查找“ 状态 ”字段：
| 状态 | 含义 |
|---|---|
| 就绪 | 任务存在并已启用。 |
| 已禁用 | 任务存在，但必须启用。 |
| 错误/未找到 | 任务丢失，必须重新创建。 |
如何启用或重新创建任务
如果 Secure-Boot-Update 的状态字段为“已禁用”、“错误”或“找不到”，请使用示例脚本启用任务： 示例 Enable-SecureBootUpdateTask.ps1
注意：这是一个示例脚本，不受 Microsoft 支持。 管理员应查看并使其适应其环境。
示例：
注意
.\Enable-SecureBootUpdateTask.ps1 -安静
运行指南
- 如果看到访问被拒绝，请以管理员身份重新运行 PowerShell。
- 如果由于执行策略而导致脚本无法运行，请使用进程范围绕过：
注意
Set-ExecutionPolicy -scope process -ExecutionPolicy Bypass