WinDbg与PerfView联动可高效定位高并发响应慢根因：先用!threads和!syncblk查托管线程阻塞与锁竞争，再用PerfView采样CPU/GC热点及ThreadPool队列，结合!dumpheap和~*k分析托管/非托管混合瓶颈，需交叉验证三者数据。
高并发下响应变慢，第一反应是线程卡在同步原语上。用 WinDbg 加载 dump 后，!threads 能快速列出所有托管线程状态，重点关注 State 列为 Wait: 或 Preemptive 但实际在等锁的线程。
接着用 !syncblk 查看同步块持有情况，输出里 MonitorHeld 非 0 的条目说明有线程正持有锁；再配合 !dlk（需先加载 SOS.dll）可自动识别死锁链——但要注意：它只检测 CLR 层面的 Monitor.Enter / lock，对 SpinLock、ReaderWriterLockSlim 或 native mutex 不敏感。
~*e !clrstack 查每个线程的托管调用栈，确认是否卡在 Monitor.Wait、WaitHandle.WaitOne 或 Task.Wait
System.Threading.Monitor.ObjWait，大概率是某个共享资源被单一线程长期独占!threads -state 中的 Background 线程可能也在争抢同一把锁，不能只盯主线程WinDbg 擅长“静态快照”，PerfView 更适合“动态采样”。启动时勾选 CPU Stack + GC Heap Alloc，采样时间建议 ≥30 秒，避免噪声干扰。导出 Events 视图后，重点看两个维度：
CPU 热点：展开 Microsoft-Windows-DotNETRuntime/MethodJITVerbose 或直接看 Stacks 页的 Hot Path，高频出现 ConcurrentDictionary`2.TryGetValue 或 StringBuilder.Append 不一定错，但若伴随大量 GC/Start 事件，则可能是分配压力引发的间接竞争。
GC 压力信号：观察 GC/End 事件间隔是否小于 1 秒，且 Gen 2 次数突增——这常意味着大对象堆（LOH）频繁分配，而 LOH 分配在高并发下会触发全局锁 gc_heap::allocate_large，成为隐形瓶颈。
ThreadPool 队列长度，需手动开启 Microsoft-Windows-DotNETRuntime/ThreadPool/WorkerThreadAdjustment 事件Alloc By Type 和 Alloc By Stack，能定位是哪个业务逻辑路径在疯狂 new 对象
GCStats 表格时，注意 PauseMSec 列总和占比，若 >15%，说明 GC 已显著拖慢吞吐async 方法没用 await 但写了 async 修饰符，或在 ConfigureAwait(false) 缺失场景下调度回 UI/ASP.NET 上下文，都会导致线程池饥饿。PerfView 中若发现 ThreadPool/WorkerThreadAdjustment 频繁触发扩容，同时 ThreadPool/QueuedWorkItem 队列深度持续 >100，就要怀疑 await 后续执行被卡住。
此时切回 WinDbg，用 !dumpheap -type System.Threading.Tasks.Task 查看未完成的 Task 数量；再挑几个状态为 WaitingForActivation 的 Task，用 !dumpobj 看其 m_stateFlags 和 m_continuation 字段——如果 m_continuation 是 AsyncMethodBuilderCore 实例，且其 m_stateMachine 的字段显示 awaiter 仍处于 IsCompleted == false，基本确认是 I/O 或定时器未触发回调。
Task.Result 或 Task.Wait() 在 ASP.NET Core 同步上下文中，这会直接阻塞整个请求线程Stacks 页中搜索 TaskAwaiter.HandleNonSuccessAndDebuggerNotification，它的调用频次异常高，往往对应 await 后续逻辑执行缓慢!dumpheap -stat 若显示大量 System.Object[] 或 System.Byte[]，可能是 JSON 序列化/反序列化过程中 buffer 复用失败，引发额外分配和锁争用高并发服务常调用 native DLL（如加密、图像处理），这类调用不会出现在 !clrstack 中，但会卡住线程。WinDbg 里用 ~*k 看所有线程的原生栈，若某线程栈顶是 ntdll!NtWaitForSingleObject 或 kernel32!WaitForMultipleObjects，且没有对应的托管帧，就得怀疑 native 层阻塞。
PerfView 可通过开启 Windows Kernel/Process Thread 事件并勾选 SampleProfile，把 native 栈也纳入采样范围。此时 Stacks 页会出现 ntdll!RtlEnterCriticalSection 或 msvcr120!malloc 这类符号——前者说明 native 代码用了临界区且持有时间过长，后者则暗示频繁 malloc/free 引发的 heap lock 竞争。
[DllImport(..., CallingConvention = CallingConvention.Cdecl)]，否则调用约定不匹配会导致栈损坏，表现为随机线程挂起GCStats 中若 Gen 0 PauseMSec 极短但 Gen 2 却很长，且 native 栈频繁出现 HeapAlloc，说明托管内存压力已传导至 native heap 管理层