Windows 10 22H2 に更新プログラム KB5058379 を適用した直後から、起動や再起動のたびに「TPM-WMI イベント 1796」が記録されて不安になるケースが報告されています。本記事では、イベント1796の意味、放置してよい条件、リスクの見極め方、今すぐできる安全な対処を分かりやすく整理します。
結論：多くの場合は「更新直後のSecure Boot更新の失敗ログ」で、実害がなければ慌てなくてよい
KB5058379 適用後に増えた「TPM-WMI イベント 1796」は、名前の印象ほど“TPMが壊れた”話ではないことが多いです。実態は、Windows が UEFI ファームウェア側の Secure Boot 変数（DB/DBX/KEK など）を更新しようとして失敗した、というログであるケースが典型です。
まず取るべき対応は「原因の切り分け」ではなく、「実害の有無」を確認して、リスクの高い操作を避けながら情報を揃えることです。特に、TPMの初期化（Clear TPM）や Secure Boot キーのリセットは、暗号化（BitLocker / デバイス暗号化）や起動周りのトラブルを誘発しやすいので、最後の手段に寄せるのが安全です。
- PCが普通に起動し、暗号化の回復キー要求・起動ループ・ブルースクリーン等がない → いったんは「ログ上の不具合」として様子見が現実的
- 起動ループ / 自動修復 / BitLocker回復画面が出る → 対応優先度を上げる（後述の「注意が必要なケース」へ）
- イベント1796が毎回出るが、PCの挙動に変化がない → DBX更新の再試行が続いている可能性。後続更新やBIOS更新で解消することがある
「TPM-WMI イベント 1796」とは何か：ポイントはTPMではなくSecure Boot変数
イベントビューアーでは「ソース: TPM-WMI」「イベントID: 1796」と表示されますが、Microsoft の説明では、これは Secure Boot の更新（特に DBX＝失効リスト）を適用する際に、想定外のエラーが発生したときに記録されるものです。Windows は次回以降の再起動で再度適用を試みます。
つまり、イベント1796は「Windowsが起動時のセキュリティ更新を適用しようとしてうまく書き込めなかった」ことを示すログであり、“TPMが無効化された/故障した”ことを直接示すログではありません。ログの文面に出る「Secure Boot variable」の更新先は、基本的にUEFIファームウェア側（BIOS/UEFI設定画面がある領域）です。
関連イベントもセットで見ると、状況が読みやすい
イベント1796単体だと「何がダメなのか」が分かりづらいので、同じ「TPM-WMI」ソースで周辺のイベントを併せて確認すると、危険度が判断しやすくなります。Microsoft が整理している代表的なイベントを、実務向けに表にまとめます。
| イベントID | 意味（要約） | 優先度 | 実務的アクション |
|---|---|---|---|
| 1796 | DBX更新適用中に想定外エラー。次回以降の再起動で再試行。 | 中 | 実害がなければ様子見＋後続更新適用。長期継続ならBIOS更新検討。 |
| 1795 | ファームウェアがSecure Boot変数更新でエラーを返した。 | 中〜高 | メーカーのBIOS/UEFI更新の有無を確認（可能なら更新）。 |
| 1032 | BitLocker構成が原因で、Secure Boot更新を適用すると回復が必要になる可能性。 | 高 | 回復キー確保。必要なら暗号化保護の一時停止（後述）。 |
| 1033 | 失効対象になり得る（古い）ブートローダー等を検出し、更新適用を保留。 | 中 | OS以外の起動系（デュアルブート等）や古いブートローダー更新を検討。 |
| 1034 | DBX更新が正常に適用された（成功）。 | 低 | 成功していれば、1796はその後出なくなることが多い。 |
| 1036 | DB（信頼リスト）更新が正常に適用された（成功）。 | 低 | 成功ログ。特に対応不要。 |
| 1801 | Secure Boot CA/keysの更新がまだ適用されていない可能性を示す。 | 中 | 今後の更新で改善されることも。長期継続ならメーカー/サポートへ。 |
KB5058379で何が変わった？Secure Bootに触れる更新が含まれている
KB5058379 は Windows 10 22H2 の 2025年5月の累積更新（OSビルド 19045.5854）です。内容の中に、Secure Boot Advanced Targeting（SBAT）や Linux EFI に関する改善が含まれており、Secure Boot周辺に手が入った更新であることが読み取れます。
また、KB5058379 自体には別件として「特定条件でBitLocker回復画面に入る既知の問題」が記載されており、これは 2025年5月19日の更新（KB5061768）以降で解決した、と公式に案内されています。
ここで重要なのは、あなたが困っているのは “BitLocker回復ループ” ではなく “イベント1796が記録され続ける” という現象だとしても、KB5058379は起動・セキュリティ（Secure Boot/TPM）周辺に影響しやすい更新だった点です。更新直後に複数台で同じイベントが出始めたなら、ローカル設定や単体故障よりも「更新をトリガーにした症状」の可能性が上がります。
今回の話に関係しやすいKBを整理
| KB | 位置づけ | 代表的なOSビルド | 補足 |
|---|---|---|---|
| KB5058379 | 2025年5月の累積更新 | 19045.5854 | SBAT/EFI周りの改善が含まれる。BitLocker回復の既知問題も記載あり。 |
| KB5061768 | 2025年5月のOOB更新（緊急） | 19045.5856 | KB5058379絡みのBitLocker回復問題の解決として案内。 |
| KB5060533 | 2025年6月の累積更新 | 19045.5965 | 累積更新のためKB5058379を内包。イベント1796が改善しない報告もある。 |
なぜ「起動のたび」に出るのか：ありがちな3パターン
パターンA：DBX更新の適用が失敗し、Windowsが毎回再試行している
イベント1796の説明そのものが「次回の再起動で再度適用を試みる」なので、失敗が継続している間は起動のたびに記録されることがあります。
パターンB：UEFIファームウェア側が更新を書き込めない（相性・制限・バグ）
Secure Boot変数はUEFIが管理する領域のため、ファームウェア側の実装や保護状態によっては、OS側が更新しようとしても拒否されることがあります。イベント1796に「Access is denied（アクセス拒否）」などが出るケースは、この線が濃くなります（Microsoft Q&Aでも同様の文言報告があります）。
パターンC：暗号化（BitLocker/デバイス暗号化）や起動構成が絡んで更新が“安全側に倒れて止まる”
BitLockerの構成によっては「適用すると回復キーが必要になり得る」ため、更新を見合わせるケースがあり、その場合は別イベント（1032など）でヒントが出ます。あなたのログが1796だけでも、周辺イベントとして1032/1033が出ていないかは確認する価値があります。
最初にやるべき「被害確認」：放置していいケース／急いで対処すべきケース
イベントビューアーの「エラー」表示は心理的に強いですが、実務的には次のように線引きすると無駄な作業を減らせます。
| 状況 | 具体例 | おすすめの初動 |
|---|---|---|
| 実害なし（ログのみ） | 起動・再起動は問題なし／普段の操作で不具合なし／暗号化回復画面なし | 様子見＋後続更新の適用。念のためバックアップ継続。 |
| 要注意（軽い実害） | 起動が遅い／更新後に一時的な不安定さ／関連イベント（1795/1801/1032）が増える | BIOS更新の有無確認、暗号化状態の確認、ログ採取。 |
| 危険（実害あり） | 自動修復ループ／BitLocker回復画面が毎回出る／再起動が増える／ブルースクリーン | 業務PCなら情シス・Microsoftサポートへ。必要なら既知問題の回避策/OOB更新を検討。 |
今すぐできる安全な対処手順（Windows側で完結）
手順1：Secure Boot と TPM の状態を「Windows側で」確認する
まずは、BIOS画面ではなく Windows 側の表示も含めて整合性を取ります。以下は“確認”なので、安全です。
- システム情報（msinfo32）：
「BIOS モード」「セキュア ブートの状態」を確認 - TPM管理（tpm.msc）：
「TPMは使用可能です」「仕様バージョン 2.0」などを確認 - PowerShell（管理者）：
TPMとSecure Bootの状態を確認
Get-Tpm
Confirm-SecureBootUEFI※Confirm-SecureBootUEFI は環境によってはエラーになることがあります（UEFIでない/権限不足など）。その場合でも、msinfo32 の表示を優先してください。
手順2：イベント1796の「エラーコード」を控えて、傾向を見る
イベント1796は「想定外エラー」なので、エラーコード（HResultなど）が重要です。イベントビューアーで該当イベントを開き、メッセージに出るコードを控えてください（例：Access is denied、0x800700c1 等）。Microsoft側に報告する場合も、このコードがあると話が進みやすいです。
もし「10進数のマイナス値」で表示されているなら、16進に直すと検索しやすくなります。PowerShell で変換する例です。
$h = -2147020471
"{0:X8}" -f ([uint32]$h)手順3：「同じTPM-WMI」ソースの周辺イベントを確認する
前述の表のとおり、1032/1033/1795/1801 などが出ていないかを確認します。特に 1032（BitLocker構成で適用すると回復になる可能性） が出ている場合は、回復キー絡みの対処が優先です。
手順4：Windows Updateは「最新を適用」し、改善するかを観察する
KB5058379 のような累積更新由来の不具合は、後続の累積更新で静かに改善することがあります。一方で、ユーザー報告では KB5060533 適用後もイベント1796が続くケースがあるため、短期で消えないこともあります。
ここで大切なのは、「イベントを消すために更新を止める」より、「更新は適用しつつ、実害がないか監視する」という運用です。Secure Boot/DBX の更新はセキュリティに関わるため、安易な更新停止はおすすめしません。
暗号化（BitLocker/デバイス暗号化）を使っている場合の注意点
イベント1796の直接原因が暗号化とは限りませんが、Secure Boot周辺の更新は暗号化と“連鎖”しやすい領域です。特に「デバイス暗号化」が自動で有効になっているWindows 10 Home環境は、本人が気づきにくい点が要注意です。
- 回復キーが必要になったときに備えて、回復キーの所在を確認しておく（Microsoft アカウントに保存されているケースが多い）
- もし企業管理PCなら、情シスに回復キーの保管場所・運用ルールを確認
なお、Microsoft は Secure Boot 更新と BitLocker 構成の相性が問題になるケース（イベント1032）について、回復回避のための扱いを説明しています。該当する場合は「暗号化保護の一時停止（再起動回数つき）」が案内されることがあります。
manage-bde -protectors -disable C: -RebootCount 2注意：これは環境によっては使えない/推奨されない場合があります。暗号化の状態や企業ポリシーによって影響が大きいので、「イベント1032が出ている」「回復画面に入る」など明確な根拠があるときに、管理者の判断で実施してください。
BIOS/UEFIで「触るべきこと」と「触らない方がいいこと」
触る価値がある：メーカー提供のBIOS/UEFI更新（公式手順に限る）
イベント1796/1795は、最終的にはファームウェア側の挙動が絡むため、メーカーがSecure Boot/UEFI更新を含むBIOSアップデートを提供しているなら適用で改善する可能性があります。特に同型機で再現している場合、「Windows更新＋その時点のBIOS」の組み合わせ問題のことがあるためです。
- メーカー公式のサポートページで「機種型番に一致するBIOS」を確認
- 適用はAC電源接続、手順通りに実施
- 不安なら“更新前の状態（BIOSバージョン等）”を控える
基本は触らない：TPMの初期化（Clear TPM）／Secure Bootキーのリセット／設定の頻繁なON/OFF
Microsoft Q&Aの回答例でも「TPMの初期化」や「Secure Bootの切り替え」が提案されがちですが、これらは暗号化の回復キー要求や起動トラブルの引き金になることがあります。特に、現状で起動や普段の操作が正常なら、むやみに触るメリットが小さいです。
どうしても実施するなら、最低限次を守ってください。
- 回復キー（BitLocker/デバイス暗号化）が取得できる状態で行う
- 実施前に重要データのバックアップを取る
- 「何を、いつ、どう変えたか」をメモして戻せるようにする
「Microsoft側の問題なのか？」への答え：OS更新が引き金になっている可能性が高いが、ファームウェア相性の可能性も残る
質問のケース（Windows 10 Home 22H2、KB5058379適用直後から、複数台で同様に再現、BIOS設定は正常、KB5060533でも継続）という条件だと、単体のハード故障や偶発的な設定ミスよりも、更新を契機に発生した症状と見るのが自然です。Microsoft Q&Aでも、HP OMEN / HP ENVY で同様のタイミングに発生した報告があり、KB5060533適用後も同様のログが出たという記述があります。
一方で、イベント1796自体は「UEFIファームウェアの変数更新」が舞台なので、OS側の変更がトリガーになっても、最終的な失敗要因がファームウェア側（相性・実装）にあるケースもあります。そのため、対応としては「Microsoftに報告しつつ、メーカーBIOS更新があるなら適用を検討」が現実的な落としどころになります。
不具合報告を“通る形”にする：Microsoftに出すときの情報テンプレ
同じ症状の報告が増えるほど修正が入りやすくなるのは事実ですが、報告内容が薄いと「再現できない」で止まりがちです。次の項目を揃えておくと、後から自分で見返すときにも役立ちます。
| 項目 | 例 | どこで確認する |
|---|---|---|
| OSバージョン/ビルド | Windows 10 22H2 / 19045.5854 など | 設定 → システム → バージョン情報 |
| 適用したKB | KB5058379、KB5060533 等 | 設定 → 更新とセキュリティ → 更新履歴 |
| イベント1796の本文 | 「error Access is denied」など | イベントビューアー → システム |
| エラーコード | 0x800700c1 など | イベント詳細 |
| TPM/Secure Boot状態 | TPM 2.0、有効、Secure Boot有効 | tpm.msc / msinfo32 |
| BIOS/UEFIバージョン | メーカー/型番/バージョン | msinfo32 またはBIOS画面 |
| 暗号化の状態 | デバイス暗号化ON/OFF | 設定（検索で「デバイス暗号化」） |
Feedback Hub へは、イベントログ（該当イベントの「保存」）や msinfo32 の情報（.nfo）を添付できると強いです。企業PCなら、管理者経由で正式サポートケースにすると優先度が上がりやすくなります。
「イベントを消すためにKB5058379をアンインストール」はアリ？
結論としては、原則おすすめしません。KB5058379 はセキュリティ更新を含む累積更新で、外すと脆弱性対応が後退します。さらに、累積更新は後続KBに内包されていくため、単純に外し続ける運用は現実的ではありません。
ただし例外として、次のような「実害がある」場合は、切り戻し・OOB更新の適用・サポート問い合わせを優先してください。
- 自動修復ループやBitLocker回復画面で起動できない
- 更新インストールが失敗し続けて業務に支障がある
- 再起動やフリーズなど明確な不安定化が起きている
ちなみに KB5058379 には、特定条件で BitLocker 回復画面に入る既知問題があり、これは KB5061768（2025年5月19日）以降で解決したと案内されています。該当する症状がある場合は、この系統の“公式に認められた既知問題”として切り分けできます。
今後の見通し：後続の累積更新で改善する可能性はあるが、長期継続なら「BIOS更新＋情報共有」が現実的
イベント1796は、Microsoftの説明上「次回以降の再起動で再試行」なので、環境によっては何かのタイミングで成功（1034が出る）し、自然に収束することもあります。
一方で、KB5060533 を適用しても戻ってくるという報告があるように、短期で直らないケースもあります。こういうときは、イベントビューアーの“見た目”に引っ張られず、以下の運用が一番コストが低いです。
- PCの動作が正常なら、更新は止めずに継続適用
- 月次更新後に「1796が減った/消えたか」をチェック（ログをスクショで記録）
- メーカーBIOS更新が来たら適用を検討
- 改善しない場合は、エラーコード付きで報告を継続
Windows 10のサポート終了も踏まえた判断
Windows 10 は 2025年10月14日でサポートが終了し、以降は無償のセキュリティ更新が提供されない、と案内されています（継続利用自体は可能ですが、セキュリティ面のリスクが上がります）。
今回のような「起動とセキュリティの境界」に近い不具合は、OSの保守フェーズやサポート状況の影響を受けやすい領域です。PCがWindows 11要件を満たしているなら、不具合対応と並行して移行計画（Windows 11へのアップグレード）も検討すると、トータルのストレスが減ります。
よくある質問
イベント1796が出ると、セキュリティ的に危険ですか？
イベント1796は「Secure Bootの失効リスト（DBX）更新などが適用できていない可能性」を示すため、放置が長期化すると“本来ブロックされるべき古いブートコンポーネントをブロックできない”状態が続く可能性はあります。とはいえ、直ちに侵害されるという意味ではなく、まずは後続更新の適用とメーカーBIOS更新の確認、そして成功イベント（1034など）が出るかの監視が現実的です。
TPMを初期化（Clear TPM）すれば直りますか？
直る場合もゼロではありませんが、暗号化の回復キー要求や、サインイン・証明書周りの再設定が必要になるなど副作用が大きめです。今回の症状は「TPMの故障」ではなく「Secure Boot変数の更新失敗」であるケースが多いので、まずはログ内容（エラーコード）と周辺イベントを確認し、BIOS更新や後続累積更新で改善するかを見たうえで、最後の手段として検討するのが安全です。
BIOSで仮想化（VT-dなど）を切ると直る、と聞きました
コミュニティでは一時的に改善したという報告も見かけますが、環境依存が強く、再発する例もあります。仮想化関連設定はセキュリティ機能やHyper-V等にも影響するため、「イベントを消すためだけ」に行う操作としてはおすすめしません。まずは“実害の有無”と“エラーコード”で判断し、必要ならメーカー・Microsoftの公式な案内に沿うのが確実です。
まとめ：いま取るべき最適解は「実害確認 → 情報収集 → 更新継続 → 必要ならメーカー/Microsoftへ」
- イベント1796は、多くの場合「Secure Boot変数（DBX等）の更新失敗ログ」で、TPM故障を意味しない
- PCが正常動作しているなら、TPM初期化やSecure Bootキーリセットは急がない
- エラーコードと周辺イベント（1795/1032/1034/1801など）で状況を把握する
- 後続累積更新の適用と、メーカーBIOS更新の確認を継続する
- 報告するなら「OSビルド・KB・エラーコード・BIOS/TPM状態」をセットで出す
コメント