知識マップ: Windowsアプリのクラッシュ時にログとダンプを残す設計

記事「Windowsアプリのクラッシュ時にログとダンプを残す設計」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

Windowsアプリがプログラムミスによる例外で落ちても原因を追えるようにするには、落ちるプロセス自身のログだけに頼らず、通常時系列ログ・落ちる瞬間の最終クラッシュマーカー・WER LocalDumpsによるダンプという3層で証跡を分担する設計が有効である。AppDomain.UnhandledExceptionやWinFormsのThreadException、WPFのDispatcherUnhandledExceptionは見かけ上の延命に使うと危険で、記録の入口として使ったうえでEnvironment.FailFastのような即時終了APIで終了させる方が安全だが、UnhandledExceptionの中でFailFastを呼ぶとダンプの原因がすり替わってしまう。native C++ではSEHに加えてCRTの終了経路も押さえる必要があり、24時間稼働や装置制御が絡む場合は監視プロセスを足すとexit codeや再起動回数まで外部から検知できるようになる。

flowchart LR
    accTitle: Windowsアプリのクラッシュ時ログ・ダンプ設計の知識マップ
    accDescr: 落ちるプロセスの中だけに証跡を期待しない設計が、通常ログ・最終クラッシュマーカー・WER LocalDumpsという3層の役割分担と、AppDomain.UnhandledExceptionやFailFastなど各種例外ハンドラの使い分け、監視プロセスによる外部からの検知で成り立つことを示す図
    crash_time_logging_design["クラッシュ時のログ・証跡設計"]
    wer_localdumps["WER LocalDumps"]
    application_log["通常ログ(時系列ログ)"]
    fatal_crash_marker["最終クラッシュマーカー"]
    seh["SEH(構造化例外処理)"]
    crt_termination_handler["CRT/C++ランタイムの終了経路"]
    watchdog_process["監視プロセス(watchdog)"]
    high_reliability_operation_requirement["24/7運転・装置制御などの強めの要件"]
    post_restart_processing["次回起動後の後処理"]
    session_id_correlation["session IDによる証跡の突き合わせ"]
    dotnet_unhandledexception["AppDomain.UnhandledException"]
    winforms_threadexception["Application.ThreadException(WinForms)"]
    unexpected_exception_continuation["プログラムミス起点の想定外例外での処理継続"]
    wpf_dispatcherunhandledexception["Application.DispatcherUnhandledException(WPF)"]
    unobserved_task_exception["TaskScheduler.UnobservedTaskException"]
    environment_failfast["Environment.FailFast"]
    windows_application_event_log["Windowsアプリケーションイベントログ"]
    dump_folder_acl["ダンプ保存先フォルダのACL"]
    crash_dump["クラッシュダンプ"]
    pdb["PDB(プログラムデータベース)"]
    windbg["WinDbg"]
    minidumpwritedump["MiniDumpWriteDump"]
    wer_file_registration["WerRegisterFileによるログ添付登録"]
    crash_time_logging_design -->|"前提とする"| application_log
    crash_time_logging_design -->|"前提とする"| fatal_crash_marker
    crash_time_logging_design -->|"前提とする"| wer_localdumps
    crash_time_logging_design -.->|"前提とする"| seh
    crash_time_logging_design -.->|"前提とする"| crt_termination_handler
    watchdog_process -->|"推奨される対応"| high_reliability_operation_requirement
    fatal_crash_marker -->|"より先に行うべき"| post_restart_processing
    fatal_crash_marker -.->|"前提とする"| session_id_correlation
    fatal_crash_marker -->|"推奨される対応"| dotnet_unhandledexception
    winforms_threadexception -->|"用いるのは非推奨"| unexpected_exception_continuation
    wpf_dispatcherunhandledexception -->|"用いるのは非推奨"| unexpected_exception_continuation
    unobserved_task_exception -->|"用いるのは非推奨"| fatal_crash_marker
    environment_failfast -->|"利用する"| windows_application_event_log
    fatal_crash_marker -->|"推奨される対応"| seh
    fatal_crash_marker -->|"推奨される対応"| crt_termination_handler
    wer_localdumps -.->|"前提とする"| dump_folder_acl
    crash_dump -.->|"前提とする"| pdb
    crash_dump -->|"で確認できる"| windbg
    minidumpwritedump -->|"実装を担う"| crash_dump
    watchdog_process -.->|"利用する"| minidumpwritedump
    wer_file_registration -->|"利用する"| application_log
    wer_localdumps -->|"より先に行うべき"| wer_file_registration
    wer_localdumps -->|"実装を担う"| crash_dump
    fatal_crash_marker -->|"推奨される対応"| winforms_threadexception

概念間の関係(全24件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• クラッシュ時のログ・証跡設計は通常ログ(時系列ログ)を前提とします。3層構成のうち、直前までの時系列を残す通常ログが土台になる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• クラッシュ時のログ・証跡設計は最終クラッシュマーカーを前提とします。3層構成のうち、落ちる瞬間に1行だけ書いてFlush(true)する最終クラッシュマーカーが要る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• クラッシュ時のログ・証跡設計はWER LocalDumpsを前提とします。3層構成の主証跡は、落ちたプロセスの外に残るWER LocalDumpsのダンプに持たせる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• クラッシュ時のログ・証跡設計はSEH(構造化例外処理)を前提とします。native Win32/C++のアプリでは、SetUnhandledExceptionFilterによるSEHの終了経路も押さえる必要がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• クラッシュ時のログ・証跡設計はCRT/C++ランタイムの終了経路を前提とします。native C++のアプリでは、SEHだけでなくinvalid parameter・purecall・terminateなどCRTランタイム起点の終了経路も意識する必要がある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 監視プロセス(watchdog)は24/7運転・装置制御などの強めの要件に対する本記事の推奨です。24/7運転、装置制御、COM/P-Invoke/native SDK混在、子プロセスやプラグイン実行などの要件では、監視プロセスを足すとかなり強くなる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 最終クラッシュマーカーは次回起動後の後処理より先に行うべきです。クラッシュ時はローカルへ短く残すだけにして、圧縮・アップロード・通知は次回起動後か別プロセスに回すべきとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 最終クラッシュマーカーはsession IDによる証跡の突き合わせを前提とします。通常ログやダンプ、watchdog記録と突き合わせる運用にする場合、最終クラッシュマーカーのファイル名にsession IDを入れることが前提になる。突き合わせを行わないなら、最終クラッシュマーカー自体はsession IDなしでも1行書いて終了するという役割を果たせる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 最終クラッシュマーカーはAppDomain.UnhandledExceptionに対する本記事の推奨です。AppDomain.UnhandledExceptionのハンドラー内では、最終クラッシュマーカーを書くところまでにとどめることが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Application.ThreadException(WinForms)をプログラムミス起点の想定外例外での処理継続に用いることは推奨されません。ThreadExceptionはUIスレッドの未処理例外を拾って見かけ上継続できてしまうが、プログラムミス起点の想定外例外で継続する用途には向かないとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Application.DispatcherUnhandledException(WPF)をプログラムミス起点の想定外例外での処理継続に用いることは推奨されません。Handled=trueで見かけ上継続できるが、プログラムミス相手にそれをやると画面状態と内部状態がずれやすいとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• TaskScheduler.UnobservedTaskExceptionを最終クラッシュマーカーに用いることは推奨されません。TaskScheduler.UnobservedTaskExceptionはTaskの例外取りこぼしの検知には使えるが、最終クラッシュハンドラの主役にはしない方がよいとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Environment.FailFastはWindowsアプリケーションイベントログを利用します。Environment.FailFastはメッセージをWindowsのアプリケーションイベントログに書いてからプロセスを即時終了させ、その内容をエラー報告にも含める / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 最終クラッシュマーカーはSEH(構造化例外処理)に対する本記事の推奨です。SetUnhandledExceptionFilterなどのnative側のハンドラでも、最終クラッシュマーカーを書いたうえで確実に終了させるのが無難とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 最終クラッシュマーカーはCRT/C++ランタイムの終了経路に対する本記事の推奨です。invalid parameter・purecall・terminateのハンドラでも最終クラッシュマーカーを書き、重い回復処理はせず確実に終了させるのが無難とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WER LocalDumpsはダンプ保存先フォルダのACLを前提とします。Windowsサービスや権限分離した子プロセス、現場機の制限アカウントでは保存先ACLが空振りの主因になるため、書き込みテストまで確認する必要がある。通常のユーザーコンテキストで既定の保存先を使う場合はここまで意識しなくても書き込めることが多い / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• クラッシュダンプはPDB(プログラムデータベース)を前提とします。ソース行まで追って原因箇所を特定したい場合、ダンプ収集とPDB・配布バイナリの保管をセットで行う必要がある。PDBが無くてもマネージドのスタックフレームや型情報など読める情報は残るが、ソースファイル名・行番号だけは失われる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• クラッシュダンプはWinDbgで確認できます。取れたダンプは同じビルドのPDBと配布バイナリを集めたうえでWinDbgを使い、.ecxrで例外コンテキストへ移動してから!analyzeで読み進める / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• MiniDumpWriteDumpはクラッシュダンプの実装を担います。MiniDumpWriteDumpは自前でクラッシュダンプを生成する実装を担うAPIで、クラッシュしたプロセスの中より別プロセスから呼ぶ方が安全とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 監視プロセス(watchdog)はMiniDumpWriteDumpを利用します。worker本体が壊れていてもhelperは健全なため、helper側からworkerのダンプを取る構成にできる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• WerRegisterFileによるログ添付登録は通常ログ(時系列ログ)を利用します。WerRegisterFileで現在のログファイルをエラーレポートに含めるための登録ができる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WER LocalDumpsはWerRegisterFileによるログ添付登録より先に行うべきです。順番としては、ローカル通常ログ・ローカルfatalマーカー・ローカルdumpのあとに、必要ならWER送信経路でも関連ファイルを登録する方が実務向きとされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WER LocalDumpsはクラッシュダンプの実装を担います。WER LocalDumpsは、落ちたプロセスの外にユーザーモードのクラッシュダンプを生成・保存する実装を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 最終クラッシュマーカーはApplication.ThreadException(WinForms)に対する本記事の推奨です。Application.ThreadExceptionのハンドラーでは最小記録として最終クラッシュマーカーを書き、そのうえでプロセスを終了させダンプとログを残す方が安全とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

クラッシュ時のログ・証跡設計

落ちるプロセスの中だけに証跡を期待せず、通常ログ・最終クラッシュマーカー・OS/別プロセス側の証跡に役割を分けて残す設計方針。

WER LocalDumps

WERがクラッシュ後にユーザーモードダンプをローカルへ保存するための、レジストリで設定する機能。追加ツールなしでアプリ単位の設定が可能。

監視プロセス(watchdog)

本体プロセスの起動・終了・生存を外から見張り、exit codeや再起動回数を記録する別プロセス。

最終クラッシュマーカー

多重突入を防ぎつつ1行だけ書いてflushし終了する、クラッシュ発生時専用の短い記録ファイル。原因の詳細ではなく入口の固定を目的とする。

Application.ThreadException(WinForms)

WinFormsのUIスレッドの未処理例外を拾い、Handled指定で見かけ上継続できてしまうイベント。

Application.DispatcherUnhandledException(WPF)

WPFのUIスレッドの未処理例外を拾い、Handled=trueにすると見かけ上継続できてしまうイベント。

TaskScheduler.UnobservedTaskException

Taskの例外取りこぼしを検知する補助イベント。クラッシュ時の確実な記録経路としては弱い。

Environment.FailFast

try/finallyとfinalizerを実行させずにプロセスを即座に終了させ、イベントログへの記録とダンプ採取を行う.NETのAPIのこと。

クラッシュダンプ

プロセスのメモリ内容・スタック情報・例外情報などをファイルへ書き出した、クラッシュ調査に使うスナップショットである。

MiniDumpWriteDump

UIからの診断情報保存や、ログ・独自メタデータの同梱など、自前のダンプ収集機能を実装するためのWin32 API。

WerRegisterFileによるログ添付登録

現在のログファイルをWERのエラーレポートに含めるための登録を行う仕組み。ローカル保存の代替ではなく追加導線として使う。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。