无缝衔接的危机预防与恢复

2025-07-18

如果固件更新失败，结果可能是毁灭性的。更新最多会失败，但系统可以复原并恢复，而不会让最终用户意识到这一点。最糟糕的是，失败的固件更新可能导致系统不可用，要求最终用户将其系统退回零售商或制造商进行修复。后一种情况是我们所谓的危机。

危机可能是由于固件更新失败或由于与 Windows 或其他系统方面不兼容的固件导致的。本部分讨论旨在防止和恢复因固件更新失败而导致的危机的功能。我们期望固件作者的固件更新测试覆盖率可防止因不兼容固件而导致的大多数危机。

为了为最终用户提供出色的体验，必须满足固件驱动程序包更新机制的以下危机预防和恢复要求。这些要求不排除额外的危机预防或恢复解决方案。

预安装条件

当系统固件执行实际更新时，必须执行一系列预安装检查。系统固件必须执行此检查，以确保有足够的电源来完成更新。此外，建议在应用更新之前对每个更新进行检查，尤其是在存在多个固件更新的情况下。下表中提供了要检查和验证的项目列表。必须在适用的情况下执行所有检查。执行测试没有具体顺序。

检查类型	DESCRIPTION
权力	系统必须至少具备 25% 电池电量。不需要使用有线电源（通过USB电缆和/或交流电源供电）。在测试/实验室环境中，只要提供外接电源，允许进行固件更新，即使没有电池也是可以接受的。但是，必须在电池死电/不充电和电池不存在之间做出区分。
安全性	验证更新胶囊有效负载是否已正确签名。确保负载中的所有基于 PE 的 EFI 文件已用适当的 EFI 证书正确签名。
完整性	对固件更新负载执行完整性检查。
版本	验证所应用的固件不会将当前已安装的固件降级低于 LowestSupportedFirmwareVersion 值。
存储	根据系统的硬件，将根据需要执行以下检查有足够的空间来备份将要替换的当前固件设备中有足够的空间来容纳新固件。

任何失败都必须生成适当的上次尝试状态错误代码。有关详细信息，请参阅 ESRT 表定义和固件更新状态中的“上次尝试状态”错误代码信息。

如果同时应用多个更新，而其中一些通过了预安装检查，而另一些没有，平台固件可以继续更新那些通过预安装检查的资源的固件。但是，任何未通过预安装检查的资源都不得更新。

安装后条件

安装固件（设备或系统）后，必须对其进行检查，以验证新更新的固件映像是否为预期。目的是尽量减少在实际更新操作中引入的任何数据损坏的风险（例如，闪存ROM中的粘滞位、更新期间总线上的干扰等）。

更新过程必须验证更新的固件是否通过完整性检查。如果失败，则系统必须通过回滚到固件的上一个已知良好版本来进行恢复。

任何失败都必须生成适当的最后尝试状态错误代码。有关详细信息，请参阅 ESRT 表定义和固件更新状态中的“上次尝试状态”错误代码信息。

从安装和启动失败中恢复

为了防止系统达到不可启动状态，固件更新机制在固件更新无法安装或系统无法成功启动的情况下，必须满足以下要求。

在以下部分中，术语“已提交”用于描述固件。固件一旦“提交”，就被视为已完全安装，遇到启动失败等问题时，固件将不会自动回滚。 “未提交的”固件指的是部分更新的固件，在固件更新无法完成或更新固件检测到错误（例如更新中的 CRC 校验无效）的情况下，可能会回滚到之前的版本。固件是否提交是固件本身应进行内部监控的事项，并且不会记录在 ESRT 中。

固件更新失败

如果单个系统或设备固件无法安装或安装不正确（例如，由于某种损坏或安装更新时断电），则更新可能总共重试三（3）次尝试，包括第一次尝试。如果固件将执行其他重试尝试，则系统不得在任何尝试之间启动到 Windows。如果所有尝试都失败，更新固件必须放弃更新。如果部分应用了更新，固件必须回滚到以前的版本。固件必须回滚到以前的版本，而无需任何用户交互。更新失败不会影响其他待处理的更新。应该尝试进行待处理的固件更新。

处理完所有更新后，UEFI 将恢复启动 Windows。 UEFI 固件必须验证是否已成功安装任何未提交的固件更新，以缓解因电源丢失而导致的问题（UEFI 绝不应尝试使用部分写入的固件启动 Windows）。

安装失败的可能原因包括但不限于以下问题：