Windows 11 24H2で、スタートメニューやエクスプローラー、タスクバー、設定アプリなど“Windowsの顔”みたいな部分がまとめて壊れる深刻な不具合が見つかりました。
2025年7月以降の月例累積更新（KB5062553）を入れた環境で発生し、MicrosoftもKB5072911のサポート文書として正式に不具合を認めています。BetaNews+2Microsoft サポート+2

この記事では、
「急にスタートメニューが開かなくなった」
「Explorer.exe や ShellHost.exe が落ちまくる」
「KB5062553を入れてから調子がおかしい」
という人に向けて、原因の整理と Microsoft が案内している PowerShell 回避策を、日本語でわかりやすく噛み砕いてまとめます。

2025年11月26日公開

今回の不具合のざっくり概要

まず全体像から。

今回の不具合は「Windows 11 24H2 に 2025年7月以降の累積更新（KB5062553 以降）を入れたあと、スタートメニューやエクスプローラーなどの“シェル”周りが連鎖的にクラッシュする」というものです。BetaNews+2BleepingComputer+2

Microsoft の公式サポート記事（KB5072911）によると、PC をプロビジョニングした直後の最初のログオン、あるいは VDI（仮想デスクトップ）などの「非永続 OS」でユーザーがログオンしたタイミングで、XAML を使うコンポーネントがうまく登録されず、いろいろなアプリや UI が落ちたり起動しなくなったりします。Microsoft サポート+2Microsoft サポート+2

相談内容を整理：どんな人向けの記事か

あなたの状況がこんな感じなら、まさにドンピシャの内容です。

・Windows 11 24H2 を使っている（または展開中）
・2025年7月以降の累積更新を入れている（KB5062553 など）
・ログオン直後から挙動がおかしく、再起動しても直らない
・スタートメニューやタスクバーが消える／エクスプローラーが頻繁に落ちる

特に、企業や学校で「イメージ展開＋VDI」を組んでいる管理者さんは、この不具合の影響をモロに受けやすいので要注意です。BleepingComputer+2窓の杜+2

一般ユーザーでも、該当ビルドを Preview で先取りしていたり、新しい PC に 24H2 を入れて運用している人は巻き込まれる可能性があります。

Windows 11 24H2＋KB5062553/KB5072911で何が起きている？

ニュースサイトや各種テック系メディアの情報をざっくり統合すると、流れはこんな感じです。

・2025年7月8日頃配信の 24H2 向け累積更新 KB5062553 を境に、世界中で「スタートメニューが開かない」「Explorer が落ちる」報告が増え始める窓の杜+2Daily CyberSecurity+2
・問題は 24H2 の“新しいコア”側にあり、同じコアを使う 25H2 系にも波及しているという指摘もあるDaily CyberSecurity+1
・Microsoft は 2025年11月20日付けで KB5072911 を公開し、「XAML コンポーネントに依存しているアプリが、更新後に正しく登録されないことが原因」と正式に認めたMicrosoft サポート+2Microsoft サポート+2

つまりアップデートそのものが“OS の顔となる UI パーツの読み込みタイミングを狂わせてしまい、シェル全体がぐらつく”という、なかなかシャレにならないバグだということです。

症状まとめ：スタートメニューもエクスプローラーも「まとめて不調」

Microsoft のサポート文書や各種報告を元に、症状を文章で整理するとこんな感じです。Daily CyberSecurity+4Microsoft サポート+4Microsoft サポート+4

まず XAML 依存の UI 部品が壊れるため、スタートメニュー（StartMenuExperienceHost）、検索（Search）、設定アプリ（SystemSettings）、タスクバー、エクスプローラー（Explorer.exe）などが「起動しない」「エラーを出して落ちる」「無言で消える」といった動きを見せます。

特に多いのが、エクスプローラー自体はプロセスとして動いているのに、タスクバーのウィンドウが表示されず、画面下部が空っぽになってしまうパターン。さらに、ShellHost.exe がクラッシュして、スタートメニューもタスクバーもまとめて消える“ほぼ操作不能な状態”に落ちる報告も出ています。

一言で言うと「OS は起動しているのに、ユーザーの入口となる UI がほぼ全部ダメになる」という、かなり致命傷に近い挙動です。

原因：XAML依存コンポーネントの登録遅延バグ

公式サポート KB5072911 では、原因がかなりストレートに書かれています。

スタートメニューや検索、設定アプリ、エクスプローラーなどは、
MicrosoftWindows.Client.CBS_cw5n1h2txyewy
Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe
MicrosoftWindows.Client.Core_cw5n1h2txyewy
といった XAML 関連のパッケージに依存しています。Microsoft サポート+2Microsoft サポート+2

ところが、2025年7月以降の累積更新を入れたあと、このあたりのパッケージが「ログオン時に間に合って登録されない」ことがあり、その結果、シェルコンポーネントが正常に初期化できずに落ちる、という流れになっています。

要するに「必要なライブラリが読み込まれる前に、スタートメニューやエクスプローラーが立ち上がろうとしてコケる」という“タイミングバグ”です。

クラッシュのきっかけ自体は単純でも、依存関係の中心にいるコンポーネントがやられるので、症状としてはかなり派手に見えるわけですね。

公式の対応状況とエラーコード情報

ここが一番大事なところかもしれません。

・Microsoft は KB5072911 の中で不具合の存在と原因を認め、「現在解決策に取り組んでいる」と明記していますが、まだ恒久的な修正パッチ（完全な自動対応）は配信されていません。Microsoft サポート+2Microsoft サポート+2
・現時点での公式方針は「手動で XAML 関連パッケージを再登録してね」という、かなり技術者寄りのワークアラウンドです。BetaNews+2Microsoft サポート+2

エラーコードとして「0x〜」のような番号が特定されているわけではなく、“アプリケーションエラー”や“クリティカルエラー”など、見た目はよくあるクラッシュとして出てしまうのも厄介なポイントです。

そのため、単体の PC トラブルと誤解されて、現場で原因特定に時間を溶かしてしまうケースがけっこう出ていそうです。

影響を受けるユーザー・環境は？

対象環境を整理すると、こんなイメージになります。Windows Forum+3BleepingComputer+3Windows Forum+3

・OS：Windows 11 バージョン 24H2（同じコアを使う 25H2 も影響の可能性あり）
・更新：2025年7月以降の月例累積更新（特に KB5062553 適用環境）
・タイミング：累積更新適用後の“最初のログオン”で発生しやすい
・構成：VDI や非永続 OS（ログオンのたびにアプリを展開する環境）だとほぼ毎回再現するケースがある

一般的な家庭用 PC でも起こり得ますが、特にやられやすいのは企業・教育機関などで 24H2 イメージを一括展開している管理者層です。

VDI プールがまるごと「スタートメニューが開かない仮想デスクトップ」になったら、正直悪夢ですよね…。

手動での回避策（PowerShellコマンド）

ここから、Microsoft が案内しているワークアラウンドを、日本語でかみくだいて書いていきます。

基本方針は「ユーザーセッション内で不足している XAML パッケージを手動で再登録し、その後シェルを再起動する」です。hackernoon.com+3Microsoft サポート+3Microsoft サポート+3

まずは単体 PC やテスト環境向けの手順から。

(1) 管理者権限の PowerShell を開く
スタートボタンが死んでいる場合は、Ctrl＋Shift＋Esc でタスクマネージャーを開き、「ファイル」→「新しいタスクの実行」から「powershell」と入力し、「管理者として作成」にチェックを入れます。

(2) 次の 3 つのコマンドを順番に実行する

1行目：
Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode

2行目：
Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\appxmanifest.xml' -DisableDevelopmentMode

3行目：
Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode

(3) シェル関連プロセスを再起動する
SiHost.exe や Explorer.exe を再起動するか、いったんサインアウト→サインイン、もしくは OS を再起動します。

この 3 パッケージをユーザーセッション内で再登録することで、スタートメニューやタスクバーなどが正常に初期化されることが多い、というのが Microsoft の説明です。hackernoon.com+3Microsoft サポート+3Microsoft サポート+3

ただし、これは“暫定の応急処置”であり、将来の更新や別ユーザーのログオンで再発する可能性は残ります。

VDI・非永続環境向けのログオンスクリプト例

VDI などの非永続 OS では、「毎回のログオン時にこの再登録処理を自動で走らせてから Explorer を起動する」という作戦が推奨されています。Microsoft サポート+2Windows Forum+2

イメージとしては、こんなバッチファイルを用意して、ユーザーログオンスクリプトとして同期実行させる感じです。

@echo off
REM MicrosoftWindows.Client.CBS を登録
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode"

REM Microsoft.UI.Xaml.CBS を登録
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\Microsoft.UI.Xaml.CBS_8wekyb3d8bbwe\appxmanifest.xml' -DisableDevelopmentMode"

REM MicrosoftWindows.Client.Core を登録
powershell.exe -ExecutionPolicy Bypass -Command "Add-AppxPackage -Register -Path 'C:\Windows\SystemApps\MicrosoftWindows.Client.Core_cw5n1h2txyewy\appxmanifest.xml' -DisableDevelopmentMode"

このログオンスクリプトを「Explorer が立ち上がるより前に同期実行する（処理が終わるまで Explorer をブロックする）」ように設定しておくことで、シェルが起動する時点では XAML パッケージが登録済みになり、クラッシュをかなり防げる、という考え方です。Microsoft サポート+2Windows Forum+2

非永続環境では“ログオンのたびにアプリを再展開する”ため、この手のタイミング問題が毎回顔を出しやすく、ログオンスクリプトによる回避が現実的な落としどころになっています。

実運用での注意点と安全に試すためのポイント

とはいえ、「とりあえず PowerShell ブチ込めばOK」というほど単純でもありません。

本番環境に適用する前に、必ずテスト用の VM や検証用 VDI プールで動作確認をし、スクリプトが失敗した場合の挙動も確認しておくことが超大事です。

気をつけたいポイントを、あえて文章で並べると、

・Add-AppxPackage 実行時にエラーが出た場合、そのログを採取しておく（パス名のタイプミスなども起こりがち）
・セキュリティポリシーで PowerShell の実行が制限されている環境では、ExecutionPolicy の扱いに注意
・ログオンスクリプトを“同期実行”にしておかないと、結局 Explorer の起動が先に走って再発する可能性がある
・シンクライアントなどネットワーク越しの環境では、スクリプト実行時間によるログオン遅延もユーザー体験に影響する

あたりは最低限押さえておきたいところです。

フォーラム風コメント欄：現場の声いろいろ

最後に、実際にありそうな“現場の声”をイメージして、掲示板っぽくまとめてみます。

ユーザーA（情シス・VDI担当）
「7月の累積更新を入れたあと、VDI プールのユーザーから『スタートメニューが開かない』『タスクバーが消えた』って問い合わせが雪崩みたいに来ました…。原因が 24H2 の XAML 周りだと分かるまで、正直かなり時間を溶かしました。」
ユーザーB（個人ユーザー）
「24H2 にしてから、たまにエクスプローラーだけ落ちる現象が続いてたんですが、まさか OS 側のバグだったとは…。最近の更新って、ちょっと怖いですね。」
ユーザーC（インフラエンジニア）
「ログオンスクリプト方式、たしかに効きます。ただ、毎回ログオンがワンテンポ遅くなるので、社内から『PCが重い』って別のクレームは来ました（笑）。恒久対策パッチ、早く出てほしい。」
ユーザーD（検証担当）
「検証用の 24H2 イメージで KB5062553 を入れて再現テストしましたが、XAML パッケージの登録が終わる前にシェルが立ち上がると、かなりの確率でタスクバー無し状態になりました。Microsoft が原因を認めたのは一歩前進ですね。」

こういう声を見ていると、「自分の環境だけがおかしいわけじゃないんだ」と少しだけ気持ちが楽になるかもしれません。

まとめ：恒久対策が出るまでの“現実解”

ここまでの内容を一行にまとめると、

「Windows 11 24H2 で KB5062553 以降を入れてからスタートメニューやエクスプローラーが壊れるのは、XAML 依存パッケージの登録タイミングバグが原因で、当面は PowerShell での手動再登録やログオンスクリプトによる回避が現実的な対処」
という話になります。Daily CyberSecurity+4BetaNews+4Microsoft サポート+4

もちろん、理想は「次の月例更新か、専用の修正パッチで Microsoft が完全に直してくれること」です。
それまでは、
・影響を受けるのが 24H2＋2025年7月以降の累積更新だと知っておく
・問題が出た場合は、XAML パッケージの再登録を試す
・VDI や非永続 OS ではログオンスクリプトでの回避を検討する
という 3 点セットを頭の片隅に置いておくと、いざというときに慌てずに済みます。

あなたの環境ではどんな症状が出ているか、PowerShell のワークアラウンドで改善したかどうか、もしよければ“フォーラム感覚”でコメントとして共有してみてください。
同じ 24H2 に悩まされている管理者さん・ユーザーさん同士で、少しでも情報が回れば、それだけでかなり心強いはずなので。