dotnet-dump 无法直接捕获线程阻塞或竞争状态
dotnet-dump 只能抓取进程某一时刻的内存快照（core dump），它不记录执行轨迹，也不保存锁持有链、线程调度历史或内存访问顺序。所以当你遇到
Task卡住、
Monitor.Enter死锁、或
ConcurrentDictionary某些 key 查不到却没报错这类问题时，仅靠
dotnet-dump analyze很难定位——它能看到线程在哪个方法挂起，但看不到“为什么等”、“谁在持锁”、“是否自旋超时后放弃”。
实操建议：
先用dotnet-dump ps确认目标
dotnet进程 PID，再用
dotnet-dump collect -p <pid></pid>抓取 dump；注意：必须确保该进程启用了
COMPlus_DbgEnableMiniDump=1环境变量，否则 dump 缺少托管堆符号信息 dump 分析阶段，重点运行
clrstack -all和
dumpheap -stat，看是否有大量
Thread或
Task实例未完成，以及哪些线程卡在
WaitHandle.WaitOne、
Monitor.ObjWait或
SpinWait.SpinOnce若发现多个线程停在
Monitor.Enter同一个对象地址，用
dumpobj <obj_addr></obj_addr>查该对象的
SyncBlockIndex，再用
eeheap -syncblk找出当前持有该 sync block 的线程 ID
lldb 是唯一能实时观测托管线程调度和原生调用栈的工具
Linux 上没有 WinDbg，而
lldb是 dotnet runtime 官方支持的调试器（通过
libsosplugin.so插件）。它能 attach 到运行中的
dotnet进程，设置断点、单步执行、查看寄存器，并在托管代码断点命中时自动切换到 C# 源码上下文（需有 PDB + 调试符号路径正确）。
实操建议：
启动前导出符号路径：export DOTNET_SYMBOLS=1，并确保
/tmp/dotnet-symbols可写（或设
DOTNET_SYMBOLS_CACHE=/path） 用
lldb --core <core_file></core_file>加载 dump 时，必须手动加载插件：
plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/*/libsosplugin.so（路径依 .NET 版本而异） 调试运行中进程更实用：先
lldb -p <pid></pid>，再
plugin load ...，然后
bpmd YourAssembly.dll YourNamespace.YourClass.YourMethod下托管断点；若断点不生效，检查是否用了 AOT 编译或 Tiered Compilation 导致方法未 JIT 并发关键操作（如
Interlocked.CompareExchange、
SpinLock.Enter）附近可下原生断点：
b coreclr!JIT_CheckedWriteBarrier或
b libpthread.so.0!pthread_mutex_lock，观察锁争用路径
并发问题必须结合日志 + 时间戳 + 线程 ID 交叉验证
单纯靠 dump 或 lldb 快照，容易误判“假死”：比如某个
Task.Delay(60000)就是合法等待，不是 bug；而
Parallel.ForEach中某次迭代耗时突增，可能只是 I/O 偶发延迟。没有上下文时间线，所有线程状态都是静态幻觉。
实操建议：
在关键同步块前后打日志，用DateTime.UtcNow.Ticks和
Thread.CurrentThread.ManagedThreadId标记，例如：
log($"[T{tid}] Enter lock @ {ticks}")
避免用 Console.WriteLine（会锁 stdout，干扰并发行为），改用
System.IO.File.AppendAllText或
Microsoft.Extensions.Logging的 async logger 若使用
dotnet-trace，启用
Microsoft-DotNetRuntime:1:4:0x80000000事件提供程序，它会记录
ThreadPoolWorkerThreadStart、
ThreadStart、
ContentionStart等底层事件，配合
traceconv转成 CSV 后用 Pandas 分析锁等待热区
常见陷阱：.NET 版本、符号、权限三重不匹配
在 Linux 上调试 .NET 并发问题，80% 的失败不是逻辑问题，而是环境没对齐：你用 .NET 7 SDK 编译的程序，却用 .NET 6 的
libsosplugin.so加载 dump；或者
dotnet-dump是全局安装的，而应用跑在容器里，符号路径根本不可见；又或者非 root 用户 attach lldb，被 ptrace_scope 拦截。
实操建议：
统一版本：用dotnet --list-runtimes和
dotnet-dump --version确保一致；容器内调试优先用
mcr.microsoft.com/dotnet/sdk:7.0镜像，自带匹配的调试工具链 符号路径必须显式指定：
dotnet-dump analyze mydump.coredump --symbols /path/to/pdb/；PDB 文件名必须与 DLL 名完全一致（含大小写），且不能压缩 绕过 ptrace 限制：
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope（临时），或容器启动加
--cap-add=SYS_PTRACE
sudo docker run --cap-add=SYS_PTRACE -v $(pwd):/app -w /app mcr.microsoft.com/dotnet/sdk:7.0 \ dotnet-dump collect -p $(pidof dotnet) --symbols ./bin/Debug/net7.0/
真正棘手的并发问题，往往藏在 JIT 编译后的指令重排、CPU cache line false sharing、或 GC suspension 导致的暂停毛刺里——这些已超出 dotnet-dump 和 lldb 的常规能力边界，需要 perf + eBPF + clrstack 多维印证。别指望一次命令就定位，留好 trace 和 dump 的时间戳，它们是你回溯的唯一锚点。
