この記事の要点

DMP / コアダンプ (.dmp / .core) はプロセスや OS のメモリイメージをディスクに記録したファイル 用途はクラッシュ後の事後解析（postmortem）。スタックトレース・変数・ヒープが見られる Linux: ulimit -c unlimited + /proc/sys/kernel/core_pattern、gdb prog core で解析 Windows: WER / mini-dump / full-dump / kernel、WinDbg / !analyze -v や Visual Studio で解析 機密情報のかたまり (秘密鍵・パスワード・トークン)。本番ダンプは保管・転送ポリシーを定めて厳重管理し、共有前にスクラブ

概要

サーバプロセスやアプリケーションが落ちたとき、ログだけではコールスタックや変数状態が分からないケースは多い。メモリダンプはクラッシュ瞬間のプロセス (または OS) のメモリイメージをディスクへ書き出したファイルで、後からデバッガで読み込んで「どの関数で、どの引数で、どの値を持って落ちたか」を逆引きできる。これを postmortem デバッグと呼び、再現困難なバグや本番限定の不具合を追跡する強力な手段となる。

Windows では .dmp、Linux / macOS / FreeBSD などでは伝統的に core ファイル (拡張子なし or core.<pid>) が使われる。両者は形式が異なるが、目的と運用思想はほぼ同じである。

内部構造

Windows DMP はマイクロソフトの minidump 形式 (MINIDUMP_HEADER 〜 各種ストリーム) でドキュメント化されている。代表的なバリエーションは以下。

• Minidump: スタックと一部メタのみ、数 MB。クラッシュレポート向け。
• Full memory dump: プロセスメモリ全量、サイズは RSS そのまま。
• Kernel memory dump: OS カーネル空間中心。BSOD 解析向け。
• Complete memory dump: 物理メモリ全量。BSOD で全容を取りたいとき。

Linux core は ELF 形式で、PT_NOTE と PT_LOAD セグメントの組み合わせ。プロセスの全マッピングをそのまま吐くため、RSS が 8 GB あれば core も 8 GB になりがちだ。

主な用途

• 稀少クラッシュの解析: 数百万リクエストに 1 回しか起きないバグでも、ダンプを集めれば原因に近づける。
• BSOD (Blue Screen of Death) 調査: ドライバ不具合、ハード故障の特定。
• セキュリティ調査: 攻撃中プロセスのメモリから残存する文字列・鍵を抽出。
• 性能・リーク解析: ヒープ全体を読み込み、オブジェクト数の異常やリーク箇所を可視化。

関連形式との比較

• PCAP: ネットワーク I/O のスナップ、メモリではなく通信を記録。
• ETL (.etl): Windows のイベントトレース。ダンプより軽量で、イベントログ的に時系列を取れる。
• HPROF (.hprof): Java VM のヒープダンプ。Eclipse MAT で解析。
• HAR / ログファイル: 高レベル情報のみで、メモリ状態は含まない。

コマンド・ツール

# Linux: core を出す準備
ulimit -c unlimited
echo "core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern

# 動作中のプロセスからスナップショット
gcore $(pgrep myserver)        # core.<pid> ができる

# gdb で読む
gdb /path/to/myserver core.12345
(gdb) bt full
(gdb) info threads
(gdb) thread apply all bt

# Windows: ユーザモードプロセスから dump
procdump -ma myserver.exe out.dmp
# あるいはタスクマネージャ → 右クリック → ダンプファイルの作成

# WinDbg で開いて解析
windbg -z out.dmp
0:000> !analyze -v
0:000> ~* k

# kdump (Linux カーネルパニック時の自動ダンプ)
sudo systemctl enable kdump
# crash ユーティリティで /var/crash/<timestamp>/vmcore を解析
crash vmlinux /var/crash/.../vmcore

注意点

• 機微情報の塊: ダンプにはパスワード・トークン・PII がそのまま残る。SaaS の本番ダンプを社外に送るのは原則 NG。
• サイズ: 数 GB〜数十 GB になることが普通。ディスクが満杯になりサービス停止に至った例多数。書き出し先・ローテーションを設計する。
• シンボル必須: シンボル (PDB / debug info) が無いとスタックが ?? ばかりで読めない。ビルド時に symbol server / debuginfod を整備しておく。
• ASLR: アドレスはランダム化されるため、別バイナリで取った core は対応不能。バイナリ + デバッグ情報をペアで保管する。
• 本番採取のオーバヘッド: フルダンプ書き出し中はプロセス停止。SLA に影響する場合はミニダンプや非同期出力 (Windows の WerFault + クラッシュレポート集約) を検討。

関連リンク

• システム・仮想化
• ファイル拡張子とは
• IT セキュリティ
• PCAP / PCAPNG（.pcap / .pcapng）
• PEM（.pem）