MENU

UWPデプロイが「Installing missing frameworks…」で止まる時の完全対処法｜Microsoft.UI.Xaml 2.8・Visual Studio 2022・Windows 11 リモートデバッグ

Visual Studio

Visual Studio 2022 から Windows 11 Pro のリモート PC へ UWP アプリをデプロイした際に「Installing missing frameworks…」で止まる、続いて「vsdebugeng.impl.resources.dll が見つからない」で接続できない――。現場で頻出するこの連続トラブルを、原因の見極めから安全な復旧、検証、再発防止まで一気に片付けるための決定版ガイドです。コマンドはすべて管理者権限で実行してください。

目次

対象読者と前提

  • UWP（WinUI 2.x）アプリを Visual Studio 2022 で開発している
  • デプロイ先は Windows 11 Pro のリモート PC（同一ネットワークまたは VPN）
  • エラー表示例：
    • Microsoft.UI.Xaml.2.8/X64, app package version 8.2501.31001.0 → Installing missing frameworks… のまま進まない
    • Unable to locate vsdebugeng.impl.resources.dll
  • すべての操作は 管理者 で実施（PowerShell／コマンド プロンプト／エクスプローラー）

この記事で解決できること

  • 「Installing missing frameworks…」で止まる原因の切り分けと復旧手順
  • Microsoft.UI.Xaml 2.8（WinUI 2.x）依存関係を安全に満たす方法（自動・手動双方）
  • リモート デバッガーの DLL 不足エラーの再発を防ぐ構成
  • Store / Notepad など組み込み UWP が起動しない状態の復旧
  • 再発防止の設定・チェックリスト・検証コマンド一式

先に結論（クイックフロー）

時間がない場合は、次の順に実施してください。ほとんどのケースはここで解決します。

  1. Microsoft アカウントで Store にサインイン → wsreset.exe 実行 → PowerShell 管理者で UWP の再登録
  2. 必要に応じて WindowsApps フォルダー ACL を修復（高度な手順。後述の注意を厳守）
  3. Microsoft.UI.Xaml 2.8 の .appx を手動導入（.nupkg から取り出し／PowerShell で Add-AppxPackage）
  4. Windows SDK の最新バージョンを追加インストール
  5. Visual Studio で「クリーン → リビルド → デプロイ」
  6. なお続く場合：リモート デバッガーを OS アーキテクチャに合わせて再インストール → プロジェクト ターゲットを x64 等に固定

症状と原因の対照表

症状主な原因対処の要点
Installing missing frameworks… で停止Store キャッシュ破損／UWP 登録不整合／WindowsApps ACL ずれ／依存フレームワーク未導入Store 正常化 → UWP 再登録 → ACL 修復 → 手動で Microsoft.UI.Xaml 2.8 を導入
vsdebugeng.impl.resources.dll が見つからないリモート デバッガーのビット数／バージョン不一致、VS 側のターゲット アーキテクチャ不整合OS に合う x64/x86/ARM64 用デバッガー入れ直し → プロジェクトを AnyCPU から固定
Store/Notepad が起動しないUWP 登録破損・Store 依存サービス停止・干渉ソフトStore 正常化手順一式、VPN/AV の一時無効化、必要なら SFC/DISM

UWP アプリの展開が「Installing missing frameworks…」で止まる問題

1) Microsoft Store を正常化する

依存フレームワーク（Microsoft.UI.Xaml.2.8 など）の自動取得は、内部的に Store 機構に依存します。Store が不安定だとダウンロードが進まず、既定の「フレームワーク不足」ダイアログやログだけを残して止まります。

サインインを Microsoft アカウントに切り替える

  • ローカル アカウントや Azure AD のみで使用中の場合でも、Store は個人の Microsoft アカウントでサインインすると復旧率が上がります。
  • Store アプリ右上のプロフィール → 既存アカウントから切替または新規サインイン。

Store キャッシュのクリア

  1. Win+R → wsreset.exe → 10〜60 秒待機（黒いコンソールが閉じて Store が自動起動すれば成功）。

UWP アプリの再登録（管理者 PowerShell）

Windows 全体の AppX 登録が歪んでいると、依存関係グラフの解決に失敗します。以下を実行して登録を再構築します。

Get-AppXPackage | Foreach {
  Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

完了後は 必ず再起動 してください。

2) WindowsApps フォルダーのアクセス権を修復

%ProgramFiles%\WindowsApps は UWP の実体を格納する特殊フォルダーです。オーナーは既定で NT Service\TrustedInstaller。誤った所有権変更や不完全なバックアップ復元などで ACL が崩れると、展開も起動も失敗します。

重要な注意: 本手順は高度です。レジリエンス確保のため、可能ならば復元ポイント作成・完全バックアップの取得 を推奨します。誤設定は UWP 全体を起動不可にします。

基本コマンド（管理者 CMD）

takeown /f "%ProgramFiles%\WindowsApps"
cacls "%ProgramFiles%\WindowsApps" /s:<既定ACL文字列>
icacls "%ProgramFiles%\WindowsApps" /setowner "NT Service\TrustedInstaller"
  • cacls の <既定ACL文字列> は長大かつビルド依存です。ここでは割愛します。
  • 実行途中で確認が出たら Y で承認してください。

より安全な代替案（推奨）

  1. 正常な同一ビルドの Windows 11 から ACL をエクスポート icacls "%ProgramFiles%\WindowsApps" /save "%TEMP%\WindowsApps.acl" /t
  2. 対象マシンへファイル転送後、対象マシンで 所有権を一時取得 → ACL 復元 → 所有者を戻す takeown /f "%ProgramFiles%\WindowsApps" /r /d y icacls "%ProgramFiles%\WindowsApps" /restore "%TEMP%\WindowsApps.acl" icacls "%ProgramFiles%\WindowsApps" /setowner "NT Service\TrustedInstaller" /t

操作後は 再起動 してから動作を確認します。

3) 不足フレームワーク（Microsoft.UI.Xaml 2.8）を手動インストール

Store からの自動取得がうまくいかない場合は、NuGet の Microsoft.UI.Xaml（WinUI 2.x）パッケージから該当アーキテクチャの .appx を取り出して手動導入します。

  1. 開発機で Microsoft.UI.Xaml.2.8 の .nupkg を取得。
  2. .nupkg の拡張子を .zip に変更して解凍。
  3. tools\AppX\x64\Release\Microsoft.UI.Xaml.2.8.appx（ターゲットが x64 の場合）をリモート PC にコピー。
  4. リモート側でダブルクリックしてインストール、または PowerShell で明示導入： Add-AppxPackage -Path "C:\Path\To\Microsoft.UI.Xaml.2.8.appx"

導入後、以下で存在を確認できます。

Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "Microsoft.UI.Xaml*" } |
  Select-Object Name, Version, Architecture

4) Windows SDK の最新バージョンを追加インストール

プロジェクトの TargetPlatformVersion に対して SDK が不足していると、依存解決が途中でこけることがあります。Visual Studio Installer から最新の Windows SDK（UWP/デスクトップ両方）を追加してください。導入後は VS を再起動します。

5) Visual Studio で「クリーン → リビルド → デプロイ」

  • ソリューション 右クリック → クリーン → リビルド → 対象デバイス（リモート）に デプロイ
  • パッケージ依存関係の自動解決が復活していれば、ここでフレームワークが自動取得され、デバッグが始まります。

イベントログとログでの検証

  • イベント ビューアー → Microsoft-Windows-AppXDeployment/Operational を確認（インストール開始／失敗コード／再試行が記録）。
  • %ProgramData%\Microsoft\VisualStudio\Packages\_bootstrapper\ 付近のログも参考になります。

リモートデバッグで「vsdebugeng.impl.resources.dll が見つからない」エラー

フレームワーク問題が解決しても、デバッグ接続時に DLL が見つからないエラーが続くケースがあります。多くは アーキテクチャ不一致、あるいは デバッガーのバージョン差 に起因します。

1) リモート デバッガーを正しいアーキテクチャで再インストール

  • リモート PC の OS に合わせて x64 / x86 / ARM64 版を選択して入れ直します。
  • リモート デバッガー（msvsmon.exe）は Visual Studio 2022 と同世代を用いるのが原則です。
  • インストール後は 管理者として起動 し、必要に応じて「Windows 認証 / ユーザー名とパスワードの指定」を設定します。

2) プロジェクトのターゲットを固定（AnyCPU を使わない）

UWP の実行は実デバイスのアーキテクチャに依存します。ソリューション プラットフォーム を x64（または対象通り）に設定し、AnyCPU は避けます。ライブラリも含めて同一に揃えてください。

3) クリーン → リビルド → リモート デプロイ

DLL エラーが消え、通常どおり接続・ブレークポイント命中が可能になります。

ファイアウォールとサービスの基本チェック

  • Windows セキュリティ → ファイアウォールで リモート デバッガー が「プライベート ネットワーク」で許可されているか確認。
  • サービス（DiagTrack / AppXSVC / ClipSVC）が無効化されていないか確認。無効化は UWP 展開に悪影響です。

Microsoft Store やメモ帳など組み込み UWP アプリが起動しない

Store や Notepad が無反応でエラーも出ない場合、§1 の Store 正常化と UWP 再登録 で大半が復旧します。さらに以下を実施すると回復が早まります。

アプリ単体のリセット／修復

  1. 設定 → アプリ → インストール済みアプリ → 対象（例：Microsoft Store / メモ帳）→ 詳細オプション
  2. 修復 → リセット の順に試す（ユーザー データが初期化される点に注意）。

サードパーティ製 VPN / アンチウイルスの一時無効化

UWP のネットワーク サンドボックスや Store チャネルに干渉し、依存ダウンロードが失敗する事例があります。一時的に無効化またはアンインストールして切り分けます。

システムファイルとイメージの整合性チェック

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

完了後に再起動し、Store/Notepad が起動するかを確認します。

再発防止のための設定と運用のコツ

  • 開発者モードを有効化：設定 → プライバシーとセキュリティ → 開発者向け → 開発者モード。
  • ビルドの整合性：リモート PC と開発 PC は、可能な限り同一の Windows ビルドと更新レベルにそろえる。
  • Visual Studio / 拡張機能の更新：Installer で定期更新。古い VS 付属のデバッガーは不整合の温床。
  • NuGet パッケージの固定：WinUI 2.x のメジャー差は依存関係が変わります。CI では packages.lock.json を有効に。
  • ACL を触る前にバックアップ：icacls /save で「戻せる状態」を作ってから作業する。

詳解：なぜ「Installing missing frameworks…」で止まるのか

VS からの UWP デプロイは、(1) パッケージのビルド → (2) 依存の解決（Store/ローカル）→ (3) 展開 → (4) 登録 → (5) 起動 の流れで進みます。WinUI 2.x（Microsoft.UI.Xaml）は フレームワーク パッケージ であり、アプリ本体とは別に 対象デバイスへ常駐させる必要があります。Store のキャッシュ破損・UWP 登録の不整合・WindowsApps の ACL 崩れがあると、(2) と (4) に失敗して進行が停止します。今回の手順はそのボトルネックを上流から直列に解消しているため、成功率が高いわけです。

コマンド＆操作まとめ（コピペ用）

Store キャッシュのクリア（実行ダイアログ）

wsreset.exe

UWP の再登録（管理者 PowerShell）

Get-AppXPackage | Foreach {
  Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

WindowsApps ACL（慎重に）

takeown /f "%ProgramFiles%\WindowsApps"
cacls "%ProgramFiles%\WindowsApps" /s:&lt;既定ACL文字列&gt;
icacls "%ProgramFiles%\WindowsApps" /setowner "NT Service\TrustedInstaller"

より安全な ACL 復元（推奨）

:: 正常機からエクスポート
icacls "%ProgramFiles%\WindowsApps" /save "%TEMP%\WindowsApps.acl" /t

:: 対象機で適用
takeown /f "%ProgramFiles%\WindowsApps" /r /d y
icacls "%ProgramFiles%\WindowsApps" /restore "%TEMP%\WindowsApps.acl"
icacls "%ProgramFiles%\WindowsApps" /setowner "NT Service\TrustedInstaller" /t

Microsoft.UI.Xaml.2.8 の手動導入（PowerShell）

Add-AppxPackage -Path "C:\Path\To\Microsoft.UI.Xaml.2.8.appx"
Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "Microsoft.UI.Xaml*" } |
  Select-Object Name, Version, Architecture

システム整合性

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

よくある落とし穴と回避策

  • 「Any CPU」のままデプロイ：UWP では実機アーキテクチャに一致しないと依存解決が崩れます。x64 などに固定。
  • 企業環境のプロキシ／証明書ピンニング：Store のバックエンドに接続できず依存取得が止まります。プロキシ例外や証明書ストアを確認。
  • 過去のバックアップからの WindowsApps フォルダー単体復元：ACL ズレの主因になります。復元は必ず OS レベルの機能で行う。
  • アンチウイルスのリアルタイム保護：Appx 展開のテンポラリを隔離しがち。ビルド/デプロイ時は除外設定を。

トラブルシューティング チェックリスト

確認項目OK の基準
□Store で Microsoft アカウントにサインインプロフィールが正しく表示され、アプリ取得が可能
□wsreset.exe 後に Store が自動起動起動・検索が正常
□UWP 再登録を実施エラーなく完走し、再起動済み
□WindowsApps ACL を確認所有者が NT Service\TrustedInstaller
□Microsoft.UI.Xaml 2.8 が存在Get-AppxPackage で x64 の行が表示
□Windows SDK を最新化プロジェクトの TargetPlatformVersion と整合
□プロジェクトのプラットフォームを固定x64 等に統一
□リモート デバッガーのアーキテクチャ一致OS と同じ（x64/x86/ARM64）

ケーススタディ：現場での再現と復旧ログ

以下は実際の現場での典型的な経路です。

  1. VS からデプロイ → Installing missing frameworks… で 10 分以上停止。
  2. Store サインイン → wsreset → UWP 再登録 → 再起動 で再試行 → まだ止まる。
  3. イベント ログに 依存フレームワークが見つからない 旨の記録。
  4. Microsoft.UI.Xaml 2.8 の .appx を手動導入 → Get-AppxPackage で確認。
  5. VS でクリーン → リビルド → デプロイ → 起動成功。
  6. 続けてデバッグ接続で vsdebugeng.impl.resources.dll が見つからない。
  7. リモート デバッガー（x64）を入れ直し、プロジェクトを x64 固定 → 接続成功。

補足：ログの読み方とエラーコードの目安

  • 0x80073CF3（パッケージ更新失敗）：依存関係不一致。WinUI 2.8 などが未導入。
  • 0x80073CFB（インストール失敗）：Store/サービス停止、ACL 問題の可能性。
  • 0x80070005（アクセス拒否）：WindowsApps の所有権や ACL を点検。

安全に進めるためのベストプラクティス

  1. 変更は上流から小さく：Store 正常化 → UWP 再登録 → 手動導入 → ACL の順で。逆走しない。
  2. バックアップを先に：ACL は icacls /save、レジストリや重要データは影響外に退避。
  3. 検証を挟む：各ステップ後に必ず Get-AppxPackage とイベント ログで効果を確認。
  4. 環境差分の見える化：PowerShell で OS ビルド、SDK、インストール済みフレームワークを採取しておくと、横展開が容易。

トラブルが解消した後にやること

  • CI/CD の段階で依存を検証：ビルド成果物に .appx の依存一覧を添付し、展開前にチェックする仕組みを用意。
  • 開発基盤の標準化：VS の Workload と Windows SDK バージョンをチームで固定。オンボーディング時間を削減。
  • ヘルスチェック スクリプトの整備：本記事のコマンド群をバッチ化しておくと、再発時の初動が早まります。

まとめ

「Installing missing frameworks…」の停止は、ほぼ必ず Store 経由の依存取得 と UWP 登録／ACL の健全性 に帰着します。順序立てて正常化し、必要なら Microsoft.UI.Xaml を手動導入。そこを乗り越えたら、リモート デバッガーは OS と同じアーキテクチャで入れ直し、プロジェクトのターゲットを固定。たったこれだけで、デプロイ停止 → DLL 不足という二段構えの障害は高確率で解消します。最後に SDK と VS を最新へ保ち、同一ビルドでそろえる――この基本を徹底すれば、同類のトラブルはぐっと減らせます。

付録：作業チェックログ（テンプレート）

[日付]:
[対象PC]: HostName / Windows 11 build:
[Store]: MS アカウントサインイン / wsreset 実行済
[UWP再登録]: 実施 / エラーなし / 再起動済
[WindowsApps ACL]: 所有者 TrustedInstaller / 差分なし
[WinUI]: Microsoft.UI.Xaml.2.8 x64 導入済 (Version: )
[SDK]: Windows SDK (10.0.x.x) 追加
[VS設定]: プラットフォーム x64 固定 / クリーン→リビルド→デプロイ
[RemoteDebugger]: x64 版 / 同世代 / 管理者起動
[結果]: デプロイ成功 / デバッグ接続成功
[イベントログ]: AppXDeployment/Operational エラーなし
[備考]:
Visual Studio
PowerShell Windows 11 リモートデバッグ Visual Studio 2022 UWP Microsoft.UI.Xaml

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次