【要注意】Windows 11 KB5077181適用レポート:ブラックアウトの懸念は?

KB5077181 Windows 11
KB5077181 Build 26200.7840 Ryzen CPUは要注意! Core i7は、OK
記事内に広告が含まれています。

杞憂だった

Thank you for reading this post, don't forget to subscribe!

 運命の月例アップデート(セキュリティ更新)が配信されました。
前回のパッチ(KB5074105)では、一部の環境でWindowsロゴ直後に画面が真っ暗になる「ブラックアウト」が発生し、当ブログの検証記事にも1,000PVに迫る切実なアクセスが寄せられました。(02/10時点で994PV)
「今回も固まってしまうのか?」という大きな不安の中、私のGEEKOM AE8(Ryzen 9 8945HS)で実施した実機検証の結果をご報告します。結論から言えば、今回の更新は「生還」です。

Blog更新

 しかし、その後の利用中に見せた「不穏な挙動」と、Intel機を用いた徹底比較によって、この不具合の根深い正体が浮き彫りになりました。

PR広告
PR広告

【速報】月例アップデート適用結果:AE8(Ryzen 9)の場合

KB5077181
KB5077181 Build 26200.7840
PR広告

KB5077181アップデートの主な修正点と変更点

今回のパッチ適用により、システムは以下の状態へと更新されます。

 OSビルド「26200.7840」への更新とセキュリティ強化

  • ビルド番号: 適用後、OSビルドは 26200.7840 にアップデートされます。
  • 主な修正内容: セキュリティの脆弱性修正に加え、前回のプレビュー版で露呈したTPM関連の通信不備に起因する「致命的なフリーズ」が抑制されています。(考察)
  • 次期バージョンへの基盤: バージョン 25H2 における動作安定化が図られています。

インストールプロセスの詳細:8時台の検証データ

アップデートは極めてスムーズに進行しました。具体的な時系列は以下の通りです。

  • 8:03: インストール開始。CPU負荷も安定していました。
  • 8:10: 再起動の保留状態へ。推定時間は4分と表示。
  • 8:14: 全工程完了。再起動後もデスクトップまで淀みなく進みました。
KB5077181
KB5077181 Install

【重要検証】

システムは正常に起動しましたが、内部ログを確認すると興味深い事実が判明しました。

  • ログの継続: アップデート前(7:32)とアップデート後(8:17)の両方で、依然としてTPM関連のエラーが記録されています。
  • 考察: Microsoftは「エラーそのもの」を消したのではなく、「エラーが起きてもシステムがハングアップしない(ブラックアウトさせない)」という対症療法的な修正を行ったと推測されます。
fTPM Error
fTPM Error

Blog更新

Feedback Hub
Feedback Hub

まとめ

当初は「再起動ループ」という最悪のシナリオも想定していましたが、結果的にはスムーズで、直後の再起動を除く、2度目(もろもろの作業後)の「再起動」で、「問題発生」となりました。

もし、現在もアップデートが進まないといったトラブルがある場合は、以前紹介したスタンドアロンインストーラーの活用も検討してください。

考察

筆者の独り言:エンジニアの視点から

【専門的考察】今回のアップデートが「成功」した真の理由とは?

今回の検証で最も興味深い事実は、**「エラーログ(fTPM)は出続けているのに、システムは固まらなくなった」**という点です。ここから、Microsoftが取った「回避策」の正体が見えてきます。

考察1:Microsoftが「タイムアウト判定」を緩和した可能性

フィードバックハブが依然として「調査中」であることから、fTPMの通信不備という根本的なバグ自体はまだ修正されていないと考えられます。

しかし、前回のパッチ(KB5074105)では、このエラーが発生した際にOSが「致命的な異常」と判断してフリーズさせていたのに対し、今回のKB5077181では、エラーを無視してOSの起動を続行させる(またはリトライ時間を延ばす)ような制御変更が行われた可能性があります。

考察2:前回のフリーズは「タイミングの不運」だったのか?

「たまたま重なった」という側面も否定できません。Windows Update直後の初回起動時は、ドライバーの再構成やインデックス作成などでCPUやストレージへの負荷が最大化します。

前回のパッチでは、この高負荷状態でfTPMとの通信の遅延(レイテンシ)が許容範囲を超えてしまい、結果としてブラックアウトを引き起こした。今回は、その「衝突」が起きないよう内部の優先順位が調整されたのではないかと推測します。

結論:根本治療ではなく「対症療法」による安定化

Feedback Hubが「調査中」である以上、Microsoftもまだ「完璧なパッチ」を当てたわけではありません。

現状は**「火事(エラー)は起きているが、延焼(フリーズ)しないように防火壁を作った」**という状態でしょう。AMD Ryzen環境の方は、引き続き「ログにはエラーが出るもの」と割り切りつつ、今後の根本修正(BIOS/AGESAの更新等)を待つのが正解と言えそうです。…..これは、この後すぐに判明します。

問題発生

Blog更新

問題発生!

Ryzen CPUは要注意!!!

バージョンアップ作業後、一連の作業をしていたら、ブラウザの殆どのタブがフリーズ!!!・・・生きていたのはYoutubeミュージック再生だけ。

仕方なく、「再起動」を選択したら、10分経っても、15分過ぎてもブラックアウトのまま。電源ボタンのLEDは点灯しているものの何もできない

しょうがないので、
● TB4ドッキングステーションを外して、
大事なデータは全て、TB4ドック配下m.2 SSDにある)
● サブのノートPCにTB4ドッキングステーションを接続
● メインのPCは、電源をいれたまま、接続されているのはHDMI接続のモニタとUSB接続のtrackボールだけにする。(あとLANケーブル)
● サブのノートPCを立ち上げる  ➡ 実機検証迄飛ぶには、ここをクリック

サブPCを立ち上げ「Gemini」に相談

 先程まで最新のKBを当てたPCで作業していたのですが、
BraveブラウザのセルがYoutube音楽再生を除いて、すべてフリーズしてしまいました。
リフレッシュも効きませんでした。

 そこでシャットダウンして再起動を実施したところ、
10分経ってもブラックアウトです(電源ボタンのLEDは光っています)

仕方なくHDMI接続のモニタと、LANケーブル接続、USB無線接続のトラックボールだけ残しています
(キーボードはBT接続に切り替えて、このノートPCに接続)。

 15分経った今も、ブラックアウト状態です。
TB4ドッキングステーション配下をこのPCに切り替えて投稿しています。

Blogは書き直しが必要ですが、
まずブラックアウトのPCを強制終了してみるかどうか考慮中なので、意見を求めます。

GEMINIの回答

深刻な状況ですね。まさに懸念されていた「最悪の事態」が再起動のタイミングで発生してしまったようです。

現在の状況(10分経過してもブラックアウト、LEDは点灯、周辺機器は最小限)を踏まえた、技術的な判断とアドバイスを至急お伝えします。

1. 強制終了の判断について:「実行すべき」です

10分間画面に変化がない場合、OSのロードプロセスまたはOSがハードウェア(特にGPUやTPM)の応答待ちで完全に「デッドロック(死着)」に陥っている可能性が高いです。

  • 理由: 電源LEDが点灯し、YouTubeの音だけが聞こえていた(Braveのプロセスの一部が生きていた)状態から、再起動後のブラックアウトへ移行したということは、**「ビデオドライバの初期化」または「fTPMの認証」**でハングアップしています。
  • リスク: この状態で放置しても自然復旧する確率は極めて低く、むしろ通電し続けることで熱がこもるリスクがあります。

2. 推奨される「強制終了と再起動」の手順

単に切るだけでなく、以下の手順で「放電」を伴うリセットを試みてください。

  1. 強制電源オフ: 電源ボタンを 15秒以上(長めに) 押し続けて完全にシャットダウンしてください。
  2. 完全放電: TB4ドッキングステーションを含む、本体に繋がっているすべてのケーブル(電源アダプタ、HDMI、TB4)を一度外します。
  3. 待機: そのまま 1分間放置 してください。これでマザーボード上の残留電荷を逃がします。
  4. 最小構成での起動:
    • ドッキングステーションは繋がないでください。
    • 電源アダプタと、確認用のモニタ(HDMI)1本のみを直挿しします。
  5. 起動試行: 電源を入れて、BIOSロゴ(GEEKOM等)が出るか確認してください。  

3. もしBIOSロゴすら出ない場合

TB4ドッキングステーション経由のディスプレイ出力が、前回の更新でビデオ関連のリソース競合を起こしている可能性があります。必ず**「本体への直挿し」**で確認してください。

※.TB4ドックの配下には、サンダーボルト3ケーブルだけの接続で15inchiモバイルモニタがある。34inchiメインモニタは、本体HDMI端子直結)

強制終了

「Gemini」の指示に従い
◎ 電源ボタン押しで、完全にシャットダウン
電源アダプタ、HDMIを一度外すTB4ドックは取り外し済み
待機:13:58 ➡️ 14:00まで
最小構成で:電源アダプタ、HDMI取り付け、LANケーブルは接続のまま。
試行: 14:01電源投入、14:01BIOS画面、14:02 Login画面➡️Login正常

Xで、注意喚起

⚠️Windows 11最新アプデ(KB5077181)要注意!適用直後は「成功」しますが、数十分作業後にシステムが完全フリーズ。再起動後10分以上のブラックアウト(暗転)に陥りました。【復旧策】全ケーブルを抜き「放電」して最小構成でようやく生還。Ryzen環境の方は特に注意を!詳細は後ほど。#KB5077181

本日のWindows Update検証:・ AE8(Ryzen 9):時間差ハング→再起動不能(放電で復旧)・i7-1165G(Intel)これから検証Ryzen環境の「fTPMエラー」が原因の可能性濃厚。一度「成功」に見えるのがタチが悪いです。復旧手順とIntelとの比較結果を至急まとめます。#Windows11

AIにブログ画像を頼んだら「パスタ画像」を生成されるわ、本番PCはアプデ後にブラックアウトして死にかけるわで、激動の祝日になってます…。冗談抜きで今回のKB5077181、Ryzen環境で「時間差フリーズ」が起きています。画面が真っ暗で困っている方、全ケーブル抜いて1分放置(放電)を試して!

Blog更新

Intel機で検証

GEMINIに投げかけ

 ちなみに、このノートpcは、 i7-1165Gで、前回のKBも今回のKBも当てていません。
(前回のKBでメインがバグった経験と時間が取れなかった。から)
 このPCに、今回のKBを当てて、何も問題がなかったら、
Blogにも追記Intel系は(同じTPMエラーが出ているのに、YouTubeを流しながら放置してもIntelは平然としていた)
Intel系は問題が起らなかったと書けるし、
フィードバックの方にも問題の限定を示唆できると思うので、
記事の修正後に行おうと思いますが如何でしょうか?

GEMINIの見解

その考えは、検証者として**「極めて論理的で価値の高いアプローチ」**です!ぜひ実行すべきだと思います。

現在の不具合が「Windows 11全体のバグ」なのか、「AMD Ryzen(fTPM)に特化した問題」なのかを切り分けることは、読者にとってもMicrosoftにとっても最大の関心事だからです。

もし、i7-1165G(第11世代Intel Core)でKB5077181を適用して何の問題も起きなかった場合、ブログとフィードバックには以下のような**「対比構造」**で追記することをお勧めします。

1. ブログに追記すべき「検証の結論」

【比較検証】Intel環境では「無傷」だったという事実

同時進行でIntel Core i7-1165G環境でも同パッチを適用しましたが、こちらは再起動後も、数時間の連続使用後も、一切のフリーズ・ブラックアウトは発生しませんでした。

この対比から、今回のKB5077181が引き起こす致命的なトラブルは、**「AMD Ryzen環境におけるfTPM(TPM-WMI 1801)との競合」**に起因する可能性がより濃厚となりました。Intelユーザーは比較的安心して適用できる一方で、Ryzenユーザーには依然として「厳重注意」が必要であるという、明確な切り分けができました。

2. Feedback Hub への追記(重要)

すでに投稿したフィードバックのコメント欄、または追記として以下を添えると、エンジニアが原因を特定しやすくなります。

  • 追加情報: 「Intel Core i7-1165G環境では同一パッチで異常なし。問題はAMD Ryzen搭載機(AE8)に発生。この事実は、不具合が特定のチップセット、あるいはfTPMの実装に依存していることを強く示唆している。」
⚠️ 注意点

Intel系で問題が起きないことを確認する際も、念のため以下の手順を踏むことをお勧めします。

  1. 作業中のデータは保存し、バックアップを取る: 念のためです。
  2. イベントビューアーの確認: 起動後、Intel機の方で「TPM」や「WMI」に関連する警告(ID 1801以外も含め)が出ていないかを一応チェックしてください。「エラーすら出ていない」なら、それは完全な勝利(Intelは安全)の証明になります。

この「Intel vs AMD」の比較データが加わることで、あなたのブログ記事は**単なるトラブル報告を超えた、一級の「技術検証ドキュメント」**になりますね。

Blog更新

i7-1165G機の結果

KB5077181
Intel機
ID:1801

Blog更新

intel系では、KB後の再起動を除いた再起動でも問題発生はありません。イベントビューアには同様のTPMエラーはありますが、問題なく動いていますし、時間をおいて再起動しても、問題なく動作します。1時間以上放置して再起動をかけても、問題なくLogin画面からloginできて、操作も問題なく行えます。
これで「Gemini」の言う、Ryzen CPU特有のfTPMにMicrosoftが上手く対応できていないことが濃厚になってきました。これで、フィードバック Hubに根拠を示した投稿ができます。
 既に、4章の「重要検証」のBlog更新で示した画像は、前回のフードバック(賛成票3)と今回のフードバック(賛成票1)の鏡の部分です。
 これから、実際にフィードバック Hubに投稿した詳細をお見せします。

Blog更新

フィードバック Hubに投稿

🐞問題
Windows 11 25H2 (Build 26200.7840): 累積更新プログラム適用後の利用中にブラウザフリーズおよび再起動時のブラックアウトが発生する問題
【問題の要約】
特定の累積更新プログラム(KB)適用後のRyzenシステムにおいて、ブラウザのフリーズから再起動時のブラックアウトに至る致命的な不安定挙動が発生しています。
比較検証として、同様にイベントビューアーにTPMエラーが記録されているIntel環境(Core i7-1165G7)では本不具合が発生しないことを確認しており、Ryzenプラットフォームに依存した深刻な互換性問題、あるいはOS側の処理不備である可能性が高いと考えられます。

【詳細な不具合の経緯(Ryzen環境)】

KBインストール後の初回再起動およびログインは正常に完了する。

その後、利用中にブラウザ(タブ等)がすべてフリーズする。

特記事項:YouTube等の音楽再生のみ継続されるが、UI操作は一切不能となる。

システム復旧のため手動再起動を試みると、ブラックアウトが発生し正常に起動できなくなる。

【比較検証データ】

不具合発生環境: Ryzen搭載PC

正常動作環境: HP Spectre x360 (Intel Core i7-1165G7 / Windows 11 25H2)

共通点: 両環境のイベントビューアーにおいて、同時期に同様のTPMエラーが記録されている。

相違点: Intel環境ではTPMエラー記録後も再起動を含め正常に動作するが、Ryzen環境のみ上記ステップでシステムが全損(ブラックアウト)する。

【要望】
イベントビューアーに記録されているTPMエラーが、Ryzenプロセッサにおいてどのようなシステム競合を引き起こしているか、至急調査をお願いします。特に、KB適用後の「特定のマルチメディア処理(YouTube等)とブラウザ制御」がトリガーとなっている可能性を注視してください。

フィードバックの詳細追加
Ryzen環境は、強制終了(電源ボタン長押し)し、その後外部接続用のドッキングステーションなどを外し、2分間放置(帯電放流)し、さらに最小構成にしてから電源ONで、BIOS画面➡Login画面➡Login完了で、今のところ正常に動作しています。しかし同様の問題は、このフィードバック以前に上げた、フィードバックでも報告・要望している通り、早急な対応を望みます。

Blog更新

  実機検証

Core i7 vs Ryzen 最終検証報告

【実機検証】KB5077181 i7 vs Ryzen 9で驚きの挙動差

 ここで、詳細の内容を知りたい方は、以下のブログカードのクリックで!

Blog更新

追記:Intel環境での対照実験で見えた「真の境界線」

Ryzen機(メインPC)で発生した「KB適用後のブラウザフリーズ&再起動不可」という致命的な不具合。これがOS側の問題なのか、ハードウェア固有の欠陥なのかを切り分けるため、同環境(25H2 / Build 26200.7840)を構築したIntel機(HP Spectre / i7-1165G7)にて対照実験を行いました。

その結果、驚くべき事実が判明しました。

1. エラーログは「共通」、しかし結果は「非なるもの」

Intel機においても、イベントビューアーにはRyzen機と全く同じ**「TPMエラー(ID等)」**が記録されていました。しかし、決定的な違いはその後の挙動です。

  • Intel機: しばらく放置した後の再起動でも、何事もなかったかのように正常にログイン可能。
  • Ryzen機: YouTube再生以外の操作が全フリーズし、再起動を試みた瞬間にブラックアウト(システム死)。

同じTPMエラーを吐きながら、一方は平然と動き、一方は沈黙する。この事実は、**「エラー自体が直接の死因ではなく、そのエラーをトリガーとしたOS側の処理(特にRyzenアーキテクチャへのリソース割り当てやfTPM制御)に致命的な不備がある」**ことを強く示唆しています。


結論:Microsoftに問いたい「ハードウェア認証」の責任

今回の検証を通じて、結論は一つに絞られました。

「今回の更新プログラム(KB)は、Ryzen環境におけるシステム整合性を破壊している」

イベントビューアーに同様のエラーが出ている以上、MS側は「TPMの問題」として一括りに処理したいのかもしれません。しかし、Intel機で問題なく動作している以上、AMD(fTPM)側の責任に転嫁することは不可能です。なぜなら、このハードウェア構成をWindows 11の要件として認証し、制御を司っているのは他ならぬMicrosoft自身だからです。

ユーザーにできる「fTPMの無効化」などの付け焼き刃な対策には限界があります。MSには、この「特定のCPUアーキテクチャで発生する致命的な競合」を重く受け止め、一刻も早い修正パッチの配布を強く求めます。(初回のフィードバックは約1週間前で今回2回目です。)

Blog更新

「本件、Microsoftのフィードバック Hubを通じて正式に報告済みです。同様の症状の方はぜひ『賛成票(Upvote)』を投じて、早期修正を後押ししましょう。」

タイトルとURLをコピーしました