トラブルシューティング
適用先
元の発行日: 2026 年 3 月 19 日
KB ID: 5085046
この記事の内容
概要
このページでは、Windows デバイスでのセキュア ブート関連の問題の診断と解決に関する管理者とサポート の専門家をガイドします。 トピックには、セキュア ブート証明書の更新エラー、正しくないセキュア ブートの状態、予期しない BitLocker 回復プロンプト、セキュア ブート構成の変更後のブート エラーが含まれます。
このガイダンスでは、Windows のサービスと構成を確認し、関連するレジストリ値とイベント ログを確認し、ファームウェアまたはプラットフォームの制限に OEM 更新が必要なタイミングを特定する方法について説明します。 このコンテンツは、既存のデバイスの問題を診断するためのものです。 これは、新しいデプロイを計画するためのものです。 このドキュメントは、新しいトラブルシューティング シナリオとガイダンスが特定されると更新されます。
セキュア ブート証明書サービスのしくみ
Windows でのセキュア ブート証明書サービスは、オペレーティング システムとデバイスの UEFI ファームウェアの間で調整されたプロセスです。 目標は、各ステージで起動する機能を維持しながら、重要なトラスト アンカーを更新することです。
このプロセスは、Windows のスケジュールされたタスク、レジストリ ベースの更新アクションのシーケンス、組み込みのログと再試行の動作によって実行されます。 これらのコンポーネントを組み合わせることで、セキュア ブート証明書と Windows ブート マネージャーが、管理された順序付けされた方法で更新され、前提条件の手順が成功した後にのみ更新されます。
トラブルシューティングを開始する場所
デバイスがセキュア ブート証明書の更新プログラムの適用に期待される進行状況を示していないように見える場合は、まず問題のカテゴリを特定します。 ほとんどの問題は、Windows サービスの状態、セキュア ブートの更新メカニズム、ファームウェアの動作、またはプラットフォームまたは OEM の制限の 4 つの領域のいずれかに分類されます。
次のチェックから順番に開始します。 多くの場合、これらの手順は、観察された動作を説明し、より深い調査なしで次のアクションを決定するのに十分です。
-
Windows サービスとプラットフォームの適格性を確認する
-
デバイスがセキュア ブート証明書の更新プログラムを受け取る基本的な要件を満たしていることを確認します。
-
デバイスでサポートされているバージョンの Windows が実行されています。
-
必要な最新の Windows セキュリティ更新プログラムがインストールされています。
-
セキュア ブートは UEFI ファームウェアで有効になっています。
-
これらの条件のいずれかが満たされていない場合は、さらにトラブルシューティングを続行する前に対処してください。
-
-
Secure-Boot-Update タスクの状態を確認 する
-
セキュア ブート証明書の更新プログラムを適用する Windows メカニズムが存在し、機能していることを確認します。
-
Secure-Boot-Update スケジュールされたタスクが存在します。
-
タスクが有効になり、ローカル システムとして実行されます。
-
このタスクは、最新の Windows セキュリティ更新プログラムがインストールされてから少なくとも 1 回実行されています。
-
タスクが無効、削除、または実行されていない場合は、セキュア ブート証明書の更新プログラムを適用できません。 トラブルシューティングでは、他の原因を調査する前にタスクの復元に重点を置く必要があります。
-
-
レジストリでデバイスのセキュア ブート サービスの状態を確認します。
-
UEFICA2023Status、UEFICA2023Error、および UEFICA2023ErrorEvent を調べます。
-
AvailableUpdates を調べ、予想される進行状況と比較します (「リファレンスと内部」を参照してください)。
これらの値は、サービスが正常に進行しているか、操作を再試行しているか、特定の手順でストールしているかを示します。
-
-
システム イベント ログでセキュア ブート関連のイベントを確認し、レジストリの状態に関連付けます。 通常、イベント データは、デバイスが前方に進んでいるか、一時的な状態が原因で再試行しているか、ファームウェアまたはプラットフォームの問題によってブロックされているかを確認します。
通常、レジストリとイベント ログは、動作が予期されているか、一時的か、または是正措置が必要かを示します。
Secure-Boot-Update スケジュールされたタスク
セキュア ブート証明書サービスは、 Secure-Boot-Update という名前の Windows スケジュールされたタスクを通じて実装されます。 タスクは次のパスに登録されます。
\Microsoft\Windows\PI\Secure-Boot-Update
タスクはローカル システムとして実行されます。 既定では、システムの起動時に実行され、その後 12 時間ごとに実行されます。 実行するたびに、セキュア ブート更新アクションが保留中かどうかを確認し、それらを順番に適用しようとします。
このタスクが無効または欠落している場合は、セキュア ブート証明書の更新プログラムを適用できません。 セキュア ブート サービスを機能させるには、Secure-Boot-Update タスクを有効にしたままにする必要があります。
スケジュールされたタスクが使用される理由
セキュア ブート証明書の更新には、セキュア ブート キーと証明書を格納する 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 タスクを実行すると、設定されたビットが保留中の作業として解釈され、定義された順序で処理されます。
順次更新、ログ記録、および再審の動作
セキュア ブート証明書の更新は、固定順序で適用されます。 各更新アクションは、再試行しても安全であり、個別に完了するように設計されています。 Secure-Boot-Update タスクは、現在のアクションが成功し、対応するビットが AvailableUpdates からクリアされるまで、次の手順に進むわけではありません。
各操作では、標準の UEFI インターフェイスを使用して、DB や KEK などのセキュア ブート変数を更新するか、更新された Windows ブート マネージャーをインストールします。 Windows では、すべてのステップの結果がシステム イベント ログに記録されます。 成功イベントは前方の進行状況を確認しますが、失敗イベントはアクションを完了できなかった理由を示します。
更新ステップが失敗した場合、タスクは処理を停止し、エラーをログに記録し、関連付けられているビット セットを残します。 次にタスクを実行すると、操作が再試行されます。 この再審動作により、ファームウェアのサポート不足や OEM 更新プログラムの遅延など、一時的な状態からデバイスを自動的に回復できます。
管理者は、レジストリの状態とイベント ログ エントリを関連付けることで進行状況を追跡できます。 UEFICA2023Status、UEFICA2023Error、UEFICA2023ErrorEvent などのレジストリ値と AvailableUpdates ビットマスクは、アクティブ、完了、またはブロックされているステップを示します。
この組み合わせは、デバイスが正常に進行しているか、操作を再試行しているか、またはストールしているかを示します。
OEM ファームウェアとの統合
セキュア ブート証明書の更新は、デバイスの UEFI ファームウェアでの正しい動作とサポートによって異なります。 Windows は更新プロセスを調整しますが、ファームウェアはセキュア ブート ポリシーを適用し、セキュア ブート データベースを維持する役割を担います。
OEM は、セキュア ブート証明書サービスを有効にする 2 つの重要な要素を提供します。
-
新しいセキュア ブート証明書のインストールを承認するプラットフォーム キー署名付きキー Exchange キー (KEK)。
-
更新中にセキュア ブート データベースを正しく保持、追加、検証するファームウェア実装。
ファームウェアでこれらの動作が完全にサポートされていない場合、セキュア ブートの更新がストールしたり、無期限に再試行したり、ブート エラーが発生したりする可能性があります。 このような場合、Windows はファームウェアを変更せずに更新プログラムを完了できません。
Microsoft は OEM と協力してファームウェアの問題を特定し、修正された更新プログラムを利用できるようにします。 トラブルシューティングでファームウェアの制限または欠陥が示されている場合、管理者は、セキュア ブート証明書の更新が正常に完了する前に、デバイスの製造元が提供する最新の UEFI ファームウェア更新プログラムをインストールする必要がある場合があります。
一般的な障害シナリオと解決策
セキュア ブート更新プログラムは、 AvailableUpdates レジストリの状態に基づいて、Secure-Boot-Update スケジュールされたタスクによって適用されます。
通常の状況では、これらの手順は自動的に実行され、各ステージが完了すると成功イベントが記録されます。 場合によっては、ファームウェアの動作、プラットフォームの構成、またはサービスの前提条件によって、進行状況が妨されたり、予期しない起動動作が発生したりする可能性があります。
以下のセクションでは、最も一般的な障害シナリオ、それらを認識する方法、発生した理由、および通常の操作を復元するための適切な次の手順について説明します。 シナリオは、最も一般的に発生するケースから、より深刻なブートに影響を与えるケースに順序付けられます。
セキュア ブートの更新に進行状況が表示されない場合は、通常、更新プロセスが開始されていないことを意味します。 その結果、更新メカニズムがトリガーされなかったため、予期されるセキュア ブート レジストリ値とイベント ログが見つかりません。
どうしたのですか
セキュア ブートの更新プロセスが開始されなかったため、セキュア ブート証明書や更新されたブート マネージャーがデバイスに適用されませんでした。
それを認識する方法
-
UEFICA2023Status などのセキュア ブート サービス レジストリ値は存在しません。
-
予期されるセキュア ブート イベント (1043、1044、1045、1799、1801 など) がシステム イベント ログに表示されません。
-
デバイスは、古いセキュア ブート証明書とブート コンポーネントを引き続き使用します。
発生する理由
このシナリオは、通常、次の条件の 1 つ以上が当てはまる場合に発生します。
-
Secure-Boot-Update スケジュールされたタスクが無効になっているか、存在しません。
-
セキュア ブートは UEFI ファームウェアで無効になっています。
-
サポートされている Windows バージョンの実行や必要な更新プログラムのインストールなど、デバイスが Windows サービスの前提条件を満たしていません。
次の操作
-
デバイスが Windows サービスとプラットフォームの適格性の要件を満たしていることを確認します。
-
ファームウェアでセキュア ブートが有効になっていることを確認します。
-
SecureBootUpdate スケジュールされたタスクが存在し、有効になっていることを確認します。
スケジュールされたタスクが無効または欠落している場合は、「 セキュア ブートスケジュールされたタスクが無効または削除された」 のガイダンスに従って復元します。 タスクが復元されたら、デバイスを再起動するか、タスクを手動で実行してセキュア ブート サービスを開始します。
場合によっては、セキュア ブート関連の更新によってデバイスが BitLocker 回復に入る可能性があります。 動作は、基になる原因に応じて、一時的または永続的な場合があります。
シナリオ 1: セキュア ブート更新後の 1 回限りの BitLocker 回復
何が起こるか
セキュア ブートの更新後、デバイスは最初のブートで BitLocker 回復に入りますが、以降の再起動時に通常どおりに起動します。
発生する理由
更新後の最初の起動中、Windows が BitLocker の再シールを試みると、ファームウェアで更新されたセキュア ブートの値はまだ報告されません。 これにより、測定されたブート値が一時的に一時的に一致し、復旧がトリガーされます。 次の起動時に、ファームウェアによって更新された値が正しく報告され、BitLocker が正常に再シールされ、問題が再発しません。
それを認識する方法
-
BitLocker の回復は 1 回行われます。
-
回復キーを入力した後、その後の起動では回復を求められません。
-
継続的なブート順序や PXE の関与はありません。
次の操作
-
BitLocker 回復キーを入力して Windows を再開します。
-
ファームウェアの更新プログラムを確認します。
シナリオ 2: PXE の最初のブート構成による BitLocker 回復の繰り返し
何が起こるか
デバイスは、すべてのブート時に BitLocker 回復に入ります。
発生する理由
デバイスは、 最初に PXE (ネットワーク) ブートを試行するように構成されています。 PXE ブート試行が失敗し、ファームウェアがディスク上の Windows ブート マネージャーにフォールバックします。
これにより、 1 回のブート サイクル中に 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 がこの特定の問題のファームウェア修正プログラムをリリースしたため、セキュア ブート リセットの問題の再発を防ぐのに役立ちます。
どうしたのですか
セキュア ブート証明書の更新プログラムを適用して再起動した後、デバイスは起動に失敗し、Windows に到達しません。
それを認識する方法
-
セキュア ブート更新プログラムで必要な再起動直後にデバイスが失敗します。
-
ファームウェアまたはセキュア ブート エラーが表示される場合や、Windows が読み込まれる前にシステムが停止する可能性があります。
-
セキュア ブートを無効にすると、デバイスの起動が許可される場合があります。
発生する理由
この問題は、デバイスの UEFI ファームウェア実装の欠陥が原因である可能性があります。
Windows でセキュア ブート証明書の更新プログラムが適用されると、ファームウェアは、既存の Secure Boot 許可署名データベース (DB) に新しい証明書を 追加 する必要があります。 一部のファームウェア実装では、DB に追加するのではなく、DB が誤って 上書き されます。
これが発生した場合、
-
以前に信頼されていた証明書 (Microsoft 2011 ブートローダー証明書を含む) は削除されます。
-
その時点でシステムが 2011 証明書で署名されたブート マネージャーを引き続き使用している場合、ファームウェアは信頼しなくなります。
-
ファームウェアはブート マネージャーを拒否し、ブート プロセスをブロックします。
場合によっては、DB が完全に上書きされるのではなく破損し、同じ結果が得られます。 この動作は、特定のファームウェアの実装で観察されており、準拠しているファームウェアでは想定されていません。
次の操作
-
ファームウェアのセットアップ メニューを入力し、セキュア ブート設定のリセットを試みます。
-
リセット後にデバイスが起動した場合は、セキュア ブート DB の処理を修正するファームウェア更新プログラムのデバイス製造元のサポート サイトをチェックします。
-
ファームウェア更新プログラムが利用可能な場合は、セキュア ブートを再度有効にし、セキュア ブート証明書の更新プログラムを再適用する前にインストールします。
セキュア ブートをリセットしてもブート機能が復元されない場合は、OEM 固有のガイダンスが必要な場合があります。
どうしたのですか
セキュア ブート証明書の更新が完了せず、Key Exchange Key (KEK) 更新ステージでブロックされたままです。
それを認識する方法
-
AvailableUpdates レジストリ値は KEK ビット (0x0004) で設定されたままになり、クリアされません。
-
UEFICA2023Status が完了した状態に進まない。
-
システム イベント ログは、KEK 更新プログラムを適用できなかったことを示す イベント ID 1803 を繰り返し記録します。
-
デバイスは、前方に進まずに更新を再試行し続けます。
発生する理由
セキュア ブート KEK を更新するには、OEM が所有するデバイスの プラットフォーム キー (PK) からの承認が必要です。
更新プログラムを成功させるには、デバイスの製造元は、その特定のプラットフォームの PK 署名付き KEK を Microsoft に提供する必要があります。 この OEM 署名 KEK は Windows 更新プログラムに含まれており、Windows でファームウェア KEK 変数を更新できます。
OEM がデバイスに PK 署名された KEK を提供していない場合、Windows は KEK 更新プログラムを完了できません。 この状態で:
-
セキュア ブート更新プログラムは設計によってブロックされます。
-
Windows では、不足している承認を回避できません。
-
デバイスは、セキュア ブート証明書のサービスを完全に完了できない状態を維持できます。
これは、OEM がファームウェアまたはキー更新プログラムを提供しなくなった古いデバイスまたはサポート対象外のデバイスで発生する可能性があります。 この条件に対してサポートされている手動回復パスはありません。
セキュア ブート証明書の更新プログラムの適用に失敗すると、進行状況がブロックされた理由を説明する診断イベントが Windows によって記録されます。 これらのイベントは、ファームウェア、プラットフォームの状態、または構成条件により、セキュア ブート署名データベース (DB) または Key Exchange Key (KEK) を安全に完了できない場合に書き込まれます。 このセクションのシナリオでは、これらのイベントを参照して、一般的なエラー パターンを特定し、適切な修復を決定します。 このセクションは、新しい障害シナリオを導入するのではなく、前に説明した問題の診断と解釈をサポートすることを目的としています。
イベント ID、説明、エントリ例の完全な一覧については、「 Secure Boot DB および DBX 変数更新イベント (KB5016061)」を参照してください。
KEK 更新エラー (DB の更新が成功し、KEK は成功しません)
デバイスはセキュア ブート DB の証明書を正常に更新できますが、KEK の更新中は失敗します。 この場合、セキュア ブート更新プロセスを完了できません。
現象
-
DB 証明書イベントは進行状況を示しますが、KEK ステージは完了していません。
-
AvailableUpdates は 0x4004に設定されたままであり、複数のタスクの実行後に0x0004 ビットはクリアされません。
-
イベント 1795 または 1803 が存在する可能性があります。
解釈
-
1795 は通常、セキュア ブート変数の更新中にファームウェアが失敗したことを示します。
-
1803 は、必要な OEM PK 署名 KEK ペイロードがプラットフォームで使用できないため、KEK 更新プログラムを承認できないことを示します。
次の手順
-
1795 の場合、OEM ファームウェア更新プログラムのチェックし、セキュア ブート変数更新プログラムのファームウェアサポートを検証します。
-
1803 の場合は、OEM がデバイス モデルに必要な PK 署名 KEK を 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 には 、進行中のビットクリア作業状態が反映されます。 どちらも同じ結果を引き出すことができますが、ポリシーが時間の経過と共に再適用されるため、動作が異なります。
Available証明書のサービスに使用される更新ビット
以下のビットは、このドキュメントで説明する証明書とブート マネージャーのアクションに使用されます。 Order 列には、Secure-Boot-Update タスクが各ビットを処理するシーケンスが反映されます。
|
ご注文 |
ビット設定 |
使用法 |
|---|---|---|
|
1 |
0x0040 |
このビットは、Windows UEFI CA 2023 証明書を Secure Boot DB に追加するようにスケジュールされたタスクに指示します。 これにより、Windows はこの証明書によって署名されたブート マネージャーを信頼できます。 |
|
2 |
0x0800 |
このビットは、Microsoft Option ROM UEFI CA 2023 を DB に適用するようにスケジュールされたタスクに指示します。 条件付き 動作: 0x4000 フラグが設定されている場合、スケジュールされたタスクは、最初に Microsoft Corporation UEFI CA 2011 証明書のデータベースをチェックします。 2011 証明書が存在する場合にのみ、Microsoft Option ROM UEFI CA 2023 証明書が適用されます。 |
|
3 |
0x1000 |
このビットは、Microsoft UEFI CA 2023 を DB に適用するようにスケジュールされたタスクに指示します。 条件付き動作: 0x4000 フラグが設定されている場合、スケジュールされたタスクは、最初に Microsoft Corporation UEFI CA 2011 証明書のデータベースをチェックします。 2011 証明書が存在する場合にのみ、Microsoft UEFI CA 2023 証明書が適用されます。 |
|
修飾子 (動作フラグ) |
0x4000 |
このビットは、MICROSOFT UEFI CA 2023 と Microsoft Option ROM UEFI CA 202 3 が適用されるように、DB に Microsoft Corporation UEFICA 2011が既に含まれている場合にのみ、0x0800ビットと0x1000 ビットの動作を変更します。 デバイスのセキュリティ プロファイルが同じであることを確認するために、このビットは、デバイスが Microsoft Corporation UEFI CA 2011 証明書を信頼している場合にのみ、これらの新しい証明書を適用します。 すべての Windows デバイスがこの証明書を信頼しているわけではありません。 |
|
4 |
0x0004 |
このビットは、スケジュールされたタスクに、デバイスのプラットフォーム キー (PK) によって署名されたキー Exchange キーを探すよう指示します。 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)
操作が正常に完了すると、関連するビットが AvailableUpdates からクリアされます。 操作が失敗した場合、Windows はイベントをログに記録し、タスクが再実行されたときに再試行します。
次の表は、各セキュア ブート更新アクションが完了した時点での AvailableUpdates 値の予想される進行状況を示しています。
|
手順 |
処理されたビット |
使用可能な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 Option 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 がセキュア ブート証明書の更新プログラムを適用するために必要です。 タスクが無効になっているか見つからない場合、セキュア ブート証明書のサービスは進行しません。
タスクの詳細
|
Task Name |
Secure-Boot-Update |
|
タスク パス |
\Microsoft\Windows\PI\ |
|
完全パス |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
として実行されます |
SYSTEM (ローカル システム) |
|
トリガー |
起動時と 12 時間ごと |
|
必須の状態 |
Enabled |
タスクの状態をチェックする方法
管理者特権の 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