Dotnet Debugging

dotnet-debugging

Overview

Windows and Linux/macOS debugging using WinDbg MCP tools (Windows), dotnet-dump, and lldb with SOS (Linux/macOS). Applicable to any application -- native, managed (.NET/CLR), or mixed-mode. Includes container diagnostic patterns for Docker and Kubernetes. Guides investigation of crash dumps, application hangs, high CPU, and memory pressure through structured command packs and report templates.

Platforms: Windows (WinDbg MCP, cdb), Linux/macOS (dotnet-dump, lldb with SOS, createdump, dotnet-monitor).

Routing Table

Scope

• Crash dump analysis (.dmp files) on Windows, Linux, and macOS
• Live process attach (cdb on Windows, lldb on Linux/macOS)
• Hang and deadlock diagnosis (thread analysis, lock detection, wait chains)
• High CPU triage (runaway thread identification)
• Memory pressure and leak investigation (managed heap, native heap)
• Kernel dump triage (BSOD / bugcheck analysis, Windows)
• Container diagnostics (dotnet-dump in Docker/Kubernetes, sidecar patterns)
• Production diagnostics (dotnet-monitor REST API, trigger-based collection)
• SOS commands across all platforms (WinDbg, dotnet-dump, lldb)
• Structured diagnostic reports with stack evidence

Boundary with [skill:dotnet-tooling]

Both skills use overlapping tools (dotnet-dump, dotnet-counters, dotnet-trace) but for different purposes:

Rule of thumb: if something is broken (crash, hang, deadlock, OOM), route here. If something is slow or needs optimization, route to [skill:dotnet-tooling].

Out of scope

• Performance profiling (dotnet-counters, dotnet-trace for optimization) -> [skill:dotnet-tooling]
• GC tuning and managed memory optimization -> [skill:dotnet-tooling]
• Assembly decompilation (ILSpy) -> [skill:dotnet-tooling]
• Performance benchmarking and regression detection -> [skill:dotnet-testing]
• Application-level logging and observability -> [skill:dotnet-devops]
• Unit/integration test debugging -> [skill:dotnet-testing]

MCP Tool Contract

These tool IDs are the WinDbg MCP server's exported names (single-underscore mcp_...), not the mcp__... dispatch prefix used by some hosts.

Diagnostic Workflow

Preflight: Symbols

Before any analysis, configure symbols to get meaningful stacks:

1. Set Microsoft symbol server: .symfix (sets srv* to Microsoft public symbols) 2. Add application symbols: .sympath+ C:\path\to\your\pdbs 3. Reload modules: .reload /f 4. Verify: lm (list modules -- check for "deferred" vs "loaded" status)

Without correct symbols, stacks show raw addresses instead of function names.

Crash Dump Analysis

1. Open dump: mcp_mcp-windbg_open_windbg_dump with dump file path 2. Load SOS for managed code: .loadby sos clr (Framework) or .loadby sos coreclr (.NET Core) 3. Get exception context: !pe (print exception), !analyze -v (automatic analysis) 4. Inspect threads: ~*e !clrstack (all managed stacks), !threads (thread list) 5. Check managed heap: !dumpheap -stat (heap summary), !gcroot <addr> (object roots)

Hang / Deadlock Diagnosis

1. Attach or open dump, load SOS 2. List all threads: !threads, identify waiting threads with !syncblk (sync block table) 3. Detect deadlocks: !dlk (SOS deadlock detection) 4. Inspect thread stacks: ~Ns !clrstack for specific thread N 5. Check wait reasons: !waitchain for COM/RPC chains, !mda for MDA diagnostics

High CPU Triage

1. Attach to live process or collect multiple dumps 10-30 seconds apart 2. Use !runaway to identify threads consuming the most CPU time 3. Inspect hot thread stacks: ~Ns kb (native stack), ~Ns !clrstack (managed stack) 4. Look for tight loops, blocked finalizer threads, or excessive GC

Memory Pressure Investigation

1. Open dump, load SOS 2. Managed heap: !dumpheap -stat (type statistics), !dumpheap -type <TypeName> (filter) 3. Find leaked objects: !gcroot <address> (trace GC roots to pinned or static references) 4. Native heap: !heap -s (heap summary), !heap -l (leak detection) 5. LOH fragmentation: !eeheap -gc (GC heap segments)

Report Template

## Diagnostic Report

**Symptom:** [crash/hang/high-cpu/memory-leak]
**Process:** [name, PID, bitness]
**Dump type:** [full/mini/live-attach]

### Evidence
- Exception: [type and message, or N/A]
- Faulting thread: [ID, managed/native, stack summary]
- Key stacks: [condensed callstack with module!function]

### Root Cause
[Concise analysis backed by stack/heap evidence]

### Recommendations
[Numbered action items]

Guardrails

• Do not claim certainty without callee-side evidence
• Do not call it a deadlock unless lock/wait evidence supports it
• Preserve user privacy: do not include secrets from environment blocks in reports

Cross-references: [skill:dotnet-tooling] for .NET SDK diagnostic tools (references/profiling.md) and GC/memory tuning (references/gc-memory.md).

References

• WinDbg MCP -- MCP server for WinDbg integration
• WinDbg Documentation -- Microsoft debugger documentation

Access WinDbg MCP

1. Install Prerequisites

• Follow mcp setup to install uvx and cdb.exe.

2. Configure MCP Server

Register WinDbg MCP in your MCP config (for example mcp.json) using:

uvx --from git+https://github.com/svnscha/mcp-windbg mcp-windbg

3. Verify MCP Access

Confirm WinDbg MCP tools are callable:

• mcp_mcp-windbg_list_windbg_dumps
• mcp_mcp-windbg_open_windbg_dump
• mcp_mcp-windbg_open_windbg_remote

If these tools are unavailable, reload chat/session after MCP config changes.

Capture Playbooks

Single Dump (Fast Snapshot)

Use when app is unstable and may exit soon.

procdump64.exe -ma <PID> C:\dumps\app_hang_1.dmp

Two-Dump Hang Capture

Use for hang diagnosis to confirm stable wait chains.

procdump64.exe -ma <PID> C:\dumps\app_hang_1.dmp
Start-Sleep -Seconds 25
procdump64.exe -ma <PID> C:\dumps\app_hang_2.dmp

Cross-App Freeze Capture

Use when multiple apps show similar freeze symptoms. Capture target app plus shell/notification-related processes.

Get-Process | Where-Object { $_.ProcessName -match 'ShellExperienceHost|StartMenuExperienceHost|explorer' } | Select-Object Id,ProcessName

Then capture each relevant PID:

procdump64.exe -ma <PID> C:\dumps\multi_<name>_<pid>.dmp

Notes

• Prefer full dumps (-ma) for stack and module fidelity.
• Capture before killing/restarting the process.

Common Patterns

COM/RPC Wait Chain

Signals:

• combase/RPCRT4 frames on blocked threads.
• UI thread in modal loop waiting on cross-apartment call.

Next commands:

• ~* kb
• !uniqstack -pn
• targeted ~<thread> kv

UI Message Pump Blocked

Signals:

• GetMessage/MsgWaitForMultipleObjectsEx path with no forward progress.

Next commands:

• !analyze -hang
• ~0 kv
• ~* kb

Worker Starvation

Signals:

• Many duplicate worker stacks in waits.

Next commands:

• !uniqstack -pn
• !runaway
• inspect representative blocked worker

Hot Loop / High CPU

Signals:

• Single thread dominates !runaway time.

Next commands:

• !runaway
• ~<thread> kv
• compare with nearby workers

Memory Pressure

Signals:

• Abnormal address space growth or heap pressure.

Next commands:

• !address -summary
• !heap -s

Dump Workflow

Purpose

Analyze a saved dump when live attach is not available.

Steps

1. Confirm dump path. 2. Open dump with mcp_mcp-windbg_open_windbg_dump. 3. Run baseline commands:

• !analyze -v
• lm
• ~* kb

4. Run scenario command pack based on symptom. 5. Close with mcp_mcp-windbg_close_windbg_dump.

Notes

• For intermittent hangs, two dumps 20-30 seconds apart improve confidence.
• Prefer full dumps when possible for complete stack/module context.

Linux and macOS .NET Debugging

Covers tools and workflows for .NET debugging on Linux and macOS. The primary skill references target Windows/WinDbg; this file provides the cross-platform equivalent commands and gotchas.

Core Tools

dotnet-dump

Collects and analyzes managed dumps without a native debugger. Available on Linux, macOS, and Windows.

Install:

dotnet tool install -g dotnet-dump

Collect a dump from a running process:

dotnet-dump collect -p <PID>
dotnet-dump collect -p <PID> -o /tmp/myapp.dmp     # explicit output path
dotnet-dump collect -p <PID> --type Full             # full dump with all memory

Open interactive analysis:

dotnet-dump analyze /tmp/myapp.dmp

SOS commands work directly inside the dotnet-dump analyze prompt (no prefix needed):

> clrstack           # managed call stack for current thread
> dumpheap -stat     # heap summary by type
> dumpheap -type System.String   # objects of a specific type
> gcroot <addr>      # find GC roots holding an object alive
> pe                 # print current exception
> threads            # list managed threads
> threadpool         # thread pool state and CPU usage
> syncblk            # monitor lock contention
> pstacks            # parallel stacks (grouped call stacks)
> dumpobj <addr>     # inspect a specific object

Key limitation: dotnet-dump is not a native debugger. Native stack frames and native memory commands are unavailable. Use LLDB for mixed native/managed analysis.

createdump

The .NET runtime's built-in dump creator, installed with every runtime version. Located in the runtime directory:

dotnet --list-runtimes
# Example output: Microsoft.NETCore.App 9.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.1]
# createdump lives at: /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.1/createdump

Manual collection:

sudo /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.1/createdump <PID>
sudo /usr/share/dotnet/shared/Microsoft.NETCore.App/9.0.1/createdump <PID> -f /tmp/coredump.%d

Preferred over gdb/gcore because system-generated dumps may lack managed state, causing SOS commands to show UNKNOWN for type and function names.

Automatic Crash Dump Configuration

Set environment variables to have the runtime invoke createdump automatically on unhandled exceptions and crashes:

Example systemd unit override:

[Service]
Environment=DOTNET_DbgEnableMiniDump=1
Environment=DOTNET_DbgMiniDumpType=4
Environment=DOTNET_DbgMiniDumpName=/var/dumps/core.%e.%p.%t

Dump type guidance:

• Mini (1): Small. Module lists, thread lists, exception info, all stacks. Good for crash triage.
• Heap (2): Large. Includes GC heaps. Default; sufficient for most managed investigations.
• Triage (3): Same as Mini but strips PII (paths, passwords). Use in regulated environments.
• Full (4): Everything including module images. Required for single-file and NativeAOT apps.

LLDB with SOS

LLDB is the recommended native debugger for Linux and macOS. Use it when you need both managed and native stack analysis.

Setup

Install LLDB (version 10+ recommended):

sudo apt-get install lldb        # Ubuntu/Debian
sudo dnf install lldb            # Fedora/RHEL
apk add lldb py3-lldb            # Alpine
xcode-select --install           # macOS (ships with Xcode CLI tools)

Install SOS and download symbols:

dotnet tool install -g dotnet-debugger-extensions && dotnet-debugger-extensions install
# Or the older, narrower install: dotnet tool install -g dotnet-sos && dotnet-sos install
dotnet tool install -g dotnet-symbol && dotnet-symbol <path-to-dump>

The installer creates ~/.lldbinit to auto-load the SOS plugin when LLDB starts.

Core Dump Analysis

lldb --core <dump-file> <host-program>
# <host-program> is typically "dotnet" or the self-contained app binary

Once inside LLDB:

(lldb) setsymbolserver -ms           # point to Microsoft symbol server
(lldb) loadsymbols                   # load native symbols
(lldb) clrstack                      # managed stack (current thread)
(lldb) dumpheap -stat                # heap summary
(lldb) gcroot <addr>                 # GC root chain
(lldb) pe                            # print exception
(lldb) threads                       # list managed threads
(lldb) setclrpath <path>             # override DAC/runtime binary location

Live Process Attach

lldb -p <PID>
# If permission denied:
sudo lldb --source ~/.lldbinit -p <PID>

Elevated LLDB does not auto-load ~/.lldbinit; pass it explicitly with --source.

SOS Command Differences from WinDbg

In WinDbg, SOS commands use the ! prefix (e.g., !clrstack). In LLDB:

• Newer dotnet-debugger-extensions: commands work directly (clrstack, dumpheap, etc.)
• Older dotnet-sos installs: may require sos prefix (sos clrstack, sos dumpheap)
• bt (LLDB native backtrace) shows native frames; clrstack shows managed frames

Container Debugging

Collecting Dumps Inside a Container

# Install tools inside the container
docker exec -it <container> dotnet tool install -g dotnet-dump

# Collect dump
docker exec -it <container> ~/.dotnet/tools/dotnet-dump collect -p 1

Caveats:

• dotnet-dump and dotnet-gcdump can consume significant memory and disk. Ensure container resource limits are sufficient.
• dotnet-dump collect spawns a helper process requiring ptrace permissions. You may need --cap-add=SYS_PTRACE on the container or adjust seccomp profiles.

Sidecar Pattern

Run diagnostic tools in a separate container. Requirements: 1. Shared process namespace -- --pid=container:<target> in Docker, or shareProcessNamespace: true in Kubernetes 2. Shared /tmp directory -- volume mount required because the .NET diagnostic port Unix Domain Socket lives in /tmp 3. Without shared /tmp, use --diagnostic-port to specify the socket path explicitly

# Docker example: run sidecar sharing PID namespace and /tmp
docker run --pid=container:myapp -v myapp_tmp:/tmp mcr.microsoft.com/dotnet/sdk:9.0

Automatic Crash Dumps in Containers

ENV DOTNET_DbgEnableMiniDump=1
ENV DOTNET_DbgMiniDumpType=2
ENV DOTNET_DbgMiniDumpName=/dumps/core.%e.%p
VOLUME /dumps

Mount a host or persistent volume at /dumps so dumps survive container restarts.

Kubernetes

Ephemeral debug containers (Kubernetes 1.23+):

kubectl debug -it <pod> --image=mcr.microsoft.com/dotnet/sdk:9.0 --target=<container>

For persistent diagnostic sidecars, use an emptyDir volume shared between app and sidecar containers for the /tmp diagnostic port socket.

Common Scenarios

Crash Analysis (Segfault, Unhandled Exception)

1. Ensure DOTNET_DbgEnableMiniDump=1 is set before the crash occurs. 2. Managed exception: dotnet-dump analyze <dump> then pe, clrstack, threads. 3. Native crash (SIGSEGV): use LLDB -- lldb --core <dump> dotnet then bt (native) and clrstack (managed).

High Memory / OOM Killer Investigation

The Linux OOM killer terminates processes without generating a .NET dump. Check dmesg | grep -i "oom\|killed process" first. For proactive investigation before OOM:

dotnet-dump collect -p <PID> --type Heap
dotnet-dump analyze <dump>
> dumpheap -stat              # top memory consumers by type
> gcroot <addr>               # trace why an object is retained
> gcheapstat                  # GC generation breakdown

Hang Diagnosis (Deadlock, Thread Starvation)

dotnet-dump collect -p <PID>
dotnet-dump analyze <dump>
> threads                     # list all managed threads
> syncblk                     # show lock contention and owners
> pstacks                     # grouped parallel stacks
> threadpool                  # thread pool saturation check

For deadlock detection, cross-reference syncblk owners with setthread <id> and clrstack to identify circular waits.

High CPU Investigation

Live check: dotnet-counters monitor -p <PID> --counters System.Runtime or top -H -p <PID> to find hot OS threads. Then collect a dump and in dotnet-dump analyze: threads, threadpool, setthread <id>, clrstack. There is no !runaway equivalent; correlate OS thread IDs from top -H with managed thread IDs via threads.

dotnet-monitor (Production Diagnostics)

A REST API for collecting dumps, traces, logs, and metrics without attaching a debugger. Designed for production and containerized environments.

Install as global tool (dotnet tool install -g dotnet-monitor) or Docker image (mcr.microsoft.com/dotnet/monitor). Start with dotnet-monitor collect --urls https://localhost:52323 --no-auth (dev only).

Key REST endpoints:

• GET /processes -- list monitored .NET processes
• GET /dump?pid=<PID>&type=Full -- collect a dump
• GET /trace?pid=<PID> -- collect an EventPipe trace
• GET /logs?pid=<PID> -- stream structured logs
• GET /metrics -- Prometheus-format metrics

Trigger-based collection (configure via settings.json):

• CPU threshold triggers (e.g., collect dump when CPU exceeds 80% for 30 seconds)
• Memory threshold triggers (e.g., collect GC dump when heap exceeds 500 MB)
• Custom EventCounter thresholds

Run as a Kubernetes sidecar with shared /tmp volume for the diagnostic port. In listen mode, use --diagnostic-port so dotnet-monitor accepts connections from the app runtime.

Cross-Platform Differences from WinDbg

Agent Gotchas

• Do not assume WinDbg commands work on Linux. Use dotnet-dump or LLDB with SOS. The ! prefix syntax is WinDbg-specific.
• Container dumps require headroom. dotnet-dump collect can consume memory comparable to the target process heap. If the container is near its memory limit, the collection will trigger the OOM killer.
• OOM kills do not generate .NET dumps by default. The kernel terminates the process before the runtime can invoke createdump. Configure DOTNET_DbgEnableMiniDump for crash dumps, but OOM kills bypass that path. Monitor dmesg and set up proactive collection with dotnet-monitor triggers.
• LLDB SOS prefix varies by install method. With dotnet-debugger-extensions, commands work without prefix. With older dotnet-sos, commands may need the sos prefix. If commands are not recognized, try both forms.
• Elevated LLDB skips ~/.lldbinit. When running sudo lldb, pass --source ~/.lldbinit explicitly or SOS will not load.
• ARM64 Linux has limited SOS support in older runtimes. .NET 6 and earlier have incomplete ARM64 SOS support. Use .NET 7+ for reliable ARM64 dump analysis.
• Cross-architecture analysis is not supported. Analyze dumps on the same architecture and Linux distro as the target. An x64 dump cannot be opened in an ARM64 dotnet-dump.
• macOS has no `/proc` filesystem. Use dotnet-counters or dotnet-trace instead of /proc-based tools for live process inspection.
• Dump output path in containers is relative to the target process filesystem. When using dotnet-dump from a sidecar, the dump is written in the target container's filesystem context, not the sidecar's.

Live Attach Workflow

Purpose

Attach to a currently hung or misbehaving process through a WinDbg debug server.

Steps

1. Find process IDs:

Get-Process | Where-Object { $_.ProcessName -match '<name-pattern>' } | Select-Object Id,ProcessName,StartTime

2. Start debug server with cdb (preferred):

& "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" -server tcp:port=5005 -p <PID>

3. If path differs, try:

& "C:\Program Files\Windows Kits\10\Debuggers\x64\cdb.exe" -server tcp:port=5005 -p <PID>

4. Provide this connection string to MCP:

tcp:Port=5005,Server=127.0.0.1

5. Open live session with mcp_mcp-windbg_open_windbg_remote. 6. Run scenario command pack. 7. Close with mcp_mcp-windbg_close_windbg_remote.

Notes

• Keep the cdb/windbg window open while MCP is connected.
• If 5005 is busy, use another port consistently in launch and connection string.
• Localhost (127.0.0.1) is recommended for local debugging.

MCP Setup

Prerequisites

• uvx installed and available in PATH.
• cdb.exe installed (from Debugging Tools for Windows).

Install cdb (Debugging Tools for Windows)

Preferred non-interactive install:

winget install 9PGJGD53TN86 --accept-source-agreements --accept-package-agreements

Fallback installer path: 1. Download the Windows SDK installer from Microsoft: https://developer.microsoft.com/windows/downloads/windows-sdk/. 2. Run setup and select only Debugging Tools for Windows (other SDK components are optional). 3. Expected cdb paths after install:

• C:/Program Files (x86)/Windows Kits/10/Debuggers/x64/cdb.exe
• C:/Program Files/Windows Kits/10/Debuggers/x64/cdb.exe

Verify cdb Installation

Use one of these checks:

Get-Command cdb -ErrorAction SilentlyContinue

Test-Path "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe"
Test-Path "C:\Program Files\Windows Kits\10\Debuggers\x64\cdb.exe"

Required Server Command

Use this launch command for the WinDbg MCP server:

uvx --from git+https://github.com/svnscha/mcp-windbg mcp-windbg

VS Code MCP Configuration

Add/update your MCP server configuration (for example in user mcp.json) so this server is available to the agent.

Validate Availability

Before debugging, confirm WinDbg MCP tools are callable in chat (for example, open remote or dump actions succeed).

Troubleshooting

• If tools are missing, verify the server entry in mcp.json.
• Restart the chat/session after MCP config changes.
• Confirm uvx is installed and reachable in PATH.
• Confirm cdb.exe is installed and reachable by full path.

Crash Dump Analysis Report Template

Use this exact structure.

Report Header

• Analysis Date: <YYYY-MM-DD>
• Dump File: <name.dmp>
• File Path: <full path>

Executive Summary

• Crash Type: <access violation|heap corruption|...>
• Severity: <critical|high|medium|low>
• Root Cause: <one sentence>
• Recommended Action: <one sentence>

Dump Metadata

• Creation Time: <from .time>
• OS Build: <from vertarget>
• Platform: <x86|x64|arm64>
• Process Name: <from !peb>
• Process Path: <from !peb>
• Command Line: <from !peb>
• Working Directory: <from !peb>

Crash Analysis

Exception Details

• Exception Code: <0x...>
• Exception Address: <0x...>
• Faulting Module: <module>
• Module Base Address: <0x...>

Call Stack Analysis

[0] module!function+offset
[1] module!function+offset
[2] module!function+offset

Thread Information

• Crashing or Primary Thread: <id + reason>
• Thread Count: <count>
• Other Notable Threads: <list or none>

Technical Details

Memory

• Virtual Size: <from !peb or analysis>
• Working Set: <if available>
• Heap Notes: <if relevant>

Loaded Modules Summary

Root Cause Analysis

• What happened: <technical failure description>
• Why it happened: <contributing factors>
• Code location: <function/module if known>
• Memory state: <null/use-after-free/corruption/unknown>

Recommendations

Immediate Actions

1. <action> 2. <action> 3. <action>

Investigation Steps

1. <next debug command or capture> 2. <code review target> 3. <repro/test scenario>

Prevention Measures

1. <fix class> 2. <validation/check> 3. <process improvement>

Priority Assessment

• Severity: <critical|high|medium|low>
• Justification: <impact, reproducibility, data-loss/security risk>

Additional Notes

• Symbols Complete: <yes|partial|no>
• Confidence: <high|medium|low>
• Missing Evidence: <what would increase confidence>

Attachment Checklist

• Dump(s)
• Stack output (k, ~* kb)
• Module list (lm)
• App/OS version and channel
• Repro steps and frequency

Sanity Check

60-Second Preflight

1. Confirm WinDbg MCP tools are available. 2. Confirm cdb.exe exists. 3. Confirm target PID or dump path. 4. Choose mode (live vs dump). 5. Set symbols if stacks are unclear: see symbols.

Quick Commands

Get-Command cdb -ErrorAction SilentlyContinue
Get-Process | Where-Object { $_.ProcessName -match '<name-pattern>' } | Select-Object Id,ProcessName

Task Index

Choose one primary task, run its commands, then summarize findings with report template.

• task-crash
• task-hang
• task-high-cpu
• task-memory
• task-unknown
• task-kernel

Cross-Task Correlation Checklist

• Identify 1-3 most relevant threads.
• Map key frames to owning module/component.
• Distinguish deadlock vs synchronous wait-chain vs active compute.
• Record confidence and missing evidence.

Support References

• sanity-check
• symbols
• common-patterns
• capture-playbooks

Symbols

Quick Setup

Run in WinDbg session:

.symfix
.reload

For Microsoft symbol server with local cache:

.sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
.reload /f

Symbol Servers

Adding Both Servers (WinDbg)

.sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols
.sympath+ srv*C:\symbols*https://symbols.nuget.org/download/symbols
.sympath+ C:\path\to\your\pdbs
.reload /f

Adding Both Servers (dotnet-dump / lldb)

# Environment variable for dotnet-dump and SOS
export DOTNET_SYMBOL_SERVER="https://msdl.microsoft.com/download/symbols;https://symbols.nuget.org/download/symbols"

Adding NuGet Symbols in Visual Studio

In Visual Studio: Tools > Options > Debugging > Symbols, add:

• https://symbols.nuget.org/download/symbols

This enables stepping into source of NuGet packages that publish symbols via SourceLink.

Verify Symbols

• lm to inspect module load status.
• lmv m <module> to confirm symbol details for a module.
• If stacks show many Unknown/raw addresses, symbols are likely incomplete.

Troubleshooting

• Ensure network access to msdl.microsoft.com and symbols.nuget.org.
• Use a writable local cache directory.
• Re-run .reload /f after changing symbol path.
• If only one module is problematic, use lmv m <module> first.
• NuGet symbol server only works for packages that opt into symbol publishing — if symbols aren't found, the package author may not publish them.

Task: Crash / Exception

Commands

• !analyze -v
• .ecxr
• k
• lmv m <faulting-module-if-known>

Deliver

• Faulting exception context.
• Faulting module and top stack path.
• Most likely crash trigger and confidence.

Task: Hang / UI Unresponsive

Commands

• !analyze -hang
• ~* kb
• !uniqstack -pn
• !locks
• ~<thread> kv for key threads

Deliver

• Blocked UI or primary thread.
• Blocking/callee path.
• Deadlock vs synchronous wait-chain classification.

Task: High CPU

Commands

• !runaway
• ~* kb
• ~<thread> kv for top CPU thread

Deliver

• Hot thread(s) and owning module.
• Why CPU is consumed (loop, wait-spin, heavy work).
• Next command if more evidence is needed.

Task: Kernel Triage

When To Use

• BSOD/bugcheck analysis.
• Kernel dump or kernel remote debug session.

Commands

• !analyze -v
• k
• lm
• !thread
• !process 0 1

Deliver

• Bugcheck or kernel fault summary.
• Faulting stack and likely driver/module.
• Confidence and next capture steps.

Guardrail

If only user-mode evidence is available, state that kernel conclusions are limited.

Task: Memory Pressure / Leak Suspicion

Commands

• !address -summary
• !heap -s
• lm

Deliver

• Memory growth area and likely owner.
• Heap summary interpretation.
• Whether evidence indicates leak vs transient pressure.

Task: Unknown Symptom

Commands

• !analyze -v
• !runaway
• !uniqstack -pn
• ~* kb

Deliver

• Best-fit symptom classification.
• Primary suspicious threads/modules.
• Recommended next task reference to continue.