https://error-daizenn.hatenablog.com/entry/2025/11/26/193111

Windows 11 24H2にして「7月以降の更新を入れたら、スタートメニューが開かない」「タスクバーが消えた」「エクスプローラーが何度も落ちる」みたいな、ちょっと笑えない不具合にハマっていませんか？

実はこれ、あなたのPCだけのトラブルではなく、2025年7月以降の累積更新（KB5062553など）を入れたWindows 11 24H2で、Microsoftが公式に“既知の不具合”として認めたバグです。Microsoft Update Catalog+1

この記事では、
「何が原因なのか」「どのPCが危ないのか」「一時的な回避策」「VDI環境はどうすればいいのか」
を、フォーラムでみんなと話しているようなノリで、でも技術的なポイントはしっかり押さえながら解説します。

2025年11月26日公開

どんな不具合なのか：スタートメニューから設定アプリまで“Windowsの顔”がまとめて壊れる

まず症状の整理からいきましょう。Microsoftと各種メディアの情報をまとめると、このバグは次のような現象を引き起こします。Microsoft サポート+1

・スタートメニューが全く開かず「重大なエラー」が出る
・タスクバーが表示されないまま、デスクトップだけ出ている
・エクスプローラーが繰り返しクラッシュする
・設定アプリ（設定→システム）が起動しない or 無言で落ちる
・ShellHost.exeやStartMenuExperienceHostがエラーで終了
・XAMLビュー（UWP系UI）の初期化に失敗してアプリが落ちる

つまり“Windowsの見た目と操作まわり（シェル周り）ほぼ全部が巻き込まれる”かなり強烈な不具合です。HotHardware+1

ここまで壊れると、正直「もうこれ仕事にならん…」というレベルですよね。特に職場のPCやVDIで起きると、朝イチから冷や汗ものです。

いつから・どの更新で壊れるのか：KB5062553以降の24H2向け累積更新がトリガー

この不具合が表に出たきっかけは、2025年7月の累積更新 KB5062553 です。

・対象：Windows 11 Version 24H2（x64／ARM64）
・配信開始：2025年7月8日（日本時間では9日）
・内容：セキュリティ修正＋新機能（タスクバーの小さいアイコンなど）を含む大型パッチMicrosoft Update Catalog+1

Microsoftのサポート記事 KB5072911 によると、**「2025年7月以降の24H2向け月例累積更新を使ってPCをプロビジョニングした場合に、この不具合が発生する」**と説明されています。Microsoft サポート+1

つまり「24H2にして、7月以降の更新を適用したPC」＋「特定の条件でプロビジョニングされたPC」という組み合わせがスイッチになっているわけです。

どんな環境が一番危ない？：一般ユーザーとVDIで影響度が違う

Microsoftは、問題が起こりやすいパターンとして次の2つを挙げています。Microsoft サポート+1

(1) 累積更新を適用した“初回ログオン”時
(2) 非永続OS（ログオンごとに環境を作り直すVDIなど）での“すべてのログオン”

一般家庭のPCだと、(1) の「更新後、最初にログインしたタイミング」でだけ出るケースが多いです。とはいえ、一度壊れるとシェル周りが回復せず、再起動しても同じ…なんて報告もあります。ハウトゥーギーク+1

一方で影響が深刻なのは、企業のVDI（仮想デスクトップ）環境です。VDIはユーザーがログオンするたびにアプリのプロビジョニングをやり直す構成が多く、「毎回ログインするたびにスタートメニューが死ぬ」「タスクバーが無い」みたいなカオス状態になりやすいのが本当にキツいところ。Cyber Security News+1

対象ユーザー層で言うと、
・自宅PCユーザー → 影響は“出る人には出る”程度
・中〜大規模企業のVDI／イメージ展開環境 → かなり高確率で刺さる
こんなイメージです。

原因：XAML依存パッケージが“間に合わない”せいでシェルが空中分解

技術的な原因は、Microsoft自身がかなりハッキリ書いてくれています。

サポート記事 KB5072911 では、**「影響を受けるアプリはXAMLパッケージに依存しており、更新後にそのパッケージが“時間内に登録されない”ことが原因」**と説明されています。Microsoft サポート+1

問題のXAML依存パッケージは、たとえば次の3つ。窓の杜+1

・MicrosoftWindows.Client.CBS
・Microsoft.UI.Xaml.CBS
・MicrosoftWindows.Client.Core

これらが更新後すぐに正しく登録されないと、

・Explorer.exe
・StartMenuExperienceHost
・ShellHost.exe
・ImmersiveShell など

シェルコンポーネントが、必要なXAMLビューを初期化できずにクラッシュしたり、真っ白のまま固まったりする、という仕組みです。HotHardware+1

要するに「見た目の部品を作るモジュールが定刻に来ないせいで、Windowsの“顔”が全部崩れている」というタイミングバグなんですね。

公式の対応状況：原因は特定済み、恒久対策は“準備中”

気になる公式対応ですが、現時点（2025年11月時点）でのMicrosoftのスタンスはこんな感じです。Microsoft サポート+1

・原因：XAML依存パッケージが更新後にタイムリーに登録されない
・ステータス：原因は特定済み
・恒久対策：現在実装中、「解決策ができ次第情報を更新する」と明記
・一時的な回避策：PowerShellとスクリプトで“手動登録”する方法を案内

つまり、**「バグは認めた・再現もしている・ただし完全に自動で直すパッチはまだ出ていない」**という段階です。

これだけ派手な症状なので、次回以降の累積更新か、オンデマンド修正パッチの形で修正版が出てくる可能性は高いですが、いつとは書かれていません。

一般ユーザー向けの回避策：PowerShellでXAMLパッケージを再登録する

じゃあ今どうすればいいの？という話ですよね。
Microsoftのサポート記事や日本の技術サイトでは、スタンドアロン環境向けに以下のような手動対処が紹介されています。窓の杜+1

ざっくり言うと、

(1) 管理者権限でPowerShellを開く
(2) 問題のXAMLパッケージを Add-AppxPackage で再登録する
(3) Shell Infrastructure Host（SiHost）などシェル関連のプロセスを再起動する

という流れです。

具体的なコマンド例（イメージ）はこんな感じになります。

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

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

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

SiHost.exe（Shell Infrastructure Host）を再起動

コマンドは環境によってパスが違う場合もあるので、Microsoft公式の記事や信頼できる技術サイトを見ながら、コピー＆ペーストではなく“確認しながら”打つのをおすすめします。窓の杜+1

うまく再登録できると、スタートメニューやタスクバーが復活し、エクスプローラーのクラッシュも収まったという報告が多いです。

VDI／企業環境向けの回避策：ログオンスクリプトで“毎回登録させる”

非永続VDIなど、ログオンのたびに環境が初期化される構成だと「一度直せば終わり」にならないのが厄介です。Microsoftはこうした環境向けに、**「ログオンスクリプトでXAMLパッケージ登録を毎回先に済ませておく」**というやりかたを推奨しています。Microsoft サポート+1

イメージとしては、

(1) バッチファイルかPowerShellスクリプトで、XAML依存パッケージをAdd-AppxPackageで登録
(2) そのスクリプトを“ユーザーログオン時”に必ず同期実行するようGPOなどで設定
(3) スクリプト実行完了までExplorer.exeの起動を待たせる

という流れです。

Explorerが先に立ち上がってしまうと、また「必要なパッケージがまだ来てない！」状態でクラッシュするので、“Explorerより先に登録を終わらせる”のが超重要なポイントです。Windows Forum+1

大規模VDIだとログオンスクリプトが増えるだけでも運用がだるくなりますが、パッチが出るまでの「時間稼ぎ」としては現実的な選択肢になってしまっているのが現状ですね…。

もし今まだ24H2に上げていないなら：様子見も選択肢のひとつ

ここまで読んで「うわ、そこまでして24H2にしたくないな…」と思った人もいるはずです。

24H2自体は新機能も多い、いわば“次のメインストリーム版”なんですが、2025年後半時点ではまだ荒削りな部分が目立ち、今回のようなシェル周りの大きい不具合も出ています。neowin.net+1

一般ユーザーであれば、

・まだ24H2に自動アップグレードされていない
・スタートメニューやタスクバーの不具合報告を見て不安なら

一旦「更新の一時停止」で様子を見る、というのも立派な戦略です。

企業環境であれば、24H2の展開を“VDIでは保留しておく”とか、“問題のKB5062553以降を除外して検証する”など、いつものパッチ運用ルールを少し慎重寄りに振っておくと、トラブルの波に飲まれにくくなります。

みんなの広場：実際どうだったか、情報を出し合った方が絶対に楽

最後に少しフォーラムっぽい話を。

もしあなたの環境で、

・KB5062553以降を入れてからシェルが壊れた
・XAMLパッケージ再登録で直った／直らなかった
・VDIでログオンスクリプトを回すことでなんとか運用している

みたいな体験があれば、ぜひ“コメント欄に書くつもり”で周りと共有してほしいなと思います。

この不具合は「条件が揃った人だけドンピシャでハマる」タイプなので、実際の事例が増えれば増えるほど、「自分の環境は危険ゾーンかどうか」が見えやすくなります。

深夜に1人でスタートメニューと戦うの、ほんと消耗しますからね…。
情報をシェアして、お互いの“時間とメンタル”の消耗を少しでも減らせたらいいなと思います。

まとめ：24H2の“シェル崩壊バグ”はXAMLパッケージの登録遅延が原因、恒久対策待ちつつ一時しのぎを

この記事のポイントをギュッとまとめると、こうなります。

・不具合はWindows 11 24H2＋2025年7月以降の累積更新（KB5062553など）で発生する既知の問題
・スタートメニュー／タスクバー／エクスプローラー／設定アプリなど、シェル周りがまとめて壊れる
・原因は「XAML依存パッケージ（Client.CBS／UI.Xaml.CBS／Client.Core）が更新後に間に合って登録されないタイミングバグ」
・Microsoftは原因を認め、恒久対策は“作業中”としたうえで、PowerShellによる手動登録やログオンスクリプトを回避策として案内

もしすでに症状が出ているなら、上で紹介した再登録の手順を試しつつ、今後の累積更新のリリースノートをしばらく注意深く追ってみてください。

「うちはこんな構成で、こうやってしのいでるよ」という話も大歓迎なので、そんなノリでまた教えてもらえたら嬉しいです。