ゲームがGameAssembly.dllでクラッシュする原因｜Unity IL2CPPはPlayer.logから切り分ける【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
これはWindowsの部品ではなく、そのゲーム専用に作られたファイルです
出典：Unity公式マニュアルのIL2CPPスクリプティングバックエンドとログファイルの保存場所、Windows IL2CPPビルドの生成ファイル一覧（2020.2版）、BepInEx公式ドキュメントのインストール概要とIL2CPP版の導入手順にもとづきます。2026年9月8日に確認しました。
Unity製のゲームが落ちたあと、イベントビューアーに「障害が発生しているモジュール名: GameAssembly.dll」と出ている。ファイル名だけでは何なのか見当がつかず、検索すると例によってDLLを配布するサイトが並びます。
ここで押さえておきたいのは、GameAssembly.dllはWindowsの部品ではなく、そのゲームをビルドしたときに生成された専用ファイルだということです。Unity公式の解説では「IL2CPPランタイムと、あなたのすべてのスクリプトコードを含むライブラリ」と説明されています。つまり中身はゲームごとに違います。他所から持ってきても意味がありません。
そして、このクラッシュにはWindowsのイベントビューアーより先に読むべきログがあります。Unityゲームが自分で書き出しているPlayer.logです。この記事では、その場所と読み方、MODを使っている場合の落とし穴に絞って整理します。例外コードやPCの安定性といった共通の話は、それぞれの記事へ送ります。
目次
前提GameAssembly.dllはゲーム専用に作られたファイル
Unityには、C#で書いたコードをどう動かすかを決める仕組みが2つあります。そのうちIL2CPPは、Unity公式の説明で「Intermediate Language To C++」の略とされ、コードを事前にネイティブコードへ変換して動かす方式です。この方式でWindows向けにビルドすると生成されるのがGameAssembly.dllです。
中身についてUnity公式は「IL2CPPランタイムと、あなたのすべてのスクリプトコードを含むライブラリ」と定義しています。ゲームのロジックそのものがネイティブコードへ変換されて詰まっているファイル、という位置付けです。
ここから2つのことが決まります。1つは、このファイルがゲームごと・ビルドごとに完全に別物だということ。同じ名前でも中身は共有されません。もう1つは、ここで落ちたということは、ゲームのスクリプト処理が動いている最中に異常が出たという手掛かりになるということです。ただし手掛かりであって、原因の確定ではありません。MODがゲーム関数に割り込んでいる場合も、PCのメモリが不安定な場合も、異常が検出される場所はここになりえます。
この定義が載っているUnity公式ページは、現行版から削除されています
GameAssembly.dllの説明は、Unity 2020.2以前のマニュアルに残っている「Windows IL2CPPビルドが生成するファイル」のページで読めます。現行のマニュアルには同じページがありません。定義自体はUnityが公式に示していたものですが、参照するときはアーカイブ版になる点を承知しておいてください。
見分けUnityPlayer.dllとは役割が違う
Unity製ゲームのクラッシュでは、UnityPlayer.dllが障害モジュールになることもあります。どちらが出たかで、最初に見る方向が変わります。
| 項目 | UnityPlayer.dll | GameAssembly.dll |
|---|---|---|
| 中身 | Unityエンジン本体のライブラリ | IL2CPPランタイムと、そのゲームのスクリプトコード |
| ゲームごとの違い | Unityのバージョンが同じなら共通しやすい | ゲームごと・ビルドごとに完全に別物 |
| 最初に疑う方向 | エンジン側の処理、描画、Unityバージョン固有の不具合 | ゲームのロジック、MOD、セーブデータや進行状態 |
| 存在するゲーム | Unity製ゲーム全般 | IL2CPPでビルドされたゲームのみ |
ただし両者はゲーム実行中ずっと連携しています。ゲーム側の処理が不正な状態を作り、最終的にエンジン側で落ちることもあれば、その逆もあります。「GameAssembly.dllだからエンジンは無関係」と切り離せるわけではありません。あくまで最初に見る方向を決めるための材料です。UnityPlayer.dll側が障害モジュールになっている場合の切り分けは、UnityPlayer.dllでクラッシュする原因で扱っています。
なお、自分の遊んでいるゲームがIL2CPPかどうかは、フォルダーを見れば判断できます。BepInEx公式のインストール案内では、IL2CPPを使うゲームは「il2cpp_data」というフォルダーを持ち、もう一方の方式（Mono）のゲームは「Managed」フォルダーを持つと説明されています。GameAssembly.dllとil2cpp_dataの両方があれば、IL2CPPと考えて差し支えありません。
最初に読むPlayer.logの場所と、見るべき部分
ここがこのクラッシュで最も重要な手順です。Unityゲームは実行中の情報を自分でログに書き出しており、Unity公式マニュアルはWindowsでの保存場所を次のように案内しています。
Player.logの場所%USERPROFILE%\AppData\LocalLow\CompanyName\ProductName\Player.log
エクスプローラーのアドレスバーに %USERPROFILE%\AppData\LocalLow と入力すると開けます。そこから開発会社名、ゲーム名の順にフォルダーをたどってください。AppDataは既定で非表示のため、直接たどる場合は隠しファイルの表示を有効にする必要があります。
読むのはファイル全体ではなく、末尾のクラッシュ直前の部分です。イベントビューアーは「GameAssembly.dllで落ちた」としか教えてくれませんが、Player.logには落ちる直前にゲームが何をしていたかが残っています。特定のシーン読み込みで毎回同じエラーが出ている、特定のアセットの読み込みに失敗している、といった具体的な情報が得られます。
注意点が1つあります。最後の1行を原因と決めつけないでください。Unityゲームは正常動作中も警告や例外をログに書きます。見るべきなのは「毎回クラッシュ直前に同じ異常が出ているか」です。1回だけの記録では判断材料になりません。2〜3回落として、共通して出るものを探してください。
MOD環境BepInExは版によってIL2CPPに対応していない
MODを入れているなら、ここが最有力の容疑者です。IL2CPPゲーム向けのMODは、ネイティブコードになったゲーム関数に直接割り込む形で動きます。ゲーム側がアップデートされてGameAssembly.dllが作り直されると、割り込む先の構造が変わり、MODが噛み合わなくなります。ゲームアップデート直後からクラッシュが始まったなら、まずここを疑ってください。
そのうえで、BepInExを使っている人が引っかかりやすい点があります。安定版として配布されているBepInExのドキュメントには「IL2CPPでビルドされたゲームは現時点でサポートしていない」と明記されています。IL2CPPに対応しているのは開発版（master）系統で、Windows向けにIL2CPP-win-x64とIL2CPP-win-x86が別々に用意されています。安定版を落としてIL2CPPゲームに入れても正しく動きません。
IL2CPP版のBepInExを導入している場合、ゲームを起動するとBepInEx/LogOutput.txtというログが生成されます。Player.logと合わせてこちらも確認してください。特定のプラグインを読み込んだ直後に止まっているなら、そのプラグインが原因です。
切り分けるときは、MODを1つずつ無効にするよりMODローダーごと外した完全な素の状態を先に作るほうが早く進みます。それで落ちなくなれば、Windowsにもドライバーにも手を付ける必要はありません。なお、ゲームを再インストールしてもMODが追加したファイルは残ることがあるため、フォルダーの中身も確認してください。
やってはいけないDLLの入手・コピーと、Unity Editorの導入
GameAssembly.dllで検索すると出てくるDLL配布サイトは、このファイルに関しては特に無意味です。中身がゲーム固有である以上、他所のファイルが自分のゲームと噛み合う可能性はありません。同じゲームであっても、バージョンが違えば中身は別物です。旧バージョンのファイルを最新版へ上書きする方法も同じ理由で成立しません。
正しい直し方は、ゲームランチャーの検証機能です。Steamならプロパティからインストール済みファイルの整合性を確認します。破損していれば正しいバージョンが再取得されます。これで直ったなら、Windowsの修復もドライバーの入れ替えも不要です。
もう1つ、Unity HubやUnity Editorをインストールする必要もありません。あれはゲームを作る側の道具で、遊ぶ側に必要なものは製品に同梱されています。同じ理由で、sfc /scannowでGameAssembly.dllが復元されることもありません。SFCが見るのはWindowsの保護されたシステムファイルで、このDLLはその対象外です。
切り分け症状ごとに、次に見る場所を決める
ここまでで直らない場合は、周辺の症状で進む方向を決めます。
| あなたの症状 | 最初に確認する場所 | 詳しい手順 |
|---|---|---|
| 1本のゲームだけで、毎回同じ場面で落ちる | Player.logとセーブデータ | 新規セーブで再現するか比較します。再現しなければ進行状態側の問題です |
| MODを入れている | MODローダーごと除去 | 素の状態で落ちなければMOD環境の問題です。BepInEx/LogOutput.txtも確認します |
| 例外コードが0xc0000005 | メモリアクセス違反 | 「メモリを参照しました」が出る原因と直し方 |
| 例外コードが0xc000001d | CPU命令セット | Illegal InstructionとAVX2の確認 |
| ゲームごとに障害モジュールが変わる | PC全体の安定性 | XMP・EXPOを無効にして比較し、CPUのOCも定格へ戻します |
| 落ちる瞬間に画面が暗転する | GPU側 | 症状から探す診断チャート |
判断の分かれ目は「1本だけか、複数か」です。同じPCで他のゲームが何時間も安定して動くなら、CPUやメモリの故障を疑う根拠は弱くなります。逆に、あるゲームはGameAssembly.dll、別のゲームはUnityPlayer.dll、また別のゲームは別のDLLというように障害モジュールが散らばるなら、ゲーム個別ではなくPC側の共通要因を先に見てください。
FAQよくある質問
%USERPROFILE%\AppData\LocalLow\CompanyName\ProductName\Player.log です。エクスプローラーのアドレスバーに %USERPROFILE%\AppData\LocalLow と入力し、開発会社名とゲーム名のフォルダーをたどってください。総括まとめ｜このDLLは「直す」のではなく「取り直す」
GameAssembly.dllは、UnityのIL2CPPでビルドされたゲームに生成される、そのゲーム専用のファイルです。Unity公式の定義では、IL2CPPランタイムとゲームのすべてのスクリプトコードが入っています。Windowsの部品ではないので、配布サイトから入手する対象でも、SFCで修復する対象でもありません。
やることの順番は決まっています。まずPlayer.logを読みます。イベントビューアーが教えてくれないゲーム側の事情がここに残っています。次にMODを使っているならローダーごと外して素の状態を作ります。それでも直らなければゲームランチャーの整合性チェックです。
それでも再発するなら、そこで初めて例外コードと周辺症状を見ます。1本のゲームだけならゲーム側、複数のゲームで障害モジュールが散らばるならPC側。この順番を守れば、MODのバージョン不一致が原因なのにWindowsを再インストールする、といった遠回りは避けられます。
GameAssembly.dllはUnityのIL2CPPでWindows向けにビルドしたときに生成される、ゲーム固有のファイルです。Unity公式は「IL2CPPランタイムとすべてのスクリプトコードを含むライブラリ」と定義しています（この記述は現行マニュアルからは削除され、2020.2以前のアーカイブ版に残ります）。Windowsのシステムファイルではないため、DLL配布サイトからの入手やsfc /scannowでは直りません。最初に読むのはPlayer.log（%USERPROFILE%\AppData\LocalLow\CompanyName\ProductName\Player.log）です。MODを使っているならローダーごと外して比較し、BepInExは安定版がIL2CPP非対応である点も確認してください。例外コードやPC全体の安定性については、それぞれの個別記事で切り分けます。
あわせて読みたい
