dotnet-dump
プロセスのダンプ(ヒープダンプやクラッシュダンプ)を収集・解析する.NETの診断ツール。SOSコマンド(dumpheap・gcroot・clrstackなど)でヒープの参照元やスタックトレースを調べられるが、ネイティブのスタックフレームは扱えない。
- 概念URI
https://comcomponent.com/knowledge/dotnet-dump/- 最終確認日
- 2026-08-01
- 機械可読データ
- JSON-LD
この概念が関わる関係
- .NETのメモリリーク(意図しない保持)はdotnet-dumpで確認できます。増えている型が見えたあと、なぜ回収されないのかはdotnet-dumpのヒープ解析で確認できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- dotnet-gcdumpはdotnet-dumpより先に行うべきです。軽量なdotnet-gcdumpで増えている型を絞り込んだうえで、参照元を追うdotnet-dumpに進むのが効率的な順番とされる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- dotnet-dumpは.NET Frameworkと両立しません。dotnet-dumpは.NET Core 3.0以降の診断機能を前提とするため.NET Framework 4.xでは使えず、代わりにWinDbgでSOSを読み込んで解析する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- dotnet-dumpはクラッシュダンプを前提とします。dotnet-dump analyzeはクラッシュダンプファイルを指定して対話セッションを開く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- dotnet-dumpはSOS拡張を利用します。dotnet-dump analyzeはSOSが事前インストールされた対話セッションを開き、clrstackやdumpheapなどSOSのコマンド体系をそのまま使える / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- dotnet-dumpをネイティブクラッシュに用いることは推奨されません。dotnet-dumpはネイティブなデバッガーではないためネイティブのスタックフレームを扱えず!analyze -vも使えないので、ネイティブクラッシュの調査には向かない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- dotnet-dumpはマネージドメモリリークに対する本記事の推奨です。純粋なマネージドコードのメモリリーク調査で、CIや複数プラットフォームでも動かしたい場合は、導入が軽いdotnet-dump analyzeが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
この概念を扱う記事
一次資料
このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。