2025年7月以降の更新プログラム（特にKB5062553）を入れたあと、Windows 11 24H2でエクスプローラーやスタートメニューが突然動かなくなる問題が世界的に報告されています。とくに企業でよく使われている VDI（仮想デスクトップ）などの非永続環境（non-persistent environment） で深刻さが増しており、「ログインのたびにアプリが壊れる」という声も上がっています。

この記事では、Microsoftの公式発表内容と実際のユーザー報告をもとに、原因・症状・対象ユーザー・回避策を一気にまとめ、さらに読者が自由に意見を投稿できる“フォーラム風の流れ”で構成しています。
同じ症状で困っている人がコメントしやすいように、疑問を投げかけながら進めますね。

2025年7月更新（初回公開）

更新後に何が起きているのか？まず状況をわかりやすく整理する

更新プログラム KB5062553（2025年7月以降の累積アップデート） を入れたWindows 11 24H2で、ログイン直後にシステムの重要コンポーネントが動かなくなる現象が報告されています。
非永続環境では“毎回ログイン時に新しい環境が構築される”ため、影響を受ける頻度が高く、一部企業では業務が止まるほどのトラブルになっているようです。

Microsoftは公式サポート文書で問題を正式に認めたため、単なる個人環境の不具合ではないことが確定しました。

最も重要なポイントは「XAMLパッケージが時間内に登録されず、依存アプリが起動に失敗する」ことです。

この原因がわかると、後で紹介する回避策がどうして有効なのかも理解しやすくなります。

発生している主な症状：Explorer.exeやStartMenuExperienceHostのクラッシュが連発する

ログイン後のトラブルは多岐にわたりますが、共通しているのはWindowsシェル（Shell）周りが正常に読み込まれないという点です。
実際にユーザーが体験している症状を、できるだけそのままの言葉で紹介します。

代表的な症状（Microsoft公式とユーザー報告の両方より）

スタートメニューが開かず「重大なエラー（critical error）」と表示される。
Explorer.exe が起動直後にクラッシュし、タスクバーに表示が出ないまま操作不能になる。
ShellHost.exe がログインごとに落ちる。
SystemSettings が“無反応のまま起動しない”。
XAMLビューの初期化でアプリがクラッシュし、一部UIが表示されない。

どれも日常的に使う部分なので、ちょっとしたトラブルでも作業が止まってしまいますよね。
しかも非永続環境ではログインのたびに症状が繰り返されるため、企業のIT管理者から「根本的に直るまで配布できない」という声も出ています。

対象となっているユーザー層：特に企業のVDI利用者は要注意

今回の不具合は、一般ユーザーの通常インストール環境でも発生する可能性はあるものの、影響が大きいのは次のような環境です。

対象ユーザーの特徴

企業で利用する仮想デスクトップ（VDI）
非永続型のWindows 11 24H2
毎回ログイン時にアプリパッケージを再構築する構成
個人でも、プロビジョニング後すぐにログインする運用をしているPC

Microsoftは特にVDIの非永続環境を名指しで説明しており、「ログイン時にアプリパッケージを再インストールする仕組みが更新後の依存関係と噛み合わない」ことを認めています。

不具合の原因：XAML依存パッケージの登録が遅れ、アプリが起動に失敗するタイミング問題

Microsoftは今回の原因を非常にシンプルにまとめています。

原因：アプリが依存している XAML パッケージが、更新後に“時間内に登録されない”ことによって起動順序が崩れる。

これにより…

StartMenuExperienceHost が起動失敗
Explorer.exe が依存コンポーネントを読み込めずクラッシュ
ShellHost.exe が登録前に起動して落ちる
XAMLビューを持つUI全般がエラーを起こす

という連鎖が発生するわけです。

特に“非永続環境”では、ログインのたびにパッケージを読み込む必要があるため、失敗の可能性が高まります。
ちょっとしたタイミングのズレで壊れてしまうあたり、なんだかシビアな仕組みだなぁ…と感じてしまいますよね。

公式対応状況：Microsoftは修正を開発中、暫定の回避策のみ公開

Microsoftはすでに問題を認識しており、「自動的に改善する修正」を開発中と発表しています。
ただし現時点（2025年7月）ではまだ配布されておらず、管理者が手動で対処するしかありません。

Microsoftが示した暫定対応（要点）

ユーザーセッション内で不足しているXAMLパッケージを手動登録する
その後 SiHost を再起動する
非永続環境向けに PowerShell スクリプトを提供
企業はログオンスクリプトとして実行することを推奨

具体的なコマンドは公式文書に提示されていますが、この記事では「コードブロックを使用しない」というルールがあるため、文章で構造を保ちながら紹介しますね。

Microsoft推奨の回避手順（企業向け）

(1) 問題が起きている端末にログインする。
(2) 管理者権限で PowerShell を開く。
(3) Microsoftが提示した3つの「パッケージ登録コマンド」を順に実行する。
(4) SiHost（Windows Shell Infrastructure Host）を再起動する。
(5) 非永続環境の場合は、同内容をログオンスクリプトとして毎回実行させる。

手順自体はそこまで難しくないのに、毎ログインでこれを要求される非永続環境は…正直かなり面倒ですよね。
だからこそ企業の管理者が疲れたような口調で「早く修正を…」と投稿しているのも見かけます。

他ユーザーの声：フォーラムやSNSでは「また壊れた」「ログインできない」と議論に

この記事はフォーラムのように読者が参加しやすい構成にしているため、ここで実際のユーザー報告に近い内容も紹介します。あなたの環境でも同じ現象は起きていますか？

海外フォーラムで見られた投稿例（意訳）

「VDI環境で更新後、ログインのたびにExplorerが落ちていく…作業にならない」
「Start menu critical error が毎日…ユーザーからクレームが止まらない」
「XAML依存のエラーって久しぶりに見た。完全にタイミング問題だろう」
「PowerShellの回避策は効くけど根本は治らないまま。はやく正式パッチを」

SNSでは“Windows 10時代のスタートメニュー壊れる問題を思い出した”という声も出ていて、妙な既視感を覚えます。