Windows Server 2019 上で .NET MAUI の自己完結型 EXE を動かそうとして、起動直後に coreclr.dll の 0xc0000005（Access Violation）でクラッシュ…というトラブルは、実は .NET MAUI／WinUI 3 と Windows Server の相性問題が背景にあります。本記事では、なぜこの現象が起きるのか、公式サポート状況と既知のバグ、そして実務レベルで取り得る回避策を整理して解説します。
Windows Server 2019 で .NET MAUI 自己完結 EXE がクラッシュするシナリオ
今回のケースは、だいたい次のような構成です。
- .NET 9（または .NET 8/10 系）＋ .NET MAUI を使用
- Windows 向けに自己完結型 EXE（self-contained）で発行
WindowsPackageType=None（＝MSIX ではなく「生 EXE」）- 発行コマンド例：
dotnet publish -f net9.0-windows10.0.19041.0 -c Release ^ -p:WindowsPackageType=None ^ -p:WindowsAppSDKSelfContained=true ^ -p:RuntimeIdentifierOverride=win10-x64 ^ --self-contained - 配置先 OS：Windows Server 2019
この構成で EXE を起動すると、アプリのウィンドウが出る前に落ちてしまい、イベントログには次のようなエラーが記録されます。
- 障害のあるアプリケーション名：<アプリ名>.exe
- 障害のあるモジュール名：
coreclr.dll - 例外コード：
0xc0000005（Access Violation）
重要なのは、「管理コード（C# 側）の例外」ではなく「CLR ランタイム DLL（coreclr.dll）のネイティブクラッシュ」である点です。つまり、あなたのアプリコードが動き出す前に、ランタイムと OS まわりの相性で落ちている可能性が高い、ということです。
.NET MAUI／WinUI 3 と Windows Server のサポート状況
.NET MAUI の Windows 対応は「クライアント OS 前提」
.NET MAUI の公式ドキュメントでは、Windows 向けアプリの対応プラットフォームとして次のように明記されています。
- Windows 11
- Windows 10 バージョン 1809 以降
- UI フレームワークは WinUI 3 を使用
ここに「Windows Server 2019 / 2022」といったサーバー OS の記載はありません。
また、別の公式情報でも「.NET MAUI で Windows アプリをビルドすると、WinUI 3 を使うため、実行対象は Windows 10 1809 以降と Windows 11 になる」と説明されています。
つまり、.NET MAUI の Windows サポートはあくまで「クライアント OS を前提」に設計されており、Windows Server 系列はテストもサポートもされていない、という立ち位置です。
Q&A でも「Server は対象外」と明言されている
Microsoft Q&A では、Windows Server 2016 や 2019 で .NET MAUI アプリが動かないという質問に対して、公式回答として「.NET MAUI の Windows ターゲットは Windows 11 と Windows 10 1809 以降であり、Server OS は含まれない」といった趣旨の説明がなされています。
また、WinUI 3 自体についても、「Windows Server 2019 上での動作は保証されていない」といった議論が GitHub の issue で繰り返されており、Server 2019 で WinUI 3 ベースのアプリ（＝.NET MAUI Windows アプリ）が不安定になるのは珍しい話ではありません。
OS ごとのサポート状況まとめ
| OS | .NET MAUI Windows の公式サポート | コメント |
|---|---|---|
| Windows 11 | ◯（正式サポート） | WinUI 3 ベースでテストされているメインターゲット。 |
| Windows 10 1809 以降 | ◯（正式サポート） | 企業 PC などのクライアント環境向け。LTS 版も多く運用されている。 |
| Windows Server 2022 | △（公式には明記なし） | 内部バージョンは Windows 10 21H2 系であり、動くケースは多いが、公式サポート対象とは書かれていない。 |
| Windows Server 2019 | ×（サポート外） | 公式ドキュメントに記載なし。Q&A や GitHub でも「動作保証外」として扱われている。 |
| Windows Server 2016 / 2012 R2 など | ×（サポート外） | OS の世代が古く、WinUI 3 / Windows App SDK の前提を満たさない。 |
0xc0000005（Access Violation）が発生する背景
管理コードではなく「CLR ランタイムのネイティブクラッシュ」
0xc0000005 は、Windows でおなじみの「メモリアクセス違反」を表す例外コードです。C# で throw した通常の例外とは異なり、次のような場面で発生します。
- ネイティブ DLL が不正なアドレスを参照した
- CPU 命令と実行環境（アーキテクチャ／OS ビルド）の前提が食い違っている
- ランタイムが内部的に使用している API が OS に存在しない／挙動が違う
.NET MAUI Windows アプリの場合、実際に落ちているのは coreclr.dll（.NET ランタイム）や Windows App SDK／WinUI 3 のネイティブ DLL であるケースが多く、「アプリ本体の C# コードに到達する前」に OS との相性でクラッシュしていることがよくあります。
self-contained（自己完結）EXE が問題を増幅する理由
self-contained EXE として .NET MAUI アプリを発行すると、次のような構成になります。
- .NET ランタイム一式（coreclr.dll など）
- アプリのアセンブリ／リソース
- Windows App SDK のネイティブ DLL 群
一見すると「全部同梱されているなら、どこでも動きそう」に思えますが、実際には次のような OS 側の前提に強く依存しています。
- WinUI 3 が前提とする Windows API（COM コンポーネントやシステム DLL）のバージョン
- Windows App SDK のブートストラップ処理が想定している OS ファミリ
- フォント／DirectX／グラフィックスドライバー周りの機能
Server 2019 では、これらの前提条件が Windows 10/11 クライアントと完全に一致しておらず、「必須機能はあるがバージョンが古い」「存在することを想定していたコンポーネントがインストールされていない」といったズレによって、coreclr.dll や WinUI 3 の初期化中にアクセス違反を引き起こしてしまいます。
まず行うべき調査：Debug ビルドでのスタックトレース取得
Release ビルドだけでは情報が足りない
Microsoft Q&A でも、今回と同様のケースに対して「まず Debug ビルドで発行し、詳細なスタックトレースを取得するべき」と案内されています。
理由はシンプルで、Release ビルドでは最適化やトリミングが効いているため、どの DLL のどの関数で落ちたのかが Event Viewer からは追いにくくなるからです。
Debug で self-contained を発行する例
一度、次のように Debug ビルドで self-contained 発行してみましょう。
dotnet publish -f net9.0-windows10.0.19041.0 -c Debug ^
-p:WindowsPackageType=None ^
-p:WindowsAppSDKSelfContained=true ^
-p:RuntimeIdentifierOverride=win10-x64 ^
--self-containedそのうえで、サーバー上で起動してクラッシュさせ、次の情報を確認します。
- Windows のイベントビューアー（アプリケーションログ）のエラー詳細
- スタックトレースに WinUI／WindowsAppSDK／グラフィックス関連 DLL が含まれていないか
- シンボルが解決できるなら、どの関数呼び出しで Access Violation が発生しているか
ここで「ユーザーコードが一切出てこない」のであれば、OS とランタイムの相性問題である可能性が非常に高くなります。
より踏み込んだ解析（必要な場合）
本格的に Microsoft にフィードバックするつもりがある場合は、次のツールでクラッシュダンプを採取しておくと良いでしょう。
- ProcDump（
procdump -e -ma <PID>など） dotnet-dumpコマンド- WinDbg での手動アタッチ
ただし、サポート対象外 OS である以上、「バグとして受け付けられても修正予定なし（not planned）」となる可能性が高い点には注意が必要です。
Windows Server 2019 ＋ self-contained EXE の既知の問題
Server 2019 では「起動すらしない」ケースが多数報告
GitHub や Q&A では、Server 2019 上で self-contained な .NET MAUI / WinUI 3 アプリを実行すると、次のような症状が報告されています。
- EXE を起動してもウィンドウが一瞬出てすぐ消える（イベントログには coreclr.dll の 0xc0000005）
- 何も画面に出ず、イベントログにもほとんど情報が残らない
- Windows App SDK をインストールしようとしても途中でクラッシュする
- Server 2019 だけで発生し、Windows 10 / 11 では正常に動作する
なかには「GitHub issue が立てられたものの、Server 2019 がサポート対象外であるため closed as not planned になった」というパターンもあり、根本的な修正が入る見込みは薄い状況です。
「動く環境」と「動かない環境」の差分
興味深いのは、同じバイナリでも以下のような差分で挙動が変わることです。
- Windows 10 上：self-contained EXE で問題なく起動
- 別の Windows 10 / 11 上：Windows App SDK ランタイムを事前インストールすると起動する
- Server 2019 上：Windows App SDK のインストール時点でクラッシュし、アプリも起動しない
このことから、「self-contained だから OS 非依存で動く」のではなく、「self-contained でも OS に強く依存している」ことが分かります。
実務的な回避策：どの道を選ぶべきか
ここからは、運用現場で現実的に取りうる回避策を整理します。
| 方策 | 概要 | Server 2019 のクラッシュ回避期待度 |
|---|---|---|
| MSIX パッケージで配布 | WindowsPackageType=MSIX で発行し、App Installer からインストール。 | 高（ただし Server 2019 自体が非サポートである点は変わらない） |
| self-contained をやめる | WindowsAppSDKSelfContained=false にし、OS 側に Windows App SDK ランタイムを配置。 | 中〜高（環境によっては改善） |
| サポート対象 OS へ移行 | Windows 10 / 11 または Server 2022 へプラットフォームを移行。 | 最高（最も再現性が高く、ベストプラクティス） |
| ビルドオプションを緩和 | PublishTrimmed / PublishSingleFile を無効化するなど。 | 中（クラッシュするコードパスを避けられることがある） |
| SDK / ツール更新 ＋ ダンプ解析 | .NET / Windows App SDK / VS を最新化し、クラッシュダンプを採取。 | 中（既知バグ修正の恩恵を受けられる可能性） |
MSIX パッケージで配布する
.NET MAUI の公式ドキュメントと Q&A では、「Windows アプリを配布する際は MSIX パッケージとして配布し、App Installer からインストールする」ことが推奨されています。
ポイントは次の通りです。
- インストール時に必要なランタイムや依存コンポーネントが適切に登録される
- ショートカットやスタートメニュー統合、アンインストールなどが OS の仕組みで管理される
- エンドユーザーにとって「信頼されたアプリ」として扱われやすい
発行コマンドの例：
dotnet publish -f net9.0-windows10.0.19041.0 -c Release ^
-p:WindowsPackageType=MSIX ^
-p:GenerateAppxPackageOnBuild=trueMSIX にしたからといって Server 2019 が「サポート OS になる」わけではありませんが、「self-contained 生 EXE よりは動作が安定する」ケースが多く見られます。
Windows App SDK を OS 側にインストールし、自己完結をやめる
もう一つの発想は、「self-contained をやめて OS にランタイムを任せる」方法です。具体的には以下のようにします。
- プロジェクトファイル（.csproj）で：
<PropertyGroup> <WindowsAppSDKSelfContained>false</WindowsAppSDKSelfContained> </PropertyGroup> - 発行時に
--self-containedを指定せず、framework-dependent として出力 - サーバー側に対応バージョンの Windows App SDK ランタイムと .NET ランタイムをインストール
実際、Windows 10 クライアントでは「Windows App SDK をインストールしたら MAUI EXE が起動するようになった」という報告があり、この構成変更によって Server 2019 でも起動できるようになるケースがあります。
ただし、先述の通り Server 2019 自体がサポート外であるため、「環境によっては改善する」程度の期待値に留めておくのが現実的です。
サポート対象 OS（Windows 10 / 11 / Server 2022）への移行
根本的には、.NET MAUI を本番運用するなら「公式サポート対象 OS に乗せる」のが最も安全です。具体的には次のような選択肢があります。
- クライアント PC：
- Windows 10 22H2（長期運用が必要なら LTSC エディション）
- Windows 11 23H2 以降
- サーバー OS（RDS／VDI 向け）：
- Windows Server 2022（内部的には Windows 10 21H2 系）
RDS や VDI 環境で MAUI クライアントを提供したい場合も、「Server 2019 上で無理に動かす」より「Server 2022 ＋ Windows 10/11 クライアント相当の環境」を用意した方が、長期的なトラブル回避につながります。
ビルドオプションを緩和してトリミング／単一ファイル化を無効化
自動トリミングや単一ファイル化はとても便利ですが、ネイティブとの絡みが複雑な .NET MAUI では思わぬ副作用を生むことがあります。特に：
PublishTrimmed=trueによって必要な型／メソッドが誤って削除されるPublishSingleFile=trueで単一ファイルにまとめることで、特定環境でのロード順やパス解決が変わる
Server 2019 でのみ発生するクラッシュの場合、「環境依存の微妙な違い」がこれらの最適化と組み合わさり、coreclr.dll での Access Violation につながる可能性があります。まずは次のようにオプションを緩和し、ふるまいが変わるかを確認してみてください。
<PropertyGroup>
<PublishTrimmed>false</PublishTrimmed>
<PublishSingleFile>false</PublishSingleFile>
</PropertyGroup>サイズは大きくなりますが、「とにかくクラッシュを止めて原因を切り分けたい」という段階では有効なアプローチです。
最新 SDK への更新とクラッシュダンプによる切り分け
.NET MAUI や Windows App SDK は、リリースごとに多数のバグ修正が入っています。Visual Studio 17.x 系の更新だけで Windows 向け MAUI アプリの起動問題が解消された事例もあります。
そのため、次の順で環境をアップデートしていくことを推奨します。
- .NET SDK を最新の LTS／最新安定版へ更新
- Visual Studio（または CLI）側の .NET MAUI workload を最新に更新
- Windows App SDK のランタイム／フレームワークパッケージを最新版へ
それでも解決しない場合は、前述の通りクラッシュダンプを取得し、「Server 2019 固有の問題なのか」「特定のドライバーやサードパーティ DLL が絡んでいるのか」を切り分けていくと、別の回避策が見えてくることがあります。
用途別：どの構成を選ぶべきかの目安
| 利用シナリオ | 推奨 OS | 推奨配布形態 | Server 2019 利用時の注意 |
|---|---|---|---|
| 社内クライアント PC での業務アプリ | Windows 10 1809+ / 11 | MSIX（ストア外配布ならサイドロード） | Server 2019 は避ける。どうしても必要なら RDS/VDI 上のクライアント OS を利用。 |
| RDS / VDI 上でのマルチユーザー利用 | Windows Server 2022 | MSIX ＋ ユーザー別プロファイル | 2019 では coreclr.dll クラッシュのリスクが高い。検証しても安定しなければ移行必須。 |
| オンプレ GUI 管理ツール | Windows 10/11 または Server 2022 | MSIX または framework-dependent EXE | Server 2019 での自己完結 EXE は避ける。WPF/WinForms など別フレームワークへの切り替えも検討。 |
| ライトなユーティリティ／診断ツール | Windows 10/11 | self-contained でも可だが、トリミングは慎重に | Server 2019 では self-contained より MSIX＋ランタイム分離の方が安全。 |
どうしても Windows Server 2019 で動かしたい場合のチェックリスト
サポート対象外であることを理解したうえで、それでも「既存の Server 2019 環境からすぐには動かせない」というケースもあると思います。その場合に試してみる価値があるチェックポイントをまとめます。
- アプリを Debug ビルドで self-contained 発行し、詳細なスタックトレースを確認する
PublishTrimmed=false、PublishSingleFile=falseにして再度テストするWindowsAppSDKSelfContained=falseにして、Windows App SDK ランタイムをサーバーにインストールする- MSIX パッケージとして発行し、App Installer からインストールしてみる
- .NET SDK / Windows App SDK / Visual Studio を最新に更新する
- グラフィックスドライバーやリモートデスクトップ環境（GPU 仮想化など）の設定を確認する
- それでもダメなら、クラッシュダンプを採取し、「MAUI＋Server 2019 の組み合わせ自体が限界」かどうかを判断する
このチェックリストのどこかで「Windows 10 / 11 では正常に動くのに Server 2019 ではどうしてもダメ」という状態まで確認できれば、「アプリ側ではなく OS サポート範囲の問題」と社内に説明しやすくなります。
.NET MAUI が合わない場合の代替案
「Windows Server 上で GUI アプリを動かしたいだけ」であれば、必ずしも .NET MAUI にこだわる必要はありません。代替として考えられる選択肢をいくつか挙げます。
- WPF / WinForms (.NET 8/9)
Server 2019 / 2022 での実績が豊富で、self-contained EXE との相性も比較的良好です。 - 純 WinUI 3 デスクトップアプリ
こちらもサポート対象は Windows 10/11 ですが、「MAUI なしで WinUI 3 だけを使う」ことで依存関係を減らし、問題切り分けをしやすくできます。 - ブラウザベースの管理画面（Blazor / ASP.NET Core）
GUI を Web 化し、サーバー側は IIS／Kestrel 上の Web アプリとして動かす構成です。クライアント OS 依存を最小限にできます。
.NET MAUI は「モバイル＋デスクトップを単一コードベースで」という点では非常に魅力的ですが、「Windows Server 上で thick client 的に使う」用途には向いていません。用途に合わせてフレームワークを選びなおすのも、長期的に見れば堅実な選択です。
まとめ：原因と最も現実的な解決策
ここまでの内容を整理すると、今回の「Windows Server 2019 上で .NET MAUI 自己完結 EXE が起動直後に coreclr.dll で 0xc0000005 を出して落ちる」問題は次のように理解できます。
- 原因の本質：
- .NET MAUI / WinUI 3 の Windows 対応は、Windows 10 1809 以降と Windows 11 のクライアント OS を前提にしている
- Windows Server 2019 は公式サポート対象外であり、WinUI 3 / Windows App SDK の前提と OS の実装が微妙にズレている
- self-contained EXE では、そのズレが coreclr.dll などのネイティブクラッシュとして顕在化しやすい
- もっとも確実な対処：
- サポート対象 OS へ移行する（Windows 10/11 または Server 2022）
- MSIX パッケージとして配布し、App Installer 経由でインストールする
- 当面の応急策として試せること：
- Debug ビルドでスタックトレースを取り、ユーザーコードではなくランタイム側で落ちていることを確認する
PublishTrimmed=false、PublishSingleFile=false、WindowsAppSDKSelfContained=falseなど、ビルドオプションを緩和して挙動の変化を確認する- .NET SDK / Windows App SDK / Visual Studio を最新化しつつ、クラッシュダンプを用意しておく
「Server 2019 でもたまたま動いている MAUI アプリ」は今後も存在し得ますが、それはあくまで「たまたま」であり、いつ壊れてもおかしくない地盤の上に立っています。Windows 向け .NET MAUI アプリを業務で長期運用するなら、「クライアント OS への移行」と「MSIX によるパッケージ配布」を前提に設計し直すことを強くおすすめします。
コメント