🧪 DiagLab — ダンプ / Profiler 採取シナリオ

このページでできること

ダンプファイル (Memory Dump) や CLR Profiler Trace の採取で 実用的に調査できる状態 を、 ボタン操作で意図的に作り出す検証エリアです。各シナリオは ON/OFF できます。

⚠️ 本気で壊れます。 これらは App Service の w3wp プロセスでメモリ・CPU・スレッドを実消費します。 検証完了後は 必ず停止 (またはアプリ再起動) してください。Auto Heal / メモリ閾値で勝手に再起動する可能性もあります。
マルチインスタンスの罠 — App Service は複数 VM / 複数 w3wp で動作することがあり、 「leak/start を呼んだプロセス」と「ダンプを採るプロセス」が一致しないと意味がない。 各レスポンスの processId と machineName で確認し、同じ PID に対してダンプを採ってください。

採取手順チートシート

📁 Kudu (SCM) と Azure Portal のリンク (ホスト名から自動生成)
🧠 Memory Dump 採取
  1. シナリオ ON (例: Leak Start で 200〜500 MB 育てる)
  2. Kudu Process Explorer (上記リンク) → 該当 PID の右メニューから「Download mini-dump」または「Download full-dump」
  3. または dotnet-dump collect -p <pid> (Kudu の Powershell から実行可能)
  4. 採取後、シナリオ OFF (Leak Stop など)
# Kudu PowerShell (App Service Diagnostics > Debug Console > PowerShell)
cd D:\home\
dotnet tool install --tool-path D:\home\tools dotnet-dump
.\tools\dotnet-dump.exe collect -p <pid> --type Heap
# 出力されたファイルを Kudu の File Manager からダウンロード
📊 CLR Profiler / .NET Profiler Trace 採取
  1. シナリオ ON (例: CPU Spin で threads=N×ms=30000)
  2. Azure Portal → App Service → 左メニュー「Diagnose and solve problems」→ 「Diagnostic Tools」→ 「Collect .NET Profiler Trace」を実行
  3. または「Collect Memory Dump」(プロファイル目的でも使われる) を選択
  4. 採取後、シナリオ OFF (CPU Stop)
🔍 WinDbg / dotnet-dump analyze のチートシート 
# dotnet-dump analyze <dumpfile> で起動した後:
clrstack -all          # 全マネージドスレッドのスタック
threads                # スレッド一覧
syncblk                # ロック / Monitor 取得状況 (デッドロック調査)
dumpheap -stat         # ヒープ統計 (メモリリーク調査)
dumpheap -stat -min 85000  # LOH のみ
gcroot <addr>    # 該当オブジェクトの GC ルート
runaway                # スレッドごとの CPU 時間 (CPU hotspot 調査)

① 現在状態 (Process / GC)

② Memory Leak (Managed) — ダンプ採取用

指定 rate で byte[] を内部 List に蓄積し続けます。chunkKb=85 以上で LOH (Large Object Heap) 行き。 maxMb 到達で自動停止。Stop の keep=true はバッファを保持したまま停止 (ダンプ用にメモリを握ったまま観察可能)。

③ CPU Spin (高 CPU) — Profiler Trace 採取用

Math.Sqrt の tight loop を threads 本の Task で並列起動。ms 経過で自動 Cancel。 Profiler を開始してからこのボタンを押すと、hotspot がきれいに採取できます。

④ Hang (BG thread) — Hang Dump 採取用

background Task が ManualResetEventSlim.Wait() でハングします (HTTP は即返却)。 !syncblk / !threads / clrstack でブロック状態が見えます。 id を指定すると後で release?id=... で個別解除。

⑤ Hang (Request 内 Sleep) — Front-end timeout 再現

request スレッドを Thread.Sleep(ms) でホールド。 HTTP クライアントからは「応答が返ってこない」状態。 230 秒超を要求すると App Service フロントエンドが 502 を返してきますが プロセス側のスレッドは保持されたまま。

その他のエリア