UWP アプリを Release（.NET Native 有効）で F5 起動した途端にアプリが即落ちし、Visual Studio まで固まる――。開発の現場で一度は遭遇するこの厄介な症状を、「なぜそうなるのか」「どう切り分け、どう直すか」を実務目線で体系化しました。Ctrl+F5 の応急回避から、.NET Native 特有の落とし穴（反射メタデータ、AOT 最適化、ABI 非互換）まで、手戻りなく原因に辿り着くための決定版ガイドです。
現象の整理（再掲と補強）
- Debug ビルド（.NET Native 無効）：正常起動・デバッグ可能。
- Release ビルド（.NET Native 有効）：F5（デバッグ付き実行）でアプリが即クラッシュ、Visual Studio もハング／クラッシュ。
- イベント ビューア：
Activation … failed. Error code: The app didn't start.等を出力。
この組み合わせは、アプリ側のクラッシュ（主因） + VS のデバッガ接続待ち（副作用）が重なって起きます。以降では両者を切り分け、最短で原因へ到達するための順路を示します。
Visual Studio がハングする理由（仕組みを理解する）
F5 実行時、Visual Studio は UWP パッケージを展開・登録し、起動直後のアプリ プロセスとデバッガ接続のハンドシェイクを行います。このときアプリが「デバッグ準備完了」のシグナルを返す前に異常終了すると、VS は「まだ起動中」と判断して待ち続け、UI が固まったように見えます。逆に Ctrl+F5（デバッグなし）ではハンドシェイク自体をスキップするため、VS は巻き込まれません。
| 起動方法 | デバッガ接続 | アプリ即死時の VS 影響 | 備考 |
|---|---|---|---|
| F5（デバッグ付き） | あり（ハンドシェイク必須） | 高い確率でハング/クラッシュ | アプリ応答前に落ちると VS が待ち続ける |
| Ctrl+F5（デバッグなし） | なし | VS は安定（巻き込まれない） | 再現確認・切り分けに最適 |
まず VS を固まらせない応急処置
- Ctrl+F5で起動し、VS を巻き込まずにクラッシュを再現・観察する。
- 壊れたインストールを一掃：
- Windows の 設定 > アプリ から該当アプリをアンインストール。
- Visual Studio を再起動し、クリーン > リビルド。
- デバッグ構成の確認：
- 一時的に Just My Code を無効化、ソース サーバー / シンボル サーバーを活用してコールスタックを深く追えるようにする。
- Release でも PDB（.pdb / .appxsym） を生成する設定にしておく（後述）。
30 分で原因に辿り着く切り分けルート
ステップ 1：.NET Native 固有かどうかの判定
Release から .NET Native ツールチェーンを一時的に無効化した派生構成（例：Release-NoNative）を作成して起動します。これで落ちなければ、.NET Native（AOT）特有の最適化・反射メタデータ・リンカ挙動が濃厚です。
ステップ 2：イベント ログと WER のクラッシュ ダンプ
- イベント ビューアで次のログを確認：
- Application and Services Logs > Microsoft > Windows > AppModel-Runtime / TWinUI-Operational / AppXDeployment-Server
The app didn't startの原因手掛かり（リソース解決失敗、マニフェスト不備、依存 DLL 読み込み失敗など）が記録されます。 - Windows Error Reporting（WER）でローカル ダンプ収集（管理者権限の PowerShell / コマンド プロンプト）：
reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApp.exe" /v DumpType /t REG_DWORD /d 2 /f reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "%LOCALAPPDATA%\CrashDumps" /fクラッシュ後、%LOCALAPPDATA%\CrashDumpsにダンプが出力されます。Visual Studio / WinDbg でスタックトレースを確認し、例外の種類（NullReferenceException、TypeInitializationException、AccessViolationExceptionなど）と崩壊点を特定します。
ステップ 3：直近で更新した NuGet を最優先で疑う
Release だけで落ちる場合、ABI 非互換・AOT 非対応・トリミング非対応の NuGet が原因のことが非常に多いです。特にグラフィクス／ネイティブ ライブラリ（例：SkiaSharp、Win2D、画像コーデック系）は要注意。直近更新分から 1 つずつバージョンをロールバックし、再ビルド・再展開で再現性を確認します。
ステップ 4：反射（リフレクション）依存の有無を疑う
.NET Native は未使用と判断した型・メンバーを積極的にトリミングします。JSON シリアライザ、DI コンテナ、MVVM フレームワーク等が 反射で型を動的生成する場合、Release だけ TypeLoadException / MissingMethodException が発生しやすく、起動直後に落ちる典型です。次のように Default.rd.xml にディレクティブを追加し、必要な型のメタデータを保持させます。
<Directives>
<Application>
<!-- 例：アセンブリ単位で動的アクセスを許可（まずは最小範囲で） -->
<Assembly Name="YourApp" Dynamic="Required All"/>
<!-- もしくは型単位で精密に指定 -->
<Type Name="YourApp.Models.Customer" Dynamic="Required All"/>
</Application>
</Directives>まずはクラッシュ点の名前空間／アセンブリに絞って適用し、アプリが起動するか確認。起動したら、保持範囲を最小化するよう調整します（不必要なメタデータ保持はバイナリ肥大・起動遅延の原因になります）。
ステップ 5：XAML / リソース / PRI の不整合チェック
- XAML の
x:Bindで Null 安全性が崩れていないか（Release ではインライン化され例外が顕在化しやすい）。 - ResourceDictionary の MergedDictionaries、テーマ リソースのキー名相違、resw / PRI の再生成漏れ。
- 画像・フォントなどの Content の Copy to Output Directory とパッケージ ビルド アクション設定。
ステップ 6：ネイティブ境界（C++/WinRT, P/Invoke）の ABI 点検
- アーキテクチャ一致（x86/x64/ARM）と Calling Convention の整合。
- 外部 DLL の存在場所（UWP は パッケージ内に同梱が必要）と DelayLoad の有無。
- 未初期化メモリ／解放後使用などは Release 最適化で顕在化、/Od や追加アサーションで炙り出す。
よくある落とし穴と対処テンプレート
| 症状 | 原因の目星 | 対処の定石 |
|---|---|---|
| 起動直後に落ちて VS も固まる | AOT 最適化とデバッガ ハンドシェイクの噛み合わせ | Ctrl+F5 で再現、イベント ログと WER ダンプ確認、VS 再起動・再展開 |
| Debug では起きないが Release で落ちる | .NET Native のトリミング、最適化、副作用順序 | Release-NoNative 構成で切り分け、rd.xml で必要型を保持 |
| JSON 反序列化で不定クラッシュ | 反射対象型がトリム済み | rd.xml に対象アセンブリ/型を追加、モデルに属性を付与 |
| SkiaSharp/Win2D 周辺でアクセス違反 | GPU/ドライバ差分・DirectX 初期化順 | 一時的に WARP（ソフトウェア）へ切替、バージョン ロールバック |
リソース読み込みで Activation failed | PRI/マニフェスト/配置不整合 | クリーン > リビルド、パッケージ再登録、リソース キー再確認 |
具体策 A：VS ハングを確実に回避する運用
- 再現観察は必ず Ctrl+F5（VS を安定させる）。
- 壊れたインストールの消し込み：
# PowerShell（開発者 PowerShell） Get-AppxPackage -Name YourApp_PackageName | Remove-AppxPackage # 必要なら再登録（パッケージ マニフェストのパスを指定） Add-AppxPackage -Register "C:\src\YourApp\AppxManifest.xml" -ForceApplicationShutdown - VS のキャッシュ・一時ファイルをクリーン（ソリューション一式の bin/obj を削除）。
具体策 B：Release でも読めるシンボルとログを仕込む
- Release で PDB を生成（プロジェクト > ビルド > 高度な設定）。UWP の .NET Native では .appxsym も活用。
- 初期化ブロックに障害検知ログ：起動直後に
App.OnLaunched等へログを書き、どこまで進んだか を確定させる。 - 例外ポリシーを一時的に強化し、
UnhandledExceptionとTaskScheduler.UnobservedTaskExceptionを集約してイベント ログへ出す。
// App.xaml.cs
sealed partial class App : Application
{
public App()
{
this.InitializeComponent();
this.UnhandledException += (s, e) =>
{
System.Diagnostics.Debug.WriteLine($"FATAL: {e.Exception}");
e.Handled = false; // 解析では握りつぶさない
};
TaskScheduler.UnobservedTaskException += (s, e) =>
{
System.Diagnostics.Debug.WriteLine($"UNOBSERVED: {e.Exception}");
};
}
}具体策 C：反射メタデータ（rd.xml）を最小コストで整備
反射を使う箇所を棚卸しし、アセンブリ単位 → 名前空間単位 → 型単位へ段階的に範囲を狭めます。Newtonsoft.Json 等の汎用シリアライザでは、JsonProperty 属性や DataContract/DataMember を付与して 必要なメンバーのみ を明示的に生存させるのがコスト最小です。
<Directives>
<Application>
<Assembly Name="YourApp.Models" Dynamic="Required Public" />
<Namespace Name="YourApp.ViewModels" Dynamic="Required Public" />
</Application>
</Directives>「とりあえず動かす」段階では Dynamic="Required All" でも構いませんが、最終的には Public もしくは型単位まで絞り込み、起動時間とパッケージ サイズを守ります。
具体策 D：NuGet パッケージの健全性を担保する
- packages.lock.json を有効化して解決バージョンを固定（ビルド環境差による “いつの間にか最新版” を防止）。
- グラフィクス／ネイティブ連携系は、既知の安定版へ戻す運用を用意（SkiaSharp, Win2D 等）。
- 破壊的変更が疑わしい場合は 1 つずつ バージョンを戻す（複数同時ロールバックは因果の判定が困難）。
具体策 E：グラフィクス/ドライバ由来の Release 専用クラッシュを避ける
DirectX の初期化順・機能レベル差・ドライバ個体差は、AOT による最適化でタイミングが変わると露呈しがちです。暫定対策として、GPU を強制的に WARP（ソフトウェア ラスタライズ）へ切り替えて切り分けます。アプリが起動するなら、GPU 周辺の初期化順やバージョン差が主因です。
// 例：Win2D/DirectX 初期化前に WARP を強制する疑似コード
var device = new SharpDX.Direct3D11.Device(
SharpDX.Direct3D.DriverType.Warp,
SharpDX.Direct3D11.DeviceCreationFlags.BgraSupport);最終的には、ドライバ更新・初期化順修正・不要な並列化の抑制で恒久対応します。
具体策 F：XAML とリソースの堅牢化
- x:Bind 先を可能な限り Null 許容にしない設計にし、
OnNavigatedToなどで確実に初期化。 - 大規模なリソース辞書は 遅延ロード（x:Load / ResourceDictionary.Source）で段階読込にし、起動直後の負荷と競合を下げる。
- PRI 再生成（クリーン > リビルド）でキーの取り違えを排除。Build Action と Copy to Output の整合を点検。
具体策 G：C++/WinRT・P/Invoke の地雷を除去
- CallingConvention と CharSet を明示し、署名の不一致を避ける。
- 構造体の LayoutKind（Sequential/Explicit）を一致させ、Packing の差でメモリ破壊を起こさない。
- UWP 制約により Win32 API の多くが使えないことを再確認（代替 API を使う）。
ビルド／CI 設計で未然防止する
- Release 検証ジョブ：CI で .NET Native を有効化した Release を常時ビルドし、Smoke Test だけでも自動起動して EventLog／ダンプを収集。
- 決め打ちリストア：packages.lock.json で依存を固定し、PR ごとに差分をレビュー。
- シンボル公開：符号付け済み PDB / appxsym をアーティファクト保管し、いつでもダンプを再解析できる状態を維持。
実務で使える「調査スクリプト／コマンド」集
アプリのパッケージ登録・削除
# 一覧
Get-AppxPackage | ? { $_.Name -like "*YourApp*" } | Select Name, PackageFullName
# 削除
Get-AppxPackage -Name YourApp_PackageName | Remove-AppxPackage
# 再登録（ローカル フォルダから）
Add-AppxPackage -Register "C:\src\YourApp\AppxManifest.xml" -ForceApplicationShutdownWER ローカル ダンプの有効化/無効化
# 有効化（前述）
reg add "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApp.exe" /v DumpType /t REG_DWORD /d 2 /f
# 無効化
reg delete "HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourApp.exe" /fMSBuild で Release PDB を確実に生成
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<DebugType>full</DebugType> <!-- portable でも可 -->
<DebugSymbols>true</DebugSymbols>
<GenerateAppxSymbolPackage>true</GenerateAppxSymbolPackage> <!-- .appxsym -->
</PropertyGroup>ケーススタディ（再現から修正まで）
ケース 1：SkiaSharp 更新後に Release だけ落ちる
- Ctrl+F5 で即落ち、VS は安定。イベント ログに
The app didn't start。 - WER ダンプを見ると
AccessViolationExceptionが Skia 初期化内で発生。 - SkiaSharp を 1 つ前の安定版へロールバック、GPU を WARP に一時切替で起動。
- 最終的に初期化順とディスパッチ（UI スレッド vs バックグラウンド）を修正し恒久対応。
ケース 2：JSON 反序列化で TypeLoadException
- Debug では再現せず、Release のみ。
- ダンプのコールスタックに Newtonsoft.Json。対象モデルがトリムされていた。
Default.rd.xmlにモデル名前空間を追加、DataContract/DataMemberで明示。- 再ビルドで起動安定化。保持範囲を型単位へ段階縮小。
チェックリスト（机の横に貼る版）
| チェック | やり方 | 期待結果 |
|---|---|---|
| VS を固めない | Ctrl+F5 で再現、壊れたパッケージはアンインストール | 原因調査に集中できる |
| .NET Native 固有の判定 | Release-NoNative 構成で起動 | Yes なら rd.xml / 反射 / AOT を疑う |
| イベント/ダンプの確保 | AppModel-Runtime ログ、WER ローカル ダンプ | 例外種別と崩壊点が読める |
| NuGet の絞り込み | 直近更新のみ 1 つずつロールバック | 不良バージョンを特定 |
| 反射メタデータ | rd.xml に最小範囲で保持を宣言 | TypeLoad/MissingMethod が消える |
| XAML/PRI 整合 | キー名/Build Action/PRI 再生成 | Activation 失敗が解消 |
| ネイティブ境界 | 署名/レイアウト/アーキ一致を再点検 | AccessViolation 等が沈静化 |
| シンボル保全 | Release PDB/appxsym の生成・保管 | ダンプから即時原因特定 |
FAQ：よくある疑問
Q. なぜアプリのクラッシュが VS のハングにつながる？
F5 起動では VS とアプリが「デバッグ準備完了」のハンドシェイクを行います。アプリが応答前に落ちると VS は応答待ちのままブロックし、固まったように見えます。
Q. The app didn’t start は何が悪い？
起動直後の初期化で未処理例外が上がるか、必要リソース/依存 DLL が見つからず異常終了した可能性が高いです。AppModel-Runtime のイベントと WER ダンプで、失敗箇所を特定します。
Q. Release だけで落ちるのはなぜ？
.NET Native により IL が AOT 変換・最適化され、未初期化・順序依存・反射メタデータ不足が露呈しやすいためです。Debug では JIT と寛容な最適化により顕在化しない問題が、Release で噴出します。
Q. まず何から手を付ければよい？
Ctrl+F5 → イベント/ダンプ → 直近の NuGet ロールバック → rd.xml の最小追加、の順が最短です。
結論（運用サマリ）
- VS ハングはデバッガ接続待ちが原因。Ctrl+F5で応急回避。
- Release 限定クラッシュは、反射メタデータ不足、NuGet の ABI/最適化非対応、ネイティブ境界の不整合が三大原因。
- イベント ログとWER ダンプで崩壊点を確認し、rd.xml・依存のロールバック・初期化順修正で恒久対応。
- CI で Release を常時検証し、packages.lock.json と シンボル保全で再発時の調査コストを最小化。
ワンポイント：グラフィクス系を更新した直後に発火したら、まず 前の安定版へロールバック。次に rd.xml と PRI を点検――この順序で多くの案件が 1 日以内に決着します。
付録：最小労力で再現性を高めるチェックポイント
- アプリ設定の 初期化ログを起動直後に残す。
- スプラッシュや最初のページで 例外の集約（握りつぶさない）。
- クラッシュ再現後は必ず アンインストール→再展開。古いパッケージが残ると謎症状が増殖します。
コピペで使えるテンプレ：問題報告書（社内向け）
【現象】Release (.NET Native) の F5 起動で即落ち、VS がハング
【再現手順】ソリューションを Release|x64 でビルド → F5
【期待】アプリが起動しブレーク可能
【実際】起動直後に停止、イベント ログに "The app didn't start"
【暫定回避】Ctrl+F5、アンインストール→クリーン→再展開
【調査結果】WER ダンプで TypeInitializationException。rd.xml に Models 名前空間を追加で解消
【恒久対策】rd.xml の最小化設定、packages.lock.json で依存固定、Release PDB/appxsym を CI で保管おわりに
UWP の Release クラッシュは「VS 側の問題」に見えて、実体は「アプリ側の起動直後例外 + デバッガ手順の副作用」の合成です。ハンドシェイクの仕組みを理解し、.NET Native の特性（AOT・トリミング・最適化）を踏まえた切り分けを行えば、闇雲な作業や無意味な再インストールを繰り返すことなく、原因に一直線で到達できます。この記事が現場の時短に役立てば幸いです。
コメント