注
- 元の発行日: 2026 年 3 月 19 日
- KB ID: 5085046
この記事の内容
- 概要
- セキュア ブート証明書サービスのしくみ
- トラブルシューティング時にまず確認する場所
- セキュア ブート更新のスケジュールされたタスク
- スケジュールされたタスクが使用される理由
- AvailableUpdates レジストリ ビットマスク
- OEM ファームウェアとの統合
- 一般的なエラー シナリオと解決策
- 参照と内部
- 証明書サービスに使用される AvailableUpdates ビット
- 予想される進行状況 (AvailableUpdates)
- 修復手順
- ファームウェアでセキュア ブートを有効にする
- セキュア ブートのスケジュールされたタスクが無効または削除された
概要
このページでは、管理者とサポート担当者が Windows デバイスでのセキュア ブート関連の問題を診断および解決する際の手順を説明します。 トピックには、セキュア ブート証明書の更新エラー、正しくないセキュア ブート状態、予期しない BitLocker 回復プロンプト、セキュア ブート構成の変更後のブート エラーが含まれます。
このガイダンスでは、Windows のサービスと構成を確認し、関連するレジストリ値とイベント ログを確認し、ファームウェアまたはプラットフォームの制限により OEM 更新が必要になる場合を特定する方法について説明します。 この内容は、既存のデバイスの問題を診断することを目的としています。 新しい展開を計画するためのものではありません。 このドキュメントは、新しいトラブルシューティング シナリオとガイダンスが特定されるたびに更新されます。
セキュア ブート証明書サービスのしくみ
Windows でのセキュア ブート証明書のサービスは、オペレーティング システムとデバイスの UEFI ファームウェアの間で連携したプロセスです。 目標は、各ステージで起動する機能を維持しつつ、重要なトラスト アンカーを更新することです。
このプロセスは、Windows のスケジュールされたタスク、レジストリ ベースの更新操作のシーケンス、および組み込みのログと再試行の動作によって駆動されます。 これらのコンポーネントを組み合わせることで、セキュア ブート証明書と Windows ブート マネージャーが、制御された順序指定された方法で、前提条件の手順が成功した後にのみ更新されます。
トラブルシューティング時にまず確認する場所
デバイスがセキュア ブート証明書の更新プログラムの適用で期待通りの進行状況を上げていないように見える場合は、まず問題のカテゴリを特定します。 ほとんどの問題は、Windows のサービス状態、セキュア ブート更新メカニズム、ファームウェアの動作、プラットフォームまたは OEM の制限の 4 つの領域のいずれかに分類されます。
以下のチェックから順番に始めます。 多くの場合、これらの手順は、確認された動作を説明し、詳細な調査を行わなくても次のアクションを決定するのに十分です。
Windows サービスとプラットフォームの適格性を確認する
- デバイスがセキュア ブート証明書の更新プログラムを受信するための基本要件を満たしていることを確認します。
- デバイスは、サポートされているバージョンの Windows を実行しています。
- 最新の必要な Windows セキュリティ更新プログラムがインストールされている。
- セキュア ブートは UEFI ファームウェアで有効になっています。
- これらの条件のいずれかが満たされていない場合は、トラブルシューティングを続行する前に対処します。
-
- セキュア ブート証明書の更新プログラムの適用を担当する Windows メカニズムが存在し、機能していることを確認します。
- セキュア ブート更新のスケジュールされたタスクが存在します。
- タスクは有効になり、ローカル システムとして実行されます。
- 最新の Windows セキュリティ更新プログラムがインストールされてから、タスクは少なくとも 1 回実行されています。
- タスクが無効、削除、または実行されていない場合、セキュア ブート証明書の更新を適用できません。 トラブルシューティングは、他の原因を調査する前に、タスクを復元することに重点を置く必要があります。
レジストリ設定で予想される進行状況を確認する
レジストリでデバイスのセキュア ブート サービス状態を確認します。- UEFICA2023Status、UEFICA2023Error、UEFICA2023ErrorEvent を調べます。
- AvailableUpdates を調べ、予想される進行状況と比較します (「参照と内部」を参照)。
これらの値を組み合わせて、サービスが正常に進行しているか、操作を再試行しているか、または特定の手順で停止しているかを示します。
レジストリの状態をセキュア ブート イベントと関連付ける
システム イベント ログでセキュア ブート関連のイベントを確認し、レジストリの状態と関連付けます。 通常、イベント データは、デバイスが進行中であるか、一時的な状態のために再試行しているか、ファームウェアやプラットフォームの問題によってブロックされているかを確認します。
レジストリ ログとイベント ログは、通常、その動作が予期されたものか、一時的なものか、それとも修正アクションが必要かを示します。
セキュア ブート更新のスケジュールされたタスク
セキュア ブート証明書サービスは、 Secure-Boot-Update という名前の Windows のスケジュールされたタスクを通じて実装されます。 タスクは次のパスに登録されます。
注
\Microsoft\Windows\PI\Secure-Boot-Update
タスクはローカル システムとして実行されます。 既定では、システムの起動時と、その後 12 時間ごとに実行されます。 実行されるたびに、セキュア ブート更新アクションが保留中であるかどうかを確認し、順番に適用しようとします。
このタスクが無効になっているか見つからない場合は、セキュア ブート証明書の更新プログラムを適用できません。 セキュア ブート サービスが機能するには、セキュア ブート更新タスクを有効にしたままにする必要があります。
スケジュールされたタスクが使用される理由
セキュア ブート証明書の更新には、セキュア ブート キーと証明書を格納する UEFI 変数の記述など、Windows と UEFI ファームウェア間の調整が必要です。 スケジュールされたタスクを使用すると、システムがファームウェア変数を変更できる状態のときに、これらの更新プログラムを Windows で試行できます。
12 時間の定期的なスケジュールでは、前回の試行が失敗した場合、または再起動せずにデバイスの電源がオンのままの場合に、更新を再試行する追加の機会が提供されます。 この設計により、手動介入を必要とせずに確実に前進することができます。
AvailableUpdates レジストリ ビットマスク
Secure-Boot-Update タスクは、 AvailableUpdates レジストリ値によって駆動されます。 この値は、次の場所にある 32 ビット ビットマスクです。
注
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
値の各ビットは、特定のセキュア ブート更新操作を表します。 更新プロセスは、 AvailableUpdates が 0 以外の値に設定されている場合に開始されます。これは、Windows によって自動的に、または管理者によって明示的に設定されたことです。 たとえば、 0x5944 などの値は、複数の更新操作が保留中であることを示します。
セキュア ブート更新タスクが実行されると、設定されたビットが保留中の作業として解釈され、定義された順序で処理されます。
シーケンシャル更新、ログ記録、再試行の動作
セキュア ブート証明書の更新プログラムは、固定順序で適用されます。 各更新操作は、個別に再試行および完了するために設計されています。 Secure-Boot-Update タスクは、現在の操作が成功し、対応するビットが AvailableUpdates からクリアされるまで、次の手順 に進みません。
各操作では、標準の UEFI インターフェイスを使用して、DB や KEK などのセキュア ブート変数を更新するか、更新された Windows ブート マネージャーをインストールします。 Windows は、すべての手順の結果をシステム イベント ログに記録します。 成功イベントは前方の進行状況を確認し、失敗イベントはアクションを完了できなかった理由を示します。
更新ステップが失敗した場合、タスクは処理を停止し、エラーをログに記録し、関連付けられたビット セットを残します。 次回タスクが実行されるときに、操作が再試行されます。 この再試行動作により、デバイスはファームウェアのサポートがない、OEM の更新プログラムが遅れているなど、一時的な状態から自動的に回復できます。
管理者は、レジストリの状態をイベント ログ エントリと関連付けることで進行状況を追跡できます。 UEFICA2023Status、UEFICA2023Error、UEFICA2023ErrorEvent などのレジストリ値は、AvailableUpdates ビットマスクと共に、どの手順がアクティブか、完了済みか、またはブロックされているかを示します。
この組み合わせは、デバイスが正常に進行しているか、操作を再試行しているか、またはストールしているかを示します。
OEM ファームウェアとの統合
セキュア ブート証明書の更新は、デバイスの UEFI ファームウェアでの正しい動作とサポートに依存します。 Windows が更新プロセスを調整している間、ファームウェアはセキュア ブート ポリシーを適用し、セキュア ブート データベースを維持する役割を担います。
OEM は、セキュア ブート証明書サービスを有効にする 2 つの重要な要素を提供します。
- 新しいセキュア ブート証明書のインストールを承認するプラットフォーム キーで署名されたキー交換キー (KEK)。
- 更新中にセキュア ブート データベースを正しく保持、追加、検証するファームウェア実装。
ファームウェアがこれらの動作を完全にサポートしていない場合、セキュア ブート更新プログラムが停止したり、無期限に再試行したり、ブート エラーが発生する可能性があります。 このような場合、Windows はファームウェアを変更しないと更新を完了できません。
Microsoft は OEM と協力してファームウェアの問題を特定し、修正された更新プログラムを利用できるようにします。 トラブルシューティングでファームウェアの制限または欠陥が示された場合、管理者はセキュア ブート証明書の更新が正常に完了する前に、デバイスの製造元から提供された最新の UEFI ファームウェア更新プログラムをインストールする必要がある場合があります。
一般的なエラー シナリオと解決策
セキュア ブート更新プログラムは、 AvailableUpdates レジストリの状態に基づいて、スケジュールされた Secure-Boot-Update タスクによって適用されます。
通常の状況では、これらの手順は自動的に実行され、各ステージが完了すると成功イベントを記録します。 場合によっては、ファームウェアの動作、プラットフォームの構成、またはサービスの前提条件によって進行状況が妨げられたり、予期しないブート動作が発生したりする可能性があります。
以下のセクションでは、最も一般的な障害シナリオ、それらの認識方法、障害が発生する理由、および通常の操作を復元するための適切な次の手順について説明します。 シナリオは、最も一般的に発生するケースから、ブートに影響を与えるより深刻なケースまで並べられています。
セキュア ブート更新プログラムが適用されない (進行状況なし)
セキュア ブート更新が進行状況を示しない場合は、通常、更新プロセスが開始されていないことを意味します。 その結果、更新メカニズムがトリガーされなかったため、予期されるセキュア ブート レジストリ値とイベント ログが失われます。
何が起こったのでしょうか
セキュア ブート更新プロセスが開始されなかったため、セキュア ブート証明書または更新されたブート マネージャーがデバイスに適用されませんでした。
見分け方
- UEFICA2023Status などのセキュア ブート サービス レジストリ値が存在しません。
- 予期されるセキュア ブート イベント (1043、1044、1045、1799、1801 など) がシステム イベント ログに表示されません。
- デバイスは、古いセキュア ブート証明書とブート コンポーネントを引き続き使用します。
問題の原因
このシナリオは通常、次の条件の 1 つ以上に当てはまる場合に発生します。
- セキュア ブート更新のスケジュールされたタスクが無効であるか、見つからない。
- UEFI ファームウェアではセキュア ブートが無効になっています。
- デバイスが、サポートされている Windows バージョンの実行や必要な更新プログラムのインストールなど、Windows サービスの前提条件を満たしていません。
次に実行する操作
- デバイスが Windows サービスとプラットフォームの適格性要件を満たしていることを確認します。
- ファームウェアでセキュア ブートが有効になっていることを確認します。
- SecureBootUpdate のスケジュールされたタスクが存在し、有効になっていることを確認します。
スケジュールされたタスクが無効になっているか見つからない場合は、「 セキュア ブートのスケジュールされたタスクが無効または削除 されている」のガイダンスに従って復元します。 タスクが復元されたら、デバイスを再起動するか、タスクを手動で実行してセキュア ブート サービスを開始します。
セキュア ブート更新後、デバイスが BitLocker 回復を起動する
場合によっては、セキュア ブート関連の更新プログラムによって、デバイスが BitLocker 回復に入ることがあります。 この動作は、根本的な原因に応じて、一時的または永続的な場合があります。
シナリオ 1: セキュア ブート更新後の 1 回限りの BitLocker 回復
処理
デバイスは、セキュア ブート更新後の初回起動時に BitLocker 回復に入りますが、後続の再起動では正常に起動します。
問題の原因
更新後の最初の起動時には、Windows が BitLocker の再シールを試みるときに、ファームウェアは更新されたセキュア ブート値をまだ報告しません。 これにより、測定されたブート値に一時的な不一致が発生し、回復がトリガーされます。 次回の起動時に、ファームウェアは更新された値を正しく報告し、BitLocker は正常に再シールされ、問題は再発しません。
見分け方
- BitLocker 回復は 1 回行われます。
- 回復キーを入力した後、それ以降の起動で回復が求められません。
- 進行中のブート オーダーまたは PXE の関与が存在しない。
次に実行する操作
- BitLocker 回復キーを入力して Windows を再開します。
- ファームウェアの更新を確認します。
シナリオ 2: PXE 初回ブート構成による BitLocker 回復の繰り返し
処理
デバイスは起動のたびに BitLocker 回復に入ります。
問題の原因
デバイスは、 最初に PXE (ネットワーク) ブートを試行するように構成されています。 PXE ブート試行が失敗し、ファームウェアがディスク上の Windows ブート マネージャーにフォールバックします。
この結果、 単一のブート サイクルで 2 つの異なる署名機関が測定されます。
- 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 更新プログラムがインストールされている 2 台目の Windows PC で、C:\Windows\Boot\EFI\ から SecureBootRecovery.efi をコピーします。
- FAT32 フォーマットの USB ドライブ上の \EFI\BOOT\ にファイルを置き、bootx64.efi に名前を変更します。
- 影響を受けるデバイスを USB ドライブから起動し、回復ユーティリティの実行を許可します。 このユーティリティは、Windows UEFI CA 2023 を DB に追加します。
証明書が復元され、システムが再起動すると、Windows は正常に起動します。
重要: このプロセスでは、新しい証明書の 1 つのみが再適用されます。 デバイスが回復されたら、最新の証明書が再適用されていることを確認し、システムの BIOS/UEFI を利用可能な最新バージョンに更新することを検討してください。 多くの OEM がこの特定の問題に対するファームウェア修正プログラムをリリースしているため、これはセキュア ブート リセットの問題の再発を防ぐのに役立ちます。
ファームウェアによる DB の上書きが原因で、セキュア ブートの更新後にデバイスが起動に失敗する
何が起こったのでしょうか
セキュア ブート証明書の更新を適用して再起動すると、デバイスは起動に失敗し、Windows に到達しません。
見分け方
- セキュア ブート更新プログラムで必要な再起動の直後にデバイスが失敗します。
- ファームウェアまたはセキュア ブート エラーが表示されるか、Windows が読み込まれる前にシステムが停止する場合があります。
- セキュア ブートを無効にすると、デバイスの起動が許可される場合があります。
問題の原因
この問題は、デバイスの UEFI ファームウェア実装の欠陥が原因である可能性があります。
Windows がセキュア ブート証明書の更新プログラムを適用すると、ファームウェアは既存のセキュア ブート許可署名データベース (DB) に新しい証明書 を追加する ことが期待されます。 一部のファームウェア実装では、DB に追加するのではなく、誤って上 書き されます。
これが発生すると、
- Microsoft 2011 ブートローダー証明書など、以前は信頼されていた証明書は削除されます。
- その時点でシステムが 2011 証明書で署名されたブート マネージャーをまだ使用している場合、ファームウェアはそれを信頼しなくなります。
- ファームウェアはブート マネージャーを拒否し、ブート プロセスをブロックします。
場合によっては、DB が正常に上書きされずに破損し、同じ結果になることがあります。 この動作は特定のファームウェア実装で確認されており、準拠しているファームウェアでは想定されていません。
次に実行する操作
- ファームウェアのセットアップ メニューに入り、セキュア ブート設定のリセットを試行します。
- リセット後にデバイスが起動する場合は、デバイスの製造元のサポート サイトで、セキュア ブート DB の処理を修正するファームウェアの更新プログラムをチェックします。
- ファームウェアの更新プログラムが利用可能な場合は、セキュア ブートを再度有効にし、セキュア ブート証明書の更新プログラムを再適用する前に、ファームウェアの更新プログラムをインストールします。
セキュア ブートをリセットしてもブート機能が復元されない場合、さらなる回復には OEM 固有のガイダンスが必要になる可能性があります。
OEM 署名 KEK がないため、セキュア ブート更新プログラムがブロックされる
何が起こったのでしょうか
セキュア ブート証明書の更新は完了せず、キー交換キー (KEK) の更新段階でブロックされたままになります。
見分け方
- AvailableUpdates レジストリ値は KEK ビット (0x0004) に設定されたままになり、クリアされません。
- UEFICA2023Status が完了状態に進まない。
- システム イベント ログにイベント ID 1803 が繰り返し記録され、KEK 更新プログラムを適用できなかったことを示します。
- デバイスは先に進まずに更新の再試行を続行します。
問題の原因
セキュア ブート KEK を更新するには、OEM が所有するデバイスの プラットフォーム キー (PK) からの承認が必要です。
更新プログラムを正常に行うには、デバイスの製造元は、その特定のプラットフォーム用の PK 署名付き KEK を Microsoft に提供する必要があります。 この OEM 署名付き KEK は Windows 更新プログラムに含まれており、Windows でファームウェアの KEK 変数を更新できるようにします。
OEM がデバイスの PK 署名済み KEK を提供していない場合、Windows は KEK 更新を完了できません。 この状態の場合:
- セキュア ブート更新プログラムは、仕様によりブロックされています。
- Windows では、承認が欠落している問題を回避できません。
- デバイスはセキュア ブート証明書のサービスを完了できなくなる可能性があります。
これは、OEM がファームウェアまたはキーの更新プログラムを提供しなくなった古いデバイスまたはサポート対象外のデバイスで発生する可能性があります。 この状態に対してサポートされている手動回復パスはありません。
セキュア ブート証明書の更新イベントと失敗インジケーター
セキュア ブート証明書の更新の適用に失敗した場合、Windows は進行状況がブロックされた理由を説明する診断イベントを記録します。 これらのイベントは、ファームウェア、プラットフォームの状態、または構成条件により、セキュア ブート署名データベース (DB) またはキー交換キー (KEK) の更新を安全に完了できない場合に書き込まれます。 このセクションのシナリオでは、これらのイベントを参照して一般的なエラー パターンを特定し、適切な修復を決定します。 このセクションは、前に説明した問題の診断と解釈をサポートすることを目的としており、新しい障害シナリオを導入するものではありません。
イベント ID、説明、エントリ例の完全な一覧については、「 セキュア ブート DB および DBX 変数更新イベント (KB5016061)」を参照してください。
KEK 更新の失敗 (DB 更新は成功、KEK は成功しない)
デバイスはセキュア ブート DB 内の証明書を正常に更新できますが、KEK 更新中に失敗します。 この場合、セキュア ブート更新プロセスを完了できません。
現象
- DB 証明書イベントは進行状況を示しているが、KEK ステージは完了していない。
- AvailableUpdates は 0x4004 に設定されたままであり、複数のタスクを実行した後、0x0004 ビットはクリアされません。
- イベント 1795 または 1803 が存在する可能性があります。
解釈
- 通常、1795 は、セキュア ブート変数を更新しようとしたときにファームウェアが失敗したことを示します。
- 1803 は、必要な OEM PK 署名済み KEK ペイロードをプラットフォームで使用できないため、KEK 更新プログラムを承認できないことを示します。
次のステップ
- 1795 の場合は、OEM ファームウェアの更新プログラムをチェックし、セキュア ブート変数の更新プログラムに対するファームウェアのサポートを検証します。
- 1803 の場合は、デバイス モデルに必要な PK 署名付き KEK が OEM から Microsoft に提供されているかどうかを確認します。
Hyper-V でホストされているゲスト VM での KEK 更新エラー
Hyper-V 仮想マシンでは、セキュア ブート証明書を更新するには、 Hyper-V ホストとゲスト OS の両方に 2026 年 3 月の Windows 更新プログラムをインストールする必要があります。
更新エラーは ゲスト内から報告されますが、イベントは修復が必要な場所を示します。
- ゲストで報告されたイベント 1795 (たとえば、「メディアは書き込み保護されています」) は、Hyper-V ホストに 2026 年 3 月の更新プログラムが存在しないため、更新する必要があることを示します。
- ゲストで報告されたイベント 1803 は、ゲスト仮想マシン自体に 2026 年 3 月の更新プログラムが存在しないため、更新する必要があることを示します。
参照と内部
このセクションには、トラブルシューティングとサポートを目的とした高度なリファレンス情報が含まれています。 展開計画用ではありません。 前に要約したセキュア ブートのサービス メカニクスを拡張し、レジストリの状態とイベント ログを解釈するための詳細なリファレンス資料を提供します。
注 (IT 管理の展開): グループ ポリシーまたは Microsoft Intune を使用して構成する場合、2 つの類似した設定を混同しないでください。 AvailableUpdatesPolicy 値は、構成されているポリシーの状態を表します。 一方、 AvailableUpdates は、進行中のビット クリア処理の作業状態を反映します。 どちらも同じ結果をもたらす可能性がありますが、ポリシーは時間の経過とともに再適用されるため、動作が異なります。
証明書サービスに使用される AvailableUpdates ビット
以下のビットは、このドキュメントで説明されている証明書とブート マネージャーの操作に使用されます。 [ 順序] 列には、セキュア ブート更新タスクが各ビットを処理するシーケンスが反映されています。
| 受注 | ビット設定 | 使用状況 |
|---|---|---|
| 1 | 0x0040 | このビットは、Windows UEFI CA 2023 証明書をセキュア ブート DB に追加するようにスケジュールされたタスクに指示します。 これにより、Windows は、この証明書によって署名されたブート マネージャーを信頼できます。 |
| 2 | 0x0800 | このビットは、スケジュールされたタスクに、Microsoft オプション ROM UEFI CA 2023 を DB に適用するように指示します。 条件付き動作: 0x4000フラグが設定されている場合、スケジュールされたタスクは、最初に Microsoft Corporation UEFI CA 2011 証明書のデータベースをチェックします。 2011 証明書が存在する場合にのみ、Microsoft オプション ROM UEFI CA 2023 証明書が適用されます。 |
| 3 | 0x1000 | このビットは、 Microsoft UEFI CA 2023 を DB に適用するようにスケジュールされたタスクに指示します。 条件付き動作: 0x4000フラグが設定されている場合、スケジュールされたタスクは、最初に Microsoft Corporation UEFI CA 2011 証明書のデータベースをチェックします。 2011 証明書が存在する場合にのみ、Microsoft UEFI CA 2023 証明書が適用されます。 |
| 修飾子 (動作フラグ) | 0x4000 | このビットは、0x0800 ビットと 0x1000 ビットの動作を変更し、DB に 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 Production PCA 2011 署名付きブート マネージャーが置き換えられます。 |
注:
- 0x4000 ビットは、他のすべてのビットが処理された後も設定されたままになります。
- 各ビットは、上記の順序で Secure-Boot-Update スケジュールされたタスクによって処理されます。
- PK 署名済み KEK がないために0x0004ビットを処理できない場合でも、スケジュールされたタスクは、ビット 0x0100 で示されるブート マネージャーの更新を適用します。
予想される進行状況 (AvailableUpdates)
操作が正常に完了すると、Windows は関連するビットを AvailableUpdates からクリアします。 操作に失敗した場合、Windows はイベントをログに記録し、タスクが再実行されたときに再試行します。
次の表は、各セキュア ブート更新操作が完了するときの AvailableUpdates 値の予想される進行状況を示しています。
| しきい値 | 処理ビット | Available Updates | 説明 | ログに記録された成功イベント | 考えられるエラー イベント コード |
|---|---|---|---|---|---|
| スタート | 0x5944 | セキュア ブート証明書サービスが開始される前の初期状態。 | - | - | |
| 1 | 0x0040 | 0x5944 → 0x5904 | Windows UEFI CA 2023 がセキュア ブート DB に追加されます。 | 1036 | 1032, 1795, 1796, 1802 |
| 2 | 0x0800 | 0x5904 → 0x5104 | デバイスが以前に Microsoft UEFI CA 2011 を信頼していた場合は、Microsoft オプション ROM UEFI CA 2023 を DB に追加します。 | 1044 | 1032, 1795, 1796, 1802 |
| 3 | 0x1000 | 0x5104 → 0x4104 | デバイスが以前に Microsoft UEFI CA 2011 を信頼していた場合、Microsoft UEFI CA 2023 が DB に追加されます。 | 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 がセキュア ブート証明書の更新プログラムを適用するには、セ キュア ブート更新 のスケジュールされたタスクが必要です。 タスクが無効になっているか見つからない場合、セキュア ブート証明書のサービスは進行しません。
タスクの詳細
| タスク名 | セキュア ブート更新 |
|---|---|
| タスク パス | \Microsoft\Windows\PI\ |
| 完全パス | \Microsoft\Windows\PI\Secure-Boot-Update |
| 次として実行 | 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 -quiet
ガイダンスの実行
- アクセスが拒否されたと表示される場合は、管理者として PowerShell を再実行します。
- 実行ポリシーが原因でスクリプトが実行されない場合は、プロセス スコープ バイパスを使用します。
注
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass