ある日のWindows Update以降、Windows 11の「設定」アプリ（ms-settings）が開かなくなりました。
ショートカットキーの Win + I を押しても、スタートメニューからアイコンをクリックしても、実行ファイルを直接叩いても、ウィンドウひとつ出ず無反応な状態でした。

異変に気づいてすぐ、当時使っていたGemini 3.8 Flashに相談しながら、ネット上の定番手順からOSの上書きインストールまで一通り試してみたのですが、まったく直りませんでした。
幸い、昔ながらの「コントロールパネル」は問題なく開いたため、「もうクリーンインストールしか道がないなら、最悪このままなんとかなるか……」と諦め、しばらく騙し騙し使い続けていました。

ただ、マルチディスプレイの配置変更やWindows Updateの確認など、新しい「設定」画面でしか触れない項目が必要になるたびに手が止まり、だんだんと不便さが限界に達してきました。
そこで重い腰を上げ、最近出たGeminiの最新モデル（Argon 4）にダメ元で再相談してみたところ、イベントログの深掘りから真因（CapAuthz レジストリの欠落）を特定でき、PowerShellスクリプトで復旧できました。

同じ症状で詰まっている方の参考として、調査と解決の記録を残しておきます。
（※なお、本記事で紹介する手順やスクリプトは、あくまでも筆者の環境で成功した事例です。システムレジストリを直接操作するため、試される際はバックアップを取った上で、自己責任にてお願いいたします。）

1. 事象発生直後に試して全滅した「定番の対処法」一覧

設定アプリが開かなくなった直後、Gemini 3.8 Flashに相談しながら、ネットでよく紹介されている対処法を上から順番に試していきました。

  1. システムファイルチェッカー（sfc /scannow）とDISMコマンド
    管理者コマンドプロンプトから実行しましたが、異常は検出されず変化なし。
  2. PowerShellからのAppXパッケージ再登録
    Get-AppxPackage *immersivecontrolpanel* | Reset-AppxPackage や Add-AppxPackage -DisableDevelopmentMode -Register ... を実行しましたが、コマンド自体はエラーなく通るものの、設定アプリは開かないままでした。
  3. エクスプローラー（explorer.exe）の再起動・キャッシュクリア
    タスクマネージャーから再起動しても改善せず。
  4. OSの上書きインストール（ISOによるインプレースアップグレード）
    個人ファイルとアプリを引き継いだままWindows 11のISOイメージから上書き修復を行う、いわゆる最終手段です。これでシステムファイルや標準アプリの構成が丸ごと洗われるはずでした。

ところが、長い再起動を終えてデスクトップに戻り、Win + I を押しても、やはり設定アプリは反応しませんでした。
上書きインストールすら空振りしたことで、「あとはクリーンインストールでOSごと初期化するしかないのか……」と心が折れ、そこからしばらく「コントロールパネルだけで凌ぐ生活」に入りました。

2. 診断：Applicationログは無言、TWinUIログ（ID: 5961）にあった手がかり

しばらく騙し騙し使っていたものの、やはり設定画面が開かない不便さに耐えかねて、最近出たGeminiの最新モデル（より深い論理推論を行う「Argon 4」）に、これまでの経緯と「OS上書きでも直らなかった事実」を伝えて再相談してみました。

そこで最初に指摘されたのが、「見ているイベントログの場所が違う」という点でした。

これまで私は、イベントビューアーの「Windows ログ ＞ Application」ばかりを見ていました。通常のアプリがクラッシュしていれば、そこに Application Error（イベントID 1000など）が残るはずだからです。しかし、設定アプリを何度クリックしても、Applicationログには何も記録されていませんでした。

設定アプリ（windows.immersivecontrolpanel）のようなUWPアプリは、プロセスが立ち上がる前の「COMアクティベーション／AppContainerの権限確認」の段階で弾かれると、そもそもプロセスが起動しないため Application Error すら出ません。

代わりに確認すべきだったのは、以下の深層ログでした。

  • ログの場所: アプリケーションとサービス ログ > Microsoft > Windows > TWinUI > Operational
  • イベントID: 5961

実際にこのログを開いてみると、設定アプリを開こうとした時刻とぴったり同じタイミングで、イベントID 5961 のエラーが大量に記録されていました。
設定アプリは「起動後に落ちていた」のではなく、「OSの起動承認チェックの段階で拒否されていた」ことがここで初めて分かりました。

3. 深層分析：なぜCapAuthzレジストリは消え、なぜ上書きでも復元されなかったのか？

さらにログのエラーコードと関連レジストリを突き合わせていくと、直接の原因が判明しました。

WindowsがUWPアプリ（AppContainer環境）を起動する際、セキュリティマネージャーは以下のレジストリキーを参照して、そのパッケージの権限情報（Capability Authorization）を確認します。

Registry Path 
HKLM:\SOFTWARE\Microsoft\SecurityManager\CapAuthz\ApplicationsEx

この配下を調べてみると、電卓やメモ帳など他の標準システムアプリ（末尾が _cw5n1h2txyewy のパッケージ）のエントリは並んでいるのに、設定アプリ（windows.immersivecontrolpanel_...）のキーだけが丸ごと欠落していました。

なぜOSの上書きインストールでも直らなかったのか？

普通なら、OSの上書きインストールや Add-AppxPackage -Register を実行すれば、こうしたレジストリも作り直されるはずです。それなのになぜ復元されなかったのかというと、AppXのデプロイメントデータベース側の仕様が関係していました。

  • OS内部のAppXデータベース上では、設定アプリのパッケージ自体は「すでに正常にステージング・登録済み」というステータスのまま残っていた。
  • そのため、OSの上書きインストールを走らせても、インストーラーが「設定アプリはすでに同じバージョンが登録済みである」と判断し、初期ステージング処理（CapAuthz レジストリキーの生成を含む）をスキップしてしまっていた。

つまり、「パッケージ登録情報は正常なのに、セキュリティ承認レジストリだけが抜け落ちている」という中途半端な壊れ方をしていたせいで、通常の修復コマンドも上書きインストールもすべて空振りしていたわけです。

4. 解決策：PowerShellでPackageSidをAPIから算出し、承認レジストリを手動復元する

原因が「CapAuthz\ApplicationsEx 配下の設定アプリ用キーの欠落」だと分かれば、やるべきことはシンプルです。足りないレジストリキーと値を手動で補ってやれば、OSを初期化しなくても復旧できます。

ただし、このレジストリキーにはパッケージ固有のセキュリティ識別子である PackageSid（S-1-15-2-... で始まる文字列）を正確に設定する必要があります。この値は適当な文字列では動かず、パッケージ名からハッシュ計算された固有の値でなければなりません。

そこで、Windows標準の userenv.dll に用意されている DeriveAppContainerSidFromAppContainerName APIをPowerShellから呼び出して正確な PackageSid を算出し、さらに他の標準システムアプリから基本構造（CapSids バイナリ値など）をコピーして設定アプリのキーを再構築しました。

⚠️ 実行にあたっての注意事項（免責事項）
  • 本記事で紹介している手順およびスクリプトは、あくまでも筆者の環境において復旧に成功した事例であり、すべての環境での動作や問題解決を保証するものではありません。
  • Windowsのセキュリティ管理に関わるシステムレジストリ（HKLM:\SOFTWARE\Microsoft\SecurityManager\CapAuthz）を直接操作するため、実行前に必ずシステムの復元ポイントを作成するか、該当レジストリキーのバックアップ（エクスポート）を取得してください。
  • 必ず「管理者として実行」したWindows PowerShellを使用してください。本手順の実行およびその結果生じたいかなる影響についても、すべて自己責任でお願いいたします。

5. 実行したPowerShellスクリプト

管理者権限で起動したPowerShellに、以下のスクリプトを貼り付けて実行します。
（※あくまでも筆者の環境で成功したスクリプト事例です。OSのビルド等によって状況が異なる場合があるため、試される際は自己責任にてお願いいたします。）

PowerShell（管理者として実行） 
# 1. 設定アプリの正確な PackageSid (S-1-15-2-...) をWindows標準APIから算出
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class SidHelper {
    [DllImport("userenv.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    public static extern int DeriveAppContainerSidFromAppContainerName(string pszAppContainerName, out IntPtr ppsidAppContainerSid);
    [DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    public static extern bool ConvertSidToStringSid(IntPtr pSid, out string strSid);
    [DllImport("advapi32.dll")]
    public static extern IntPtr FreeSid(IntPtr pSid);
    public static string GetSid(string name) {
        IntPtr pSid = IntPtr.Zero;
        if (DeriveAppContainerSidFromAppContainerName(name, out pSid) == 0 && pSid != IntPtr.Zero) {
            string strSid;
            ConvertSidToStringSid(pSid, out strSid);
            FreeSid(pSid);
            return strSid;
        }
        return null;
    }
}
"@
$pkgSid = [SidHelper]::GetSid("windows.immersivecontrolpanel_cw5n1h2txyewy")

# 2. 他の標準システムアプリ (_cw5n1h2txyewy) のエントリから基本構造を取得
$templateKey = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\SecurityManager\CapAuthz\ApplicationsEx" | Where-Object {$_.PSChildName -like "*_cw5n1h2txyewy"} | Select-Object -First 1
$templateProps = Get-ItemProperty $templateKey.PSPath

# 3. 欠落している設定アプリの CapAuthz レジストリキーを作成して値を設定
$targetPath = "HKLM:\SOFTWARE\Microsoft\SecurityManager\CapAuthz\ApplicationsEx\windows.immersivecontrolpanel_10.0.8.1000_neutral_neutral_cw5n1h2txyewy"
New-Item -Path $targetPath -Force | Out-Null
New-ItemProperty -Path $targetPath -Name "AppPackageType" -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $targetPath -Name "EnterpriseID" -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $targetPath -Name "ApplicationFlags" -Value 0 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path $targetPath -Name "PackageSid" -Value $pkgSid -PropertyType String -Force | Out-Null
if ($null -ne $templateProps.CapSids) {
    New-ItemProperty -Path $targetPath -Name "CapSids" -Value $templateProps.CapSids -PropertyType Binary -Force | Out-Null
}

# 4. AppXサービスの再起動
Restart-Service AppXSvc -Force

スクリプトの各ステップの解説

  1. PackageSid の算出:
    C#のインラインコード（Add-Type）を使って userenv.dll の DeriveAppContainerSidFromAppContainerName を呼び出し、windows.immersivecontrolpanel_cw5n1h2txyewy に対応する正確なSID文字列を取得しています。
  2. テンプレートの取得:
    同じシステム署名（_cw5n1h2txyewy）を持つ他の標準アプリのエントリを1つ参照し、共通の権限バイナリ（CapSids）を取得しています。
  3. レジストリキーとプロパティの作成:
    欠落していた windows.immersivecontrolpanel_10.0.8.1000_neutral_neutral_cw5n1h2txyewy キーを作成し、AppPackageType、EnterpriseID、ApplicationFlags、PackageSid、CapSids を書き込みます（※パッケージ名に含まれるバージョン表記等は筆者のWindows 11環境におけるものです）。
  4. AppXSvc の再起動:
    最後にAppX Deployment Service（AppXSvc）を再起動して、追加したレジストリ情報をシステムに認識させます。

6. 復旧の確認と、他のUWP機能の事後検証

スクリプトの実行が完了したあと、Win + I を押してみると、これまで何をやっても無反応だった「設定」アプリが何事もなかったかのようにすっと立ち上がりました。OSの上書きインストールまで試してダメだった時間は何だったのかと思うほど、あっけない復旧でした。

念のため、他のUWP関連機能にも影響が出ていないか、あわせて動作を確認しました。

  • モダン印刷ダイアログの確認: メモ帳を開いて Ctrl + P を押し、UWPベースの印刷ダイアログが正常に表示されることを確認。
  • 各種設定項目の遷移: ディスプレイ設定、Windows Update、Bluetoothとデバイス、アプリ一覧など、設定アプリ内の各ページがエラーなく開くことを確認。
  • OS再起動後の持続性: PCを再起動したあとも、問題なく Win + I で設定が開くことを確認。

すべて正常に動作しており、クリーンインストールによる環境作り直しを無事に回避できました。

7. まとめ：定番の処方箋で直らない時は「一段深いログ」を見る

Windowsのトラブルシューティングを調べると、多くの記事が sfc /scannow や DISM、パッケージの再登録コマンドを紹介しています。もちろんそれで直るケースも多いのですが、今回のように「登録ステータスは正常なまま、深層の承認キーだけが欠落している」ケースでは、定番コマンドもOSの上書きインストールも効きません。

今回得られた教訓は2つありました。

  • アプリが起動すらしない時は、Application ログではなく TWinUI/Operational などのコンポーネント別ログを疑うこと。
  • 「なぜ再登録や上書きインストールが空振りするのか」という仕組みの面から逆算すると、ピンポイントな修復方法が見えてくること。

また、定番手順が全滅した状況から、TWinUI のイベントID 5961の特定、さらには userenv.dll を使った PackageSid の算出まで導き出してくれた、Geminiの最新モデル（Argon 4）の推論力には本当に助けられました。もし同じようにWindows 11の設定アプリが沈黙してしまい、OSの初期化を検討している方がいれば、その前に一度 TWinUI のログと CapAuthz レジストリを確認してみてください（繰り返しになりますが、レジストリ操作を伴うため、試される際はバックアップを取った上で自己責任にてお願いいたします）。

👨‍💻
Rui
Rui Tools 開発者 / 個人エンジニア
日々の「ちょっとした不便」を最速で解決するWebツールを開発中。軽量・ミニマル・実用的なUI設計を好みます。好きなものは珈琲とシンプルな道具。
← 前の記事 💡 発表・プレゼンで絶対に時間オーバーしない！文字数とスピーチ時間の黄金比率と練習のコツ