次の方法で共有


シームレスな危機防止と回復

ファームウェアの更新に失敗すると、結果が壊滅的になることがあります。 最善の場合、更新は失敗しますが、システムは回復力があり、エンドユーザーの認識なしで回復します。 最悪の場合、ファームウェアの更新に失敗すると使用できないシステムが発生する可能性があり、エンドユーザーは修理のためにシステムを販売元または製造元に送付することが必要になります。 後者のケースが危機と呼んでいるものです。

ファームウェアの更新が失敗した場合やWindows あるいはその他のシステムの側面と互換性のないファームウェアが原因で、危機が発生することがあります。 この章では、ファームウェアの更新の失敗に起因する危機を防ぎ、回復するように設計された機能について説明します。 ファームウェアの作成者によるファームウェア更新テストカバレッジによって、互換性のないファームウェアから生じるほとんどの危機を防ぐことが期待されます。

エンド ユーザーに優れたエクスペリエンスを提供するには、ファームウェア ドライバー パッケージの更新メカニズムについて、次の危機防止と回復の要件を満たす必要があります。 これらの要件は、追加の危機を防止したり、回復ソリューションを妨げることはありません。

プレインストール条件

システム ファームウェアが実際の更新を実行している場合は、一連のプレインストール チェックを実行する必要があります。 システム ファームウェアは、更新プログラムを完了するのに十分な電力があることを確認するためにこのチェックを実行します。 また、複数のファームウェア更新プログラムがある場合は、更新プログラムが適用される前に、各更新プログラムに対するチェックを行うことをお勧めします。 チェックして検証する項目の一覧を次の表に示します。 必要に応じて、すべてのチェックを実行します。 テストの実行に特定の順序はありません。

チェックの種類 説明
Power システムには、少なくとも 25% のバッテリ充電が必要です。

テザリング電源 (USB ケーブルまたは AC 電源経由の電源) は必要ありません。

テスト/ラボ環境では、テザリングされた電源が提供されている限り、バッテリがまだ存在しない場合でもファームウェアの更新を許可できます。 ただし、機能しないバッテリや充電されていないバッテリーの場合とバッテリーが存在しない場合は、区別する必要があります。
セキュリティ 更新プログラムのカプセル ペイロードが正しく署名されていることを確認します。

ペイロード内の PE ベースの EFI ファイルが適切な EFI 証明書で正しく署名されていることを検証します
整合性 ファームウェア更新プログラムのペイロードに対して整合性チェックを行ないます。
バージョン 適用されているファームウェアが、LowestSupportedFirmwareVersion 値を超えて現在インストールされているファームウェアをダウングレードしていないことを確認します。
ストレージ システムのハードウェアに応じて、次の適切なチェックを行ないます

置き換えられる現在のファームウェアのバックアップに十分なスペースがあること

デバイスには、新しいファームウェアに対応できる十分なスペースがあります。

エラーが発生した場合は、適切な最終試行状態エラー コードが発生する必要があります。 詳細については、ESRT テーブル定義およびファームウェアの更新状態で最新の試行状態エラー コード情報を参照してください。

複数の更新プログラムが適用されていて、その一部がプレインストール チェックに成功し、その他が成功しない場合、プレインストール チェックに成功したリソースのファームウェアの更新をプラットフォーム ファームウェアで続行できます。 ただし、プレインストール チェックに失敗したリソースを更新することはできません。

インストール後の条件

ファームウェア (デバイスまたはシステム) をインストールした後、新しく更新されたファームウェア イメージが意図したものであることを検証するには、ファームウェア (デバイスまたはシステム) をチェックする必要があります。 これは、実際の更新プロセス中に発生する破損のリスクを最小限に抑えるためです (フラッシュ ROM のスティッキー ビット、更新中のバスのノイズなど)。

更新プロセスでは、更新されたファームウェアが整合性チェックに成功したことを確認する必要があります。 失敗した場合は、ファームウェアの最新の既知の正常なバージョンにロールバックして回復する必要があります。

エラーが発生した場合は、適切な最終試行状態エラー コードが発生する必要があります。 詳細については、ESRT テーブル定義およびファームウェアの更新状態で最新の試行状態エラー コード情報を参照してください。

インストールと起動の失敗からの回復

システムが起動不可能な状態に達するのを防ぐために、ファームウェアの更新メカニズムは、ファームウェアの更新プログラムのインストールに失敗した場合、またはシステムが正常に起動できない場合に、次の要件を満たす必要があります。

次の章では、「コミット済み」という用語を使用してファームウェアを記述します。 ファームウェアが「コミット済み」になると、ファームウェアは完全にインストール済みとして扱われ、ブートエラーなどの理由でファームウェアによって自動的にロールバックされることはありません。「コミットしていない」ファームウェアは、部分的に更新されたファームウェアを記述し、ファームウェアの更新が完了できない場合や、更新中のファームウェアによってエラーが検出された場合に、以前のバージョンにロールバックされる可能性があります (たとえば、更新の無効な CRC チェックなど)。 ファームウェアがコミットされているかについてはファームウェアが内部的に追跡する必要があり、ESRT の一部としてはキャプチャされません。

ファームウェアの更新に失敗しました

個々のシステムまたはデバイスのファームウェアをインストールできない場合、または正しくインストールされていない場合 (たとえば、何らかの破損や、更新プログラムのインストール中に電源が失われたなど)、最初の試行を含む合計 3 回まで更新が再試行される可能性があります。 ファームウェアによって追加の再試行が実行される場合、試行の間にシステムを Windows で起動することはできません。 すべての試行が失敗した場合、更新ファームウェアは更新を諦めます。 更新プログラムが部分的に適用された場合、ファームウェアは以前のバージョンにロールバックする必要があります。 ファームウェアは、ユーザーの操作なしで以前のバージョンにロールバックする必要があります。 更新エラーは、他の保留中の更新プログラムには影響しません。保留中のファームウェアの更新を試みる必要があります。

すべての更新プログラムが処理されると、UEFI は Windows の起動を再開します。 UEFI ファームウェアは、電源損失による問題を軽減するために、コミットされていないファームウェアの更新プログラムが正常にインストールされたことを確認する必要があります (UEFI は、部分的に書き込まれたファームウェアで Windows を起動するべきではありません)。

インストールが失敗した原因には次のような問題が考えられます (ただし、これに限定されない)。

インストール失敗の原因 エラー コード
リソース不足 STATUS_INSUFFICIENT_RESOURCES
電力損失 STATUS_INSUFFICIENT_POWER
ハードウェア障害 STATUS_POWER_STATE_INVALID

ファームウェアの更新は成功したが、Windows の起動に失敗する

UEFI ファームウェアは、更新されたファームウェアがコミットされた後にロールバックする責任を負いません。 Windows の既存のフェールオーバー ロジックは、起動試行が 2 回失敗した後、エンド ユーザーを Windows 回復環境 (WinRE) に転送します。 WinRE が正常に起動する場合と起動しない場合があります。 エンド ユーザーは、システムを回復するために手動で回復手順を実行するか、または、デバイスを販売元/製造元に送付することが必要になります。

このようなエラーの原因として考えられるものは次のとおりですが、これらに限定されるわけではありません。

  • OS ドライバーと互換性のないファームウェア。

  • OS コンポーネントと互換性のないファームウェア。

ハードウェア ベンダーが、Windows が正常に起動したかどうかを判断する追加のロジックを実装することを決定した場合は、許容されます。 上述したように、ファームウェア作成者によるファームウェア更新テストカバレッジにより、互換性のないファームウェアによるほとんどの危機を防ぐことが期待されます。

ESRT テーブル定義

プラグ アンド プレイ デバイス

更新プログラム ドライバー パッケージの作成

更新プログラムの処理

UEFI 環境からのデバイス I/O

ファームウェア更新の状態