イベントビューアーに「エラー 1801 (TPM-WMI)」が記録される原因とMicrosoftの公式対処法

コメント一覧 （12件）

• 問題は（旧グラボの）ドライバがどの証明書を使って署名されているかわからないことだ
  NVIDIAコントロールパネル　システム情報
  ドライバーのバージョン：573.22
  ビデオBIOSのバージョン：86.07.63.00.2F
  証明書のデフォルトDBには新旧両方が存在するので（パソコンの）BIOS更新による準備は実施済みだが　アクティブDBに新しい証明書が入ってないので（NVIDIAの）ドライバの署名も旧いままと思われ（新旧両方の証明書で署名されていれば吉、だがそれを確かめるすべがない）署名に使った証明書が無効になると GOPドライバがロードされず、BIOS画面がブラックアウトして設定変更もできなくなる（大騒ぎになってからドライバ更新が提供されるに一票）
  https://www.dell.com/support/kbdoc/ja-jp/000347876/microsoft-2011%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%AE%E6%9C%89%E5%8A%B9%E6%9C%9F%E9%99%90
  https://www.dell.com/support/kbdoc/ja-jp/000385747/%E3%82%BB%E3%82%AD%E3%83%A5%E3%82%A2-%E3%83%96%E3%83%BC%E3%83%88%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
  PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match ‘Windows UEFI CA 2023’
  True
  PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match ‘Microsoft UEFI CA 2023’
  True
  PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match ‘PCA 2011’
  True
  PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match ‘UEFI CA 2011’
  True
  PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
  False
  PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Microsoft UEFI CA 2023’
  False

  返信

  • 匿名様コメントありがとうございます。

    PowerShell による検証結果と、セキュアブート証明書の現状に関する詳細な情報、非常に勉強になります。

    ご指摘の「BIOS 画面がブラックアウトして設定変更もできなくなる」という点は、まさに盲点であり、最も恐ろしいシナリオですね。 もしその状態に陥ってしまったら、解決策であるはずの「セキュアブートの無効化」すら、画面が見えないため実行不可能になってしまいます。（別のグラフィックボードを用意して換装する等の物理的な対応を迫られることになると思います）

    匿名様は「大騒ぎになってからドライバ更新が提供される」と予想されていますが、私はそれすらも厳しいのではないかと悲観視しております。 現実的に、既にサポートが終了している古いグラフィックボードに対し、メーカーがコストをかけて新しい署名の VBIOS やドライバを提供するとは考えにくいからです。

    そうなると、Microsoft が古い証明書を完全に無効化した際、古いパーツを使い続けるユーザーに残された道は「新しいPC（パーツ）に買い替える」か、手遅れになる前に予防的に「セキュアブートを無効化（OFF）しておく」か、という究極の二択になってしまいます。

    しかし、本記事内にリンクを貼っております別記事（【警鐘】PCが起動しなくなる？～）でも触れました通り、セキュアブートの無効化は「ルートキット」等のマルウェア感染リスクを招く危険な行為です。 セキュリティを高めるための更新によって、「コスト負担」か「セキュリティ低下」のどちらかを強制されるというのは、なんとも皮肉な事態です。

    匿名様の検証データのおかげで、この「詰み」のリスクがより明確になりました。 貴重な裏付けデータを共有いただき、本当にありがとうございました。

    返信

    • 返信とプロフィールを拝読して僭越ながら一言（座右の銘が泣いている）
      試行錯誤を重ねて見つけた「なるほど！」な技が「悲観視」、困った時の解決策が「詰み」のリスクを「強制される」、それらを「皆さんの PC ライフに役立ててほしい一心で発信しています。」というのはちょっと違うと思う（騒ぎましょう。求めよさらば与えられん。叩けよさらば開かれん）

      返信

      • 匿名様

        返信、そしてプロフィールまで読み込んでいただき、恐縮です。 「座右の銘が泣いている」……そのお言葉、痛いところを突かれました。

        正直なところ、いち技術屋としての冷静な目で見れば、「サポート終了＝企業のビジネス対象外」という現実の壁はあまりに分厚く、今でも「対応される可能性は極めて低い」とは思っております。 しかし、ご指摘の通り、私が試行錯誤や働きかけをする前から「どうせ無理（詰み）」と決めつけ、白旗を上げてしまっていたのは、私の掲げる「為せば成る」の精神に反しておりました。

        私たちが声を上げ続けることで、メーカーが動かずとも、Microsoft 側が何らかの「救済措置」や「猶予の延長」を検討せざるを得なくなる可能性だって、ゼロではありませんものね。
        技術的な見通しの甘さだけでなく、運営者としての姿勢まで正していただき、ありがとうございます。 いただいたご意見を参考に、今後は「ダメ元でも、まずは声を上げる」姿勢も含めて発信していきたいと思います。

        返信

• よくわからない勢なのですが、放っといて大丈夫なんですよね？

  返信

  • siden様、コメントありがとうございます。

    はい、このエラーは放っておいても問題ありません。今後、Windows Update を通じてセキュアブート証明書は更新される予定です。
    更新がされた後、イベントID 1801 は記録されなくなり、イベントID 1808 が記録されるはずです。

    返信

    • 返信ありがとうございます。
      心配してるのが、ゲーミングノートで、それに搭載されたGTX1660 Ti　でそれが影響を受けないか？ということです。BIOSは、2022年に出たものが最後ですし。

      返信

      • siden様、

        確かに、自分の PC が影響を受けないかどうかが気になりますよね。記事にセキュアブート証明書の更新順序を追記しました。
        Microsoft は、適切なタイミングで自動的に更新を開始する、つまり、レジストリ値の変更を行うはずです。レジストリ値の変更がされると、タスクが実行されるたびに記事に追記した順序で更新が進みます。
        そして、最終的には互換性の問題を回避するように設定されます。そのため、Windows 11 に対応しているデバイスであれば問題ないと思われます。

        2025/11/03 追記：【上級者向け】手動でセキュアブート証明書を即時更新する方法
        https://windows-waza.com/what-causes-error-1801-tpm-wmi-to-be-logged-in-the-event-viewer-and-how-to-fix-it-from-microsoft/#index_id5

        返信

• なんかいろいろ情報があって原因わかりにくい。
  Windows UEFI CA 2023に更新したら解決するってことですか。
  https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_mitigation_guidelines
  この辺試したらWindows UEFI CA 2023に変わりました。

  返信

  • 匿名様、

    コメント、そして非常に価値のある情報（Microsoft 公式ドキュメント）のご共有、誠にありがとうございます。

    「なんかいろいろ情報があって原因わかりにくい。」

    おっしゃる通りです。 このセキュアブートの問題は、「DB（許可リスト）」「DBX（禁止リスト）」「KEK（鍵）」など、複数のコンポーネントが関わるため、非常に分かりにくいですよね。

    「Windows UEFI CA 2023に更新したら解決するってことですか。」 「この辺試したらWindows UEFI CA 2023に変わりました。」

    はい、匿名様が実行されたその手順で解決した可能性は非常に高いです。

    ただ、この問題には少し補足が必要です。
    当サイトの記事で解説している「イベント 1801」が記録される直接的な原因は、DB（許可リスト）ではなく、DBX（禁止リスト/ブラックリスト）が古いことによるものです。

    しかし、匿名様がリンクしてくださった Microsoft の公式ページ（CVE-2023-24932）は、まさにその DBX の脆弱性に対処するための公式ガイドです。
    そのガイドに記載されている手動の緩和策（「Mitigation Guidelines」）を実行すると、DB（許可リスト）が「Windows UEFI CA 2023」に更新されると同時に、DBX（禁止リスト）も最新版に更新されるようになっています。

    結論として、 匿名様がその手順を実行されて「Windows UEFI CA 2023に変わりました」ということは、おそらく DBX も同時に最新版に更新されており、それによって「イベント 1801」の問題も解決されているのだと推測されます。
    今後、イベントID 1801 ではなく、イベントID 1808：This device has updated Secure Boot CA/keys.（このデバイスのセキュア ブート CA/キーが更新されました。） が記録されているかを確認してみてください。

    返信

    • お役に立てて何よりです。
      RufusがWindows UEFI CA 2023にできるとあったので調べたものです。
      インストール後だったので他の手段を探してました。
      https://github.com/pbatard/rufus/wiki/FAQ#how-do-i-secure-a-pc-for-the-pca-2011-windows-uefi-certificate-revocation-and-install-windows-11-25h2-on-it

      返信

      • 匿名様、

        再度のご連絡、そして情報源（Rufus の FAQ）まで教えていただき、本当にありがとうございます。

        「（Windowsを）インストール後だったので他の手段を探してました」という、そのトラブルシューティングのプロセスは非常に論理的で、素晴らしいです。
        Rufus の FAQ ページも、この問題の背景を理解する上で非常に価値のある情報源ですね。 この度は、有益な情報を重ねてご共有いただき、ありがとうございました。

        返信