Windows 11 環境において、デスクトップ上の画像ファイルを右クリックした際、コンテキストメニューが透明になり正常に描画されなくなるバグを確認しました。
この現象は、私が右クリックメニューを拡張するツールの試作を行っている最中に偶然発見したものです。特定の操作を繰り返すことで症状が悪化する特徴があり、Windows 11 のテーマ設定にかかわらず発生します。本記事では、詳細な発生条件と、原因と推測されるメニューの動的読み込みについて解説します。
デスクトップ上でのみ発生する透明化の症状
このバグは、フォルダー内などのエクスプローラー上ではなく、デスクトップ画面で右クリックメニューを表示した際にのみ限定して発生します。
メニューを出したり閉じたりする動作を連続して行っていると、次第にメニューの背景が透明になっていく症状が現れます。さらに、画像ファイルを右クリックするたびに、この透明な状態が維持される時間が長くなっていくという特徴があります。何度か繰り返すと、メニューの項目だけが背景から浮き上がったような不自然な表示になります。
当初は画像メニューの動的読み込みが原因と推測
この現象はすべてのファイルで起こるわけではなく、画像ファイルを右クリックした時のみ発生します。他の拡張子のファイルでは、何度右クリックを繰り返してもメニューが透明になることはありません。
原因として、画像ファイル特有のコンテキストメニュー項目の処理が影響していると考えられます。画像ファイルを右クリックすると、「フォト」や「ペイントで編集する」といった専用の項目が追加されます。
これらのメニュー項目は、右クリックされた直後ではなく、少し遅れて非同期で読み込まれる仕様になっています。処理が追いつかない場合は、メニュー上に「読み込んでいます…」というテキストが複数表示されます。
この動的な読み込み処理が Windows 11 の描画システム（アクリル効果など）に負荷をかけ、透過処理のバグを引き起こしていると推測されます。
その後の検証では、画像専用の右クリックメニュー項目を無効化しても現象が発生することを確認しました。そのため、これらの項目そのものが直接の原因ではなく、Windows 11 が画像ファイルとして認識した際に通る新しいコンテキストメニュー内部の処理に原因がある可能性が高いと考えています。
ダークモードとライトモードの両方で発生
右クリック拡張ツールの検証過程でテーマを変更してテストを行いましたが、このバグは OS のカラーモードに依存しません。
ダークモードを使用している場合でも、ライトモードを使用している場合でも、同様に右クリックメニューの透明化が発生することを確認しました。テーマの描画設定の問題ではなく、コンテキストメニューの生成プロセスそのものに起因する不具合であると言えます。
バグを確認した OS バージョン
現在、この右クリックメニューのバグは以下の OS バージョンで発生することを確認しています。
- Windows 11 25H2（OS ビルド 26200.8039）
- Windows 11 25H2（OS ビルド 26200.8106）
- Windows 11 25H2（OS ビルド 26200.9278）
- 2026年8月27日公開の KB5120998 Preview を適用した環境でも、不具合は修正されていません。
- Windows 11 26H2（OS ビルド 26300.9550）
これらの環境で同じ症状を確認しています。
現時点では、Microsoft からこの不具合について既知の問題としての案内は確認できていません。そのため、今後のアップデートで修正されるかどうかは不明です。
追記：画像を右クリックするたびに Explorer のメモリー使用量も増加する
その後、この不具合について詳しく調査したところ、右クリックメニューが透明になるだけではなく、画像ファイルを右クリックしてメニューを表示するたびに、Explorer のメモリー使用量が段階的に増加する現象も確認しました。
Windows 11 の新しい右クリックメニューでは、メニューを表示すると内部的に PopupHost と呼ばれるウィンドウが生成されます。
通常のファイルでは、右クリックメニューを閉じるとこれらの PopupHost も破棄されます。
しかし、PNG など Windows が画像として認識するファイルでは、メニューを閉じた後も 2個の PopupHost が非表示の状態で残り続けることを確認しました。
画像ファイルを右クリックするたびに、
右クリックメニューを表示
↓
2個の PopupHost が生成される
↓
メニューを閉じる
↓
PopupHost が破棄されず非表示のまま残る
↓
次の右クリックでさらに 2個増える
という状態になります。
実際に検証した環境では、残留する PopupHost の数が増えるのに合わせて、Explorer のワーキングセットも増加しました。
残留 PopupHost 110個：約 420.9 MB
残留 PopupHost 120個：約 443.2 MB
残留 PopupHost 126個：約 455.2 MB
数分待つと一部のメモリーは解放されますが、増加した分のすべてが元に戻るわけではなく、右クリックを繰り返すほど使用量の基準値が上昇していきます。
そのため、これは単なる右クリックメニューの描画不具合ではなく、メニューに関連するリソースが正常に解放されていない可能性が高い不具合と考えられます。
内部的には XAML の Popup が残留している
さらに WinDbg を使用して調査したところ、問題が発生した画像の右クリックメニューでは、メニューを閉じた後も XAML 側の CPopup オブジェクトが残っていることを確認しました。
残留した 2個の CPopup では、それぞれ参照カウントが 3 と 4 の状態で維持され、その後に別の右クリックメニューを表示して閉じても値は変化しませんでした。
また、これらの CPopup は IPopupWindowSiteBridge を保持したまま残っています。
正常な場合は、
CPopup の破棄
↓
EnsureBridgeClosed
↓
ContentSiteBridge::Close
↓
PopupWindowSiteBridge::Destroy
という処理によって右クリックメニューのウィンドウが破棄されます。
しかし、画像ファイルの場合は CPopup が参照を残したまま破棄されないため、この処理まで到達せず、PopupWindowSiteBridge と PopupHost も残留していると考えられます。
現時点では、画像ファイルの場合に CPopup の参照が残り、関連する PopupWindowSiteBridge や PopupHost が破棄されないことまでは確認できています。参照が残る直接の原因については特定していません。
Explorer を再起動すると元に戻る
蓄積した PopupHost とメモリー使用量は、Explorer を再起動するとリセットされます。
右クリックメニューが透明になった場合、一時的な回避策として Explorer を再起動することで正常な状態に戻すことができます。
