WinDbg、CDB 与 ProcDump：从崩溃转储到 PDB 身份治理

同一个崩溃，为什么有人看到源码行，有人只看到地址

一个 Windows 服务偶发退出，日志只留下异常码。开发者拿到 .dmp 后直接双击 WinDbg，栈里既有 KERNELBASE!RaiseException，也有一串业务模块地址；换一台机器后，函数名和源码行又消失了。真正缺失的不是某条“万能分析命令”，而是四件能互相校验的证据：转储是否保留了所需内存、异常上下文是否切对、业务 PDB 是否与二进制同一构建、分析动作是否改变了目标进程。

WinDbg 适合交互式查看 live 进程和离线 dump，CDB 使用同一调试引擎提供命令行入口，ProcDump 则擅长按异常、CPU、内存、挂起或退出条件采集用户态 dump。三者组成的是证据链，不是三个可随意互换的命令：先用最小但足够的 dump 留住现场，再用匹配符号解释地址，最后把异常、线程和内存证据还原到可审查的构建身份。

Windows 崩溃转储与符号证据链ProcDump 按受控触发器采集最小充分转储，WinDbg/CDB 以异常上下文、线程栈和 PDB GUID/age 还原现场，权限、容量与销毁策略约束整条链路。高清原图

先把三个入口装对

现代 WinDbg 可以从 WinDbg 安装页 直接安装、从 Microsoft Store 获取，或用 winget 安装。安装后先确认命令实际来自哪里：

winget install Microsoft.WinDbg
winget upgrade Microsoft.WinDbg

Get-Command WinDbgX -ErrorAction SilentlyContinue
WinDbgX -?

WinDbgX.exe 是现代 WinDbg 的命令行入口，-? 应显示当前安装实际支持的启动参数；进入调试器后再用 version 查看调试引擎版本。它沿用经典调试引擎、命令和扩展，但独立安装 WinDbg 不等于同时安装 CDB、DumpChk、SymStore 与 AgeStore。现代 WinDbg 的官方系统基线与 ProcDump 并不相同：前者支持 Windows 10 1607 及以上和 Windows 11，ProcDump 的当前 Windows 发行页列出客户端 Windows 11 及以上、服务器 Windows Server 2016（产品版本标识）及以上。部署前应分别核对目标系统，不要用 WinDbg 能安装来推导 ProcDump 一定受支持。

需要无界面的 cdb.exe、dump 完整性检查或企业符号仓库工具时，从 Debugging Tools for Windows 入口运行 Windows SDK 安装器，只选择 Debugging Tools for Windows 即可。安装后用实际发现结果决定脚本路径，不要在团队脚本里猜 SDK 版本目录：

$debuggers = Get-ChildItem "${env:ProgramFiles(x86)}\Windows Kits" `
  -Filter cdb.exe -Recurse -ErrorAction SilentlyContinue
$debuggers | Select-Object -ExpandProperty FullName

Get-Command cdb, dumpchk, symstore -ErrorAction SilentlyContinue

ProcDump 从 Microsoft Sysinternals ProcDump 获取。它是独立工具，首次运行需要处理 EULA；自动化环境应由组织在镜像制作或软件分发阶段完成许可审查，不应让生产作业临时下载并静默运行未知副本。

Get-FileHash .\procdump.exe -Algorithm SHA256
.\procdump.exe -accepteula -?

帮助文本和文件摘要分别回答“参数是否是预期版本”和“执行的是否是获准制品”。团队基线应保存下载来源、版本、签名与摘要；受限网络通过已审查的软件仓库分发，不关闭 TLS 或终端安全控制来换取下载成功。

先选 live 还是 dump

调试器 attach 后，break 状态会让目标线程停止执行；即便使用 noninvasive debugging，目标全部线程仍会暂停，只是调试器不能控制目标继续运行。live 调试适合隔离环境里观察动态状态、设置断点和逐步执行，不适合把“只看一眼”包装成零影响生产操作。

dump 是某一时点的离线证据。它不会在分析时继续影响原进程，但采集瞬间仍可能暂停目标，且未采集的内存以后无法补回。选择顺序应当是：

只有在必须观察状态变化、且已有暂停预算、现场 owner 和明确退出条件时，才升级到 live attach。生产事故流程、审批和值班接管仍由组织运行手册负责；工具层必须准确交代会暂停什么、留下什么以及如何退出。

Dump 类型决定以后还能问什么

“Mini”只是名称，不是跨工具统一格式策略。ProcDump 的 -mm 与 WinDbg/CDB 的 .dump /m 保留内容不同，不能把两条命令写成等价替换。

ProcDump 的四个常用档位

参数	主要内容	适合从哪里开始	关键限制
-mt	Triage，栈直接引用内存与有限元数据	只需初步分型且数据暴露要求很严	只是尝试移除敏感信息，不保证脱敏
-mm	默认 Mini，直接和间接引用内存、线程/模块/句柄等元数据	崩溃栈、模块和线程初查	不含全地址空间，任意目标内存可能缺失
-mp	MiniPlus，更多 Private 和可读写 Image/Mapped 内存	需要堆或私有内存、又希望小于 Full	会排除特定大区域；CLR 进程可能升级为 Full
-ma	Full，Image、Mapped、Private 内存与完整元数据	明确需要完整用户态内存的深度分析	文件最大，凭证与业务数据暴露面最大

-mc <Mask> 可按 MINIDUMP_TYPE 掩码定制，-md <DLL> 可交给回调 DLL 决定内容。两者一旦进入团队流程，就必须把掩码含义、回调 DLL 来源和版本写进评审记录；一个没人能解释的十六进制值不是治理策略。

WinDbg/CDB 的 .dump 档位

在 live 用户态会话里，.dump /m <file> 生成基础 minidump，主要包含模块、线程和栈；.dump /ma <file> 还包括完整内存、句柄、卸载模块、基本内存信息和线程时间。.dump /mA 与 /ma 接近，但遇到不可读内存时继续生成。

.dump /m  <dump-path>
.dump /ma <dump-path>

.dump /mr 会清零不利于重建栈的部分栈或存储内容，局部变量和值也可能消失；/mR 移除完整模块路径。它们能减少暴露，却不能证明 dump 已脱敏。旧式用户态 .dump /f 已不受支持，不应继续放进新脚本。

对已有 dump 再执行 .dump 可以裁成更小的副本，但不能从 Mini 中重新创造未采集的内存。若问题从“哪条线程崩了”升级成“某个未被栈引用的堆对象是什么”，只能回到采集策略重新取证。

用 ProcDump 建立最小采集闭环

最安全的入门目标是同一普通用户启动的隔离测试进程。先创建受限实验目录，再按 PID 采集一个默认 Mini：

$Lab = Join-Path $env:TEMP 'windbg-procdump-lab'
$DumpDir = Join-Path $Lab 'dumps'
New-Item -ItemType Directory -Force $DumpDir | Out-Null

$TargetPid = <test-process-pid>
.\procdump.exe -accepteula -n 1 -mm $TargetPid $DumpDir
Get-ChildItem $DumpDir -Filter *.dmp |
  Select-Object Name, Length, LastWriteTime

预期证据不是“命令退出了”，而是目录中出现一个 dump、文件大小非零，并且工具报告目标 PID 与输出路径。安装了 Debugging Tools 后，再做结构完整性检查：

$Dump = Get-ChildItem $DumpDir -Filter *.dmp | Select-Object -First 1
dumpchk.exe $Dump.FullName

DumpChk 只能快速判断文件能否读取、基础结构是否合理；它不能证明关键内存已采集，也不能证明 PDB 正确。

按异常采集，而不是等人盯着窗口

-e 在 second-chance，也就是未处理异常时写 dump：

.\procdump.exe -accepteula -ma -n 1 -e your-service.exe $DumpDir

-e 1 同时捕获 first-chance 与 second-chance 异常。first-chance 异常会先到调试器，应用随后可能自行处理；在异常频繁但可恢复的程序上，无过滤使用 -e 1 会快速制造大量 dump：

# 仅用于隔离实验：上限、过滤和目录容量必须同时存在
.\procdump.exe -ma -n 2 -e 1 -f '<known-exception-text>' `
  your-test-app.exe $DumpDir

这个反例应看到“应用处理了异常但仍产生 dump”。它证明 first-chance 是线索，不等于崩溃根因；上线前必须验证过滤文本的命中与不命中各一次，并设置 dump 个数、目录配额和停止条件。

CPU、内存、挂起与退出触发

ProcDump 的触发器必须和指标语义一起评审：

现场信号	参数示例	容易误判的地方
CPU 持续过高	-c <percent> -s <seconds>	加 -u 才按单核口径解释阈值
CPU 持续过低	-cl <percent> -s <seconds>	低 CPU 不能单独证明线程死锁
进程 commit 过高	-m <MB>	是 process memory commit，不是 working set 或 private bytes
GUI 挂起	-h	表示窗口至少 5 秒不响应消息；不适用于无窗口服务
进程退出	-t	适合抓退出现场，不解释退出原因
等待目标启动	-w	按名称等待时要防止选中同名错误实例
启动并监控	-x <folder> <image>	ProcDump 成为父级启动入口，项目脚本要处理参数与工作目录

例如，采集两份相隔至少一个触发周期的 GUI 挂起 dump，可以比较线程栈是否稳定停在同一等待链：

.\procdump.exe -accepteula -h -n 2 -s 10 -mm `
  your-test-app.exe $DumpDir

-s 表示条件连续满足的秒数，-n 表示写多少个 dump 后退出。多时点相同栈比单张快照更能支持“持续等待”的判断，但仍要结合锁、等待对象和应用证据，不能由一个 WaitForSingleObject 帧直接宣布死锁。

clone 采集的 -r [1..5] 可降低某些采集路径的停顿，但高并发会消耗系统资源；-a 依赖 -r，会在预计产生长暂停时跳过触发，-at <seconds> 可取消超时采集。降低停顿不等于无停顿，跳过 dump 也必须进入告警与审计。

打开 dump 后先固定分析上下文

现代 WinDbg 可以从界面打开 dump，也可从命令行启动；CDB 适合脚本化输出：

WinDbgX -z <dump-path>
cdb.exe -z <dump-path> -c ".symfix; .reload; !analyze -v; q"

离线分析中的 q 只关闭调试会话；live CDB 中 q 默认会同时关闭被调试应用，两种场景不能混用。

崩溃 dump 的最小异常链是：

!analyze -v
.exr -1
.ecxr
kv

!analyze -v 给出自动分析线索；.exr -1 显示最近异常记录中的异常码、地址、flags 和参数；.ecxr 切换到用户态 crash dump 关联的异常寄存器上下文；随后 kv 才是在正确上下文里显示调用栈。自动分析的 bucket 或“可能由某模块导致”不是最终因果证明，必须继续核对异常地址属于哪个模块、模块是否有正确符号、参数和内存是否实际存在于 dump。

first-chance/second-chance 的控制命令主要用于 live 调试：sxe 在 first chance break，sxd 先显示、未处理后在 second chance break，sxn 只通知，sxi 忽略。gh 以“已处理”继续，gn 以“未处理”继续；在 second chance 执行 gn 会结束应用。只在一次性测试程序里练习这组命令，不在共享服务上试错。

在线程层面证明等待，而不是猜死锁

用户态 ~ 列线程，. 标记当前线程，# 标记原始异常线程或 attach 时活动线程。常用入口如下：

~
~*e kv
~3s
kv

~*e kv 遍历全部线程栈，~3s 选择调试器编号为 3 的线程。k 家族始终基于当前线程；kp/kP 想显示完整参数需要 full symbols，优化构建、公共符号或缺失内存都会让参数与局部变量不可靠。

挂起分析可以先选择可疑线程，再运行：

!analyze -hang

判断链应包含至少两个时点：负责请求的线程是否持续停在同一等待对象，持锁线程是否存在且栈是否变化，等待关系是否与业务超时吻合。若两个 dump 中线程 ID、等待对象或栈快速变化，现场更像慢处理、饥饿或外部依赖抖动，而不是稳定死锁。

live attach 还存在两套容易混淆的暂停状态。~n/~m 修改 Windows suspend count，detach 后可能残留；~f/~u 是调试器自己的 freeze/unfreeze，detach 时会解冻。实验里使用过 ~n 就必须配对 ~m 并验证目标恢复。保留目标进程退出 live 会话应使用：

qd

或：

.detach

不要通过关闭窗口、终止调试器进程或在 live CDB 中执行 q 来赌目标能继续运行。

符号路径要分清业务 PDB、公共符号和缓存

微软公共符号服务器只提供 Microsoft 组件符号，不会替团队保存业务 PDB。推荐的搜索顺序是：本次构建的业务符号、受控团队符号服务、Microsoft 公共符号服务，并为远程服务配置独立 downstream cache。

.sympath <build-symbol-dir>;srv*<team-symbol-cache>*<team-symbol-server>;srv*<microsoft-cache>*https://msdl.microsoft.com/download/symbols
.sympath
.reload

只需要微软公共符号时可以简化：

.symfix <microsoft-cache>
.reload

对应的环境变量形式是：

$env:_NT_SYMBOL_PATH = 'srv*<cache-dir>*https://msdl.microsoft.com/download/symbols'

符号路径从左到右搜索。公共服务器要求网络链路支持 TLS 1.2+；企业代理或内网环境应预热缓存、配置经批准的代理或镜像到内部符号服务，不能关闭证书校验，也不能从论坛附件下载同名 PDB。

符号排障保持固定顺序：

lml
lm m your_module v
.sympath
!sym noisy
.reload /f your_module.dll
!lmi your_module

栈里出现少量函数名并不证明 private PDB 已加载，导出符号也能提供有限名称。lm ... v 与 !lmi 要显示实际符号状态、PDB 路径和身份，!sym noisy 则解释调试器从哪些位置查找、为何拒绝某个候选。

PDB identity 不是文件名相同

新式 PDB 的关键身份是 GUID 与 age，旧式 PDB 使用 signature 与 age。PE 映像中的 RSDS 调试记录携带预期 PDB 名称、GUID 和 age，调试器据此判断候选是否匹配；把另一次构建的文件改名为 your-app.pdb 不会让身份变正确。

团队需要把以下对象绑定为一个不可拆的构建证据包：

目标 EXE/DLL 及 SHA-256。与映像匹配的 PDB，以及 GUID/age。源码提交和干净/脏工作树状态。

编译器、链接器、目标架构和优化配置。发布版本、构建流水线与制品摘要。

SymStore 对 PDB 按 signature+age 索引，对可执行映像和 DBG 按 timestamp+image size 索引。full/private PDB 与 stripped/public PDB 可能共享同一 signature+age，不能把两者当成同一 store 中可并存的两个身份；团队要分层存储或制定唯一发布策略，避免一个覆盖另一个。

正反实验：让正确 PDB 成功，让错误 PDB 明确失败

下面是使用合成数据的隔离实验。运行者应先进入 x64 Native Tools Command Prompt for VS，确认 MSVC cl.exe 与获准的 ProcDump 可用；正文给出的输出是判定条件，实际结论必须以本机保存的命令输出、文件摘要和符号诊断为准。

先在临时目录创建两个同名、不同函数的构建：

$Lab = Join-Path $env:TEMP 'windbg-pdb-identity-lab'
$A = Join-Path $Lab 'build-a'
$B = Join-Path $Lab 'build-b'
$Dumps = Join-Path $Lab 'dumps'
New-Item -ItemType Directory -Force $A, $B, $Dumps | Out-Null

@'
#include <windows.h>
__declspec(noinline) void BuildAAnchor() { Sleep(60000); }
int main() { BuildAAnchor(); }
'@ | Set-Content -Encoding ascii (Join-Path $A 'main.cpp')

@'
#include <windows.h>
__declspec(noinline) void BuildBAnchor() { Sleep(60000); }
int main() { BuildBAnchor(); }
'@ | Set-Content -Encoding ascii (Join-Path $B 'main.cpp')

cl /nologo /Zi /Od /EHsc /Fo:"$A\main.obj" `
  /Fd:"$A\compiler.pdb" /Fe:"$A\pdb_identity_demo.exe" "$A\main.cpp" `
  /link /DEBUG /PDB:"$A\pdb_identity_demo.pdb"
if ($LASTEXITCODE -ne 0) { throw "build A failed: $LASTEXITCODE" }

cl /nologo /Zi /Od /EHsc /Fo:"$B\main.obj" `
  /Fd:"$B\compiler.pdb" /Fe:"$B\pdb_identity_demo.exe" "$B\main.cpp" `
  /link /DEBUG /PDB:"$B\pdb_identity_demo.pdb"
if ($LASTEXITCODE -ne 0) { throw "build B failed: $LASTEXITCODE" }

$Target = Start-Process "$A\pdb_identity_demo.exe" -PassThru
.\procdump.exe -accepteula -ma $Target.Id "$Dumps\build-a.dmp"
if ($LASTEXITCODE -ne 0) { throw "ProcDump failed: $LASTEXITCODE" }
if (!(Test-Path -LiteralPath "$Dumps\build-a.dmp")) {
  throw 'ProcDump returned without the expected dump file'
}

先从 PowerShell 打开 dump：

WinDbgX -z "$Dumps\build-a.dmp"

待调试器命令窗口可用后，只使用 A 的 PDB：

.sympath <lab-dir>\build-a;srv*<cache-dir>*https://msdl.microsoft.com/download/symbols
!sym noisy
.reload /f pdb_identity_demo.exe
lm m pdb_identity_demo v
!lmi pdb_identity_demo
x pdb_identity_demo!*

预期正向证据是：模块显示已加载匹配的 PDB，路径指向 build-a，!lmi 中 GUID/age 与映像调试记录一致，x 能找到 BuildAAnchor。不要只截图漂亮调用栈，要保存 lm/!lmi 和符号诊断文本。

关闭会话，重新执行 WinDbgX -z "$Dumps\build-a.dmp" 打开同一 dump，再把符号路径只指向 B。这里不追加公共服务器或旧缓存，避免 A 的 PDB 从其他位置被命中：

.sympath <lab-dir>\build-b
!sym noisy
.reload /f pdb_identity_demo.exe
lm m pdb_identity_demo v
!lmi pdb_identity_demo
x pdb_identity_demo!*

预期反向证据是 !sym noisy 明确报告候选 PDB 不匹配或拒绝加载，模块不能冒充已加载正确 private symbols，BuildAAnchor 也不能由 B 的 PDB 正确解析。不要使用忽略 symbol mismatch 的强制选项把实验“修绿”；恢复 A 的路径并再次成功加载，才闭合正反对照。

最后结束测试进程并删除实验目录。删除前验证它确实位于当前用户临时目录，避免变量错误扩大清理范围：

if (!$Target.HasExited) { Stop-Process -Id $Target.Id -ErrorAction Stop }

$resolvedLab = [IO.Path]::GetFullPath((Resolve-Path -LiteralPath $Lab).Path)
$resolvedTemp = [IO.Path]::GetFullPath(
  (Resolve-Path -LiteralPath $env:TEMP).Path
).TrimEnd([IO.Path]::DirectorySeparatorChar) + [IO.Path]::DirectorySeparatorChar
if ($resolvedLab.StartsWith($resolvedTemp, [StringComparison]::OrdinalIgnoreCase) -and
    ($resolvedLab + [IO.Path]::DirectorySeparatorChar) -ne $resolvedTemp) {
  Remove-Item -LiteralPath $resolvedLab -Recurse -Force
} else {
  throw "Refusing to remove path outside the temp directory: $resolvedLab"
}
Test-Path -LiteralPath $resolvedLab

预期最后一条为 False。实际项目中不能这样删除受保留策略约束的事故证据；实验目录与正式证据库必须完全分开。

快照回答不了历史时，再升级到 TTD

dump 只能回答采集时刻“有哪些线程、寄存器和内存”，不能直接回答某个字段在此前何时被改坏。若错误能在受控 Windows 用户态进程中复现，且团队能够承受明显的运行时与磁盘开销，可以把同一个合成程序升级为 Time Travel Debugging（TTD） 实验。TTD 会记录进程执行并生成 .run，WinDbg 首次打开后生成加速查询的 .idx；回放可以前进、后退和重复查询，但不能修改已经记录的历史。

TTD 不是更大的 dump。它当前只记录用户态进程，不能记录内核态目标，也不能注入 Protected Process Light 等受保护进程；录制需要管理员权限。安全软件、内存防护和 Electron 一类运行时还可能与注入机制冲突。生产上出现权限或兼容性错误时，正确动作是保存 TTD 日志并转移到隔离复现环境，不是临时关闭整套终端防护。

第一次实验应使用 WinDbg 的 Launch executable (advanced) 和 Record with Time Travel Debugging，目标仍是前面的合成程序，输出目录则放在受限实验盘。需要自动化时，再使用单独安装并经过版本审查的 TTD.exe。三种录制方式的安全语义不同：

方式	典型入口	必须确认的影响
Launch	TTD.exe -launch <program> <args>	目标继承 recorder 的管理员权限，可能改变权限相关故障
Attach	TTD.exe -attach <pid> -out <trace.run>	目标按原权限运行，但 attach 和注入仍会造成性能扰动
Monitor	TTD.exe -monitor <full-path> -out <trace.run>	等待后续实例并保持其正常权限；结束监控要显式 Ctrl+C

先在隔离目录做一轮正向录制：触发确定错误，停止录制，确认 .run、TTD 日志和文件摘要都存在，再用 WinDbg 的 Open trace file 打开。只有 WinDbg 能索引并移动到记录末尾，才说明 trace 可用于分析：

!tt 100
!analyze -v
kv
!tt 0
g

!tt 0 和 !tt 100 分别移动到记录开头和结尾；位置也可以写成 sequence:step。在错误点设置代码断点或数据断点后，g- 向后运行，p- 向后跨过调用，t- 向后逐入。预期正向证据是再次到达同一异常地址，反向证据则是停在导致状态变化的写入或调用附近。若只能在结尾看到崩溃、反向搜索找不到业务位置，应先检查业务 PDB 是否匹配、目标代码是否已被记录、断点地址是否属于加载后的正确模块，而不是宣布“TTD 没记录到内存”。

反向实验要故意破坏一个条件。例如把业务 PDB 从符号路径移走后重新打开同一 .run：执行历史仍可回放，但查询结果会出现地址或 UnknownOrMissingSymbols，源码行和参数解释退化；恢复同一构建 PDB 后，函数和源码位置应重新出现。这个对照证明 TTD 保存执行历史，PDB 仍负责把机器地址解释成源码身份，两者不能互相替代。

TTD 的容量必须按 .run + .idx + 日志 + 传输副本 计算。微软给出的经验区间是活跃进程的 .run 约每秒增长 5 MB 到 50 MB，.idx 常见约为 .run 的两倍，典型录制性能损耗约 10 到 20 倍；实际值必须由目标负载测量。磁盘耗尽时录制可能等待并留下不完整 trace，索引耗尽空间还可能产生无效 .idx。因此录制脚本需要时长上限、空闲空间下限和人工停止条件；索引失败时保留原始 .run，删除可重建的 .idx，补足空间后再索引，不能把不完整 trace 当成“已捕获崩溃”。

.run 可能包含路径、注册表、内存和文件内容，敏感级别不低于 Full dump；.idx、日志和导出的查询结果也继承案件分级。录制结束后核销管理员会话、monitor 进程、.run、.idx、错误日志、分析机副本和传输分片。需要协作时共享案件库中的只读副本及 SHA-256，不通过聊天附件传播原始 trace。

把采集能力接进项目，而不是接进每个人的记忆

项目仓库适合保存采集策略和脚本模板，不适合保存 dump、private PDB、符号缓存或真实进程参数。一个可评审的采集配置至少要把这些决策显式化：

schema: 1
target: your-service.exe
trigger:
  kind: unhandled-exception
  firstChance: false
dump:
  type: mini
  maxCount: 2
  outputDirectory: "${DUMP_STAGING_DIR}"
guards:
  requireApprovedIncident: true
  minimumFreeSpaceBytes: "${DUMP_MIN_FREE_BYTES}"
  maximumDirectoryBytes: "${DUMP_MAX_DIR_BYTES}"
retention:
  classification: restricted-debug-evidence
  owner: runtime-debugging-oncall
  deleteAfterReview: true

包装脚本应先解析目标 PID 与所有者，再检查输出目录 ACL、可用空间和现有证据总量，最后才启动 ProcDump。脚本退出码至少区分：未找到唯一目标、权限拒绝、容量不足、触发窗口结束但未产出、dump 写入失败、取消成功。不要把 procdump.exe 的整段命令散落在 Wiki、聊天和个人计划任务中。

构建流水线则需要独立发布符号证据包。推荐顺序是：

编译一次得到 EXE/DLL 与 PDB，不在发布后重新编译“同版本”符号。计算二进制和 PDB 摘要，提取 PDB GUID/age。把 private PDB 发布到受限符号仓库，把允许外发的 public/stripped PDB 发布到另一个层级。

生成构建清单，绑定源码提交、编译配置、制品摘要和符号身份。用一个发布制品产生受控 dump，在干净分析机上只通过符号服务解析，验证源码行和私有函数。删除分析机临时缓存，确认没有依赖构建机偶然残留路径。

若使用 SymStore，先在隔离仓库演练 add、查询和事务回滚，再交给单写者流水线。符号仓库写权限只给发布身份，开发者和分析机使用只读权限；同一事务的清单、日志和摘要进入审计记录。

容量预算从触发频率和内存规模一起算

Full dump 的规模与进程可访问内存密切相关，不能把一个小测试程序的压缩比推广到所有服务。容量预估至少包含：

最坏单份大小 × 单次最大份数 × 同时受监控实例数
+ 符号缓存增长
+ TTD .run、可重建 .idx 与录制日志
+ WinDbg 日志与传输临时副本
+ 安全余量

采集前观察目标 commit、目录当前总量与磁盘可用空间：

$p = Get-Process -Id <target-pid>
$resolvedDumpDir = (Resolve-Path -LiteralPath $DumpDir).Path
$drive = [IO.DriveInfo]::new([IO.Path]::GetPathRoot($resolvedDumpDir))
[pscustomobject]@{
  PrivateBytes = $p.PrivateMemorySize64
  DumpDirectoryBytes = (Get-ChildItem $DumpDir -File -Recurse |
    Measure-Object Length -Sum).Sum
  AvailableFreeBytes = $drive.AvailableFreeSpace
}

PrivateMemorySize64 是该进程已提交的私有字节，不等于 ProcDump -m 判断的完整进程 commit，也不等于 Full dump 大小；这里把它作为容易取得的预算输入，并同时保留磁盘余量。需要让脚本复刻 -m 触发判断时，应使用经目标 PID 校验的 Windows 性能计数器并先处理同名实例映射，不能把这个属性直接代替官方触发指标。-mp 对 CLR 进程可能转成 Full；first-chance 触发可能在短时间连发；-r clone 并发会叠加瞬时资源。容量门禁应在启动前拒绝不安全计划，并在写入后重新检查，而不是等磁盘满了再删。

团队指标不要只看“采集成功率”，还应看触发次数、实际写出数、因容量/暂停预算跳过数、每份大小、目录总量、分析完成到销毁的年龄、符号命中率与 mismatch 数。阈值来自进程基线、磁盘预算和恢复目标，不使用脱离负载的万能数字。

权限提升必须是例外路径

调试同一用户拥有的测试进程通常不需要 SeDebugPrivilege。跨用户、LocalSystem 服务或本无权访问的进程可能需要 Debug privilege；它可以绕过常规进程访问边界，因此是高权限能力，不是“遇到 Access Denied 就以管理员重试”的快捷键。

权限失败按下面的证据顺序排查：

记录目标 PID、可执行路径、进程所有者和完整性级别。确认调试器/ProcDump 进程使用的账号、token 和架构。判断进程对象 ACL、组织策略、EDR 或受保护进程机制是否拒绝访问。

只在获得授权后，于故障窗口临时提升并记录审批与操作人。采集结束立即退出高权限会话，复核没有常驻监控、计划任务或调试器残留。

同一账号能打开测试进程、另一安全上下文的受控测试服务被拒绝、授权临时提升后成功，这组三段式实验比用系统关键进程做反例更安全。不要以 LSASS、受保护进程或生产核心服务作为教学靶标。

所有 dump 都先按高敏证据处理

Full dump 可能包含 token、连接串、Cookie、请求体、客户数据、明文密钥、文件路径和已经“释放”但仍残留在页面中的字节。扩展名是 .dmp 不会降低数据等级。ProcDump -mt、WinDbg .dump /mr 和 /mR 都只是减少某些数据，不能作为脱敏证明。

采集目录应满足以下条件：

本地加密存储，ACL 只允许故障处理角色和受控服务身份。不使用桌面、下载目录、公共共享盘或自动同步网盘。文件产生后立即记录 SHA-256、目标构建身份、采集工具版本和访问人。

传输走受控证据库，启用静态/传输加密、访问审计和到期销毁。分析前使用合成数据验证流程；真实 dump 不在普通编辑器、在线反编译网站或第三方 AI 服务中打开。

完整转储绝不能当作普通附件上传到公共工单、聊天群、邮件或无访问控制的 CI 制品区。 即便只发给同事，也要先按组织的数据分级与事故证据流程审批。需要外部厂商协助时，优先生成最小充分副本，并明确合同、传输、访问、地域和销毁边界。

清理不是删掉最后一个 .dmp

ProcDump 监控可用 Ctrl+C 结束，也可从另一会话取消：

.\procdump.exe -cancel <target-pid>

取消事件会影响监控同一目标的 ProcDump 实例，团队脚本要先列出 owner 和实例，避免误停别人的取证。若曾用 procdump -i 注册机器级 AeDebug 事后调试器，结束时必须撤销：

.\procdump.exe -u

不要把 -i 当作普通单次采集参数，它会改变机器级崩溃处理入口。live 调试器使用 qd 或 .detach 保留目标，并验证进程重新响应；若修改过线程 suspend count，还要配对恢复。

证据交接和保留期结束后，清理清单包括：

dump、CAB、WinDbg 日志和临时导出文本。TTD .run、.idx、录制日志和监控残留。传输暂存、副本、失败上传分片和分析机下载目录。

private PDB、临时源码映射和构建制品副本。downstream symbol cache 与调试扩展缓存。ProcDump 监控进程、AeDebug 注册和临时高权限会话。

符号 cache 是可重建派生数据，可以在确认路径后整体删除。AgeStore 支持按年龄或容量管理并可用 -l 预演，但依赖 NTFS Last Access Time；现代 Windows 默认配置常使该时间不可用。不要为了清一次缓存贸然修改文件系统行为并重启生产机。

常见失败要回到证据链定位

现象	先看什么	常见原因	修复后怎样再验证
ProcDump 报访问拒绝	PID、owner、token、ACL	跨安全上下文、策略或受保护进程	用同用户测试进程验证工具，再按审批临时提升
dump 能打开但某地址不可读	dump 类型与目标地址范围	Mini 未采集该内存	在隔离环境用 Mini/Full 对照，不对原文件强行补数据
只有系统栈，没有业务源码行	lm、.sympath、!sym noisy	private PDB 缺失、网络失败或身份 mismatch	.reload /f 后由 !lmi 核对 GUID/age
PDB 文件名正确仍拒载	RSDS 身份、GUID/age	来自另一次同名构建	恢复原构建 PDB，不忽略 mismatch
-e 1 很快写满目录	触发日志、过滤、-n	可处理 first-chance 异常过于频繁	降为 -e 或增加经验证过滤与硬上限
-h 没抓到服务挂死	进程是否有 GUI 窗口	-h 只看窗口消息响应	改用多时点 PID dump、线程与应用超时证据
attach 后服务更慢或不响应	暂停时长、线程 suspend/freeze	break、noninvasive 或残留 suspend	恢复计数、qd/.detach，验证请求重新流动
公共符号服务器不可达	TLS、代理、CA、DNS、缓存	企业网络限制或证书链失败	使用受控代理/预热缓存，保留证书校验

排障完成的标准不是“换管理员后能跑”，而是能说明哪一层失败、为什么失败、修复是否只扩大了必要权限，以及现场是否恢复。

团队把符号和转储当成一条受控供应链

成熟团队不让 dump 与 PDB 依赖某位开发者的笔记本。建议按职责拆成四层：

采集层：只负责识别目标、评估暂停与容量、按批准策略写出最小充分 dump。证据层：保存摘要、构建清单、访问审计、保留期限和销毁状态。符号层：发布不可变业务 PDB，分离 private/public 存储，提供只读查询和缓存。

分析层：使用隔离工作站与固定调试器基线，输出命令、符号身份和可复核结论。

符号服务应有单一发布 owner、只读消费者、构建身份索引、备份恢复演练和退役策略。Microsoft 公共符号服务放在业务符号之后，只作为系统模块来源。内部服务不可用时，分析应明确降级为地址与导出符号，不把不完整栈包装成最终结论。

转储策略则按问题逐级升级：线程/异常先从 Triage 或 Mini 起，证据明确缺少 private memory 时再申请 MiniPlus/Full。每次升级都重新评估暂停、文件大小、敏感内容、传输和保留期。这样，WinDbg 的价值不再是“某个人会敲 !analyze -v”，而是团队能证明一个地址属于哪次构建、一个判断依赖哪些内存、一次取证留下了什么影响，并在结论交付后把高敏证据彻底退出系统。