Crash reports ja

English | 日本語

実験的な機能です。 中核 1.3.0（フレームワーク 1.3.0、2026-09-19）で入ったものです。

ゲームが落ちると、その直前に何が起きていたかは、たいてい分からなくなります。BepInEx のログは途中で止まってしまいますし、Unity のクラッシュフォルダーにはネイティブのスタックはあっても、どの Mod が何をしていたかまでは分かりません。そこで中核は、セッションごとに短い記録を残しておき、ゲームがきれいに終了しなかったときにそれをレポートにまとめます。すべてこの PC の中だけに置き、どこにも送りません。

レポートの場所

ゲームのフォルダーの BepInEx/CrashReports/ の下です。

何か	場所
遊んでいるセッションの記録	session.log（長いセッションで切り替わったときは session.1.log も）
クラッシュのあとのレポート	<日付>_<時刻>/。report.txt、セッションの記録、Unity が作っていれば crash.dmp
フリーズしたときのメモリダンプ	<日付>_<時刻>_hang/

レポートは、ゲームが落ちたとき、固まって手で閉じられたとき、強制終了されたときに作られます。Windows ではゲームが閉じたらすぐ（下のウィンドウを見てください）、それ以外では次に起動したときに作ります。どこに作ったかはログに出ます。残すのは最新の 10 件です。

クラッシュレポートのウィンドウ（Windows）

Windows では、ゲームが落ちたり固まったりすると、ゲームが消えてすぐに専用のウィンドウが開きます。描いているのはゲームではなく Windows なので、ゲームがどんな止まり方をしても出せます。中身は次のとおりです。

• 何が起きたかを言葉で説明します。Direct3D 12 の既知のクラッシュ（Unity の不具合 UUM-140564）、グラフィックスデバイスの応答停止、フリーズ、クラッシュなしの停止（強制終了、電源断）、その他の Unity 内のクラッシュのどれかです。
• それに対してできることがあれば、それも出ます。
• 詳しい情報：日時、シーン、プレイ時間、最後のエラー、グラフィックス、レポートの場所。
• レポートのフォルダーを開く、レポートをコピー（report.txt をコピーします。不具合の報告用）、閉じる。

ウィンドウは、ゲームで選んだ言語で表示されます（英語・日本語・中国語。Assets 1.1.1 以降が必要で、Drag'n Wash Localization には入っています）。選んでいなければ Windows の表示言語になります。きれいに終了したときは何も出ません。

これは中核の DLL の隣にある小さなプログラム CrashReporter.exe で、中核がゲームと一緒に起動し、ゲームが閉じるのを待っています。Wine や Proton（Steam Deck、Linux）では起動しないので、その場合は次の起動時にレポートを書きます。CrashReporter.exe --show <レポートのフォルダー> でレポートをもう一度開けます。

助けを求めるとき

• 不具合の報告や Issue には report.txt を添えてください（レポートをコピー でコピーした内容を貼っても同じです）。中身はバージョン、Mod、最後の記録、ネイティブのスタックで、公開の報告に添えるためのものです。
• メモリダンプ（crash.dmp、または _hang フォルダーの .dmp）にはゲームのメモリの一部が入っています。調べる人にだけ個別に渡し、公開の Issue には決して添付しないでください。
• フレームワークの Issue は TomXV/dragnwash-modframework へどうぞ。

設定

Options → Mods → Drag'n Wash ModFramework → Settings の Diagnostics のセクションにあります（詳細設定は、ページの上の Show advanced settings をオンにすると出ます）。

設定	設定ファイルの項目	既定
Crash reports	[Diagnostics] CrashReports	オン	セッションの記録とレポート。次の起動から効きます。
Crash report window	[Diagnostics] CrashReporterWindow	オン	Windows での専用ウィンドウ。次の起動から効きます。
Memory dump when the game freezes	[Diagnostics] HangDumps	オン、詳細設定	フリーズの見張り役のダンプ（Windows）。Crash reports がオンのときだけ。
Trace GPU uploads (Direct3D 12 investigation)	[Diagnostics] TraceGpuUploads	オフ、詳細設定、実験的	調べるために、GPU への転送のたびに記録を足します。Crash reports がオンのときだけ。次の起動から効きます。

Direct3D 12 のセクションには Batch font atlas uploads (Direct3D 12)（[Direct3D12] BatchFontAtlasUploads、オン、詳細設定、次の起動から効きます）があります。詳しくは Direct3D 12 のクラッシュ を見てください。

記録するもの

BepInEx/CrashReports/session.log に 1 行ずつ書き、書くたびにすぐディスクへ流すので、落ちても最後の行が残ります。

04:22:07.528 f18344 main scene loaded 'Wash' (Single)
04:22:07.611 f18351 main unity-error NullReferenceException: ...
04:22:09.002 f18470 main beat 16.7 ms/frame

• 始めに、フレームワークと Unity のバージョン、グラフィックス API とグラフィックスカード、画面モード、起動オプション。そのあと、読み込まれたすべての Mod とそのバージョン。
• シーンの読み込みと破棄、Mod のリロード、ゲームで選んだ言語。
• Unity のエラー、例外、グラフィックスデバイスのメッセージ。
• 10 秒ごとの生存確認（GPU 転送のトレース中は 1 秒ごと）。これで、最後の記録からどのくらいあとにゲームが止まったかが分かります。
• Mod が残す記録（Mod 作者向け を参照）。

きれいに終了すると、ファイルの最後に END clean exit と書きます。長いセッションでは 4 MB で次のファイルに切り替え、前の分を session.1.log として残します。

レポート

次の起動時（Windows ではゲームが閉じたらすぐ）に、session.log の最後にその印がなければ、ゲームはきれいに終了しなかったということなので、レポートのフォルダー BepInEx/CrashReports/<日付>_<時刻>/ に次のものを書きます。

• report.txt：いつ終わったか、バージョンと Mod、最後の 40 件の記録、そして Unity 自身のクラッシュフォルダー（%TEMP%/<会社名>/<製品名>/Crashes/Crash_*）が終了から 2 分以内に作られていれば、そのネイティブのスタック。
• session.log（切り替えがあれば session.1.log も）。
• crash.dmp：Unity 自身のクラッシュのメモリダンプ。クラッシュフォルダーからコピーします。

ウィンドウと次の起動時は同じコードを使っていて、先に動いたほうが記録に「報告済み」の印を付けます。なので、1 回のクラッシュにレポートは 1 つだけです。

メモリダンプ

ダンプは、ゲームのプロセスのスナップショットです。すべてのスレッドのスタックと、読み込まれていたモジュールが入っていて、デバッガー（WinDbg、Visual Studio）でゲームの PDB ファイルと一緒に開けます（ゲームには UnityPlayer_Win64_player_mono_x64.pdb が同梱されています）。ログでは分からない「おかしくなったとき、各スレッドがどこにいたか」が分かります。

• クラッシュのときは Unity 自身が crash.dmp を書くので、レポートにはそのコピーを入れます。
• フリーズのときは、ゲームが固まっても Unity は何も書かないので、見張り役のスレッドが代わりに書きます。ゲームの窓が前面にある状態で、メインスレッドが 15 秒間 1 フレームも進まなかったら、プロセスのミニダンプ（数 MB、Windows）を BepInEx/CrashReports/<日付>_<時刻>_hang/ に書き、セッションの記録にもそう書きます。ゲームがまた動き出したら、それも記録します。裏に回っているゲームは、わざとフレームを止めていることがあるので数えません。どの窓が前面にあるかは Windows に聞くので、前面に戻った瞬間に固まるゲームも捕まえられます。

Direct3D 12 のクラッシュ

Direct3D 12（Windows の既定）では、この Unity のバージョンは、GPU への転送が通る一時的なメモリ（scratch）をあるフレームが切り詰めるときに、レンダリングのスレッドの D3D12ScratchAllocator::DestroyScratch で落ちることがあります（Unity の不具合 UUM-140564）。クラッシュレポートを見ると、その転送はフォントのエンジンから来ていました。新しい文字の多い画面を開くと何十ものラベルが並び、ラベルごとにフォントアトラス全体をもう一度転送していたのです。Tool window が落ちていたのはこれが原因でした。

中核 1.3.0 から、Direct3D 12 では、変わったフォントアトラスをフレームの終わりに 1 回だけ転送します（Batch font atlas uploads、オン）。新しく足された文字が、その 1 フレームだけ空白で描かれることがあります。ほかのグラフィックス API では何も変えていません。中核がこれをしているかどうかは GameInfo.FontAtlasUploadsBatched で分かります。

Trace GPU uploads は、クラッシュの陰にあるほかの転送を探すためのものです。テクスチャの転送と作成、動的フォントと TextMeshPro のアトラスの拡張、メッシュの転送、アセットバンドルの読み込み、解放された GPU のリソースのすべてについて、大きさと、呼び出し元の Mod を記録に足します。Unity のメソッドにパッチを当て、そのたびにスタックをたどるので、調べるときだけオンにしてください。それでも Direct3D 12 で落ちるなら、Steam の起動オプションに -force-d3d11 を入れて回避できます（Assets を見てください）。

Mod 作者向け

CrashReports.Note(MyPlugin.Guid, "load", $"importing {count} textures from {folder}");

CrashReports.Note(ownerGuid, category, message) はセッションの記録に 1 行足します。記録は軽いので、どのスレッドからでも安全に呼べます。重い処理や危ない処理の前に 1 つ残しておくと、その直後に落ちたときに手がかりになります。短く書いて、個人情報は決して入れないでください。レポートは公開の不具合報告に添えるものだからです。