用途：面向 dotnet 仓库在 Helix 分布式测试基础设施上的 CI 测试崩溃，帮助定位崩溃工作项、下载转储并分析。仅用于“崩溃”而非普通断言失败；普通失败应用 ci-analysis，本地已有转储或构建失败不适用。
主要流程：1) 若是 PR，用 ../ci-analysis/scripts/Get-CIStatus.ps1 -PRNumber <PR> -Repository "dotnet/runtime" -ShowLogs 或 -BuildId 找失败 Helix 作业；若是 issue，从正文与评论找 AzDO 构建链接，优先最新构建，跳过 PR 关联。不要照抄已有堆栈，需独立分析。2) 先看控制台日志，dotnet/runtime 可能已有 cdb 符号化堆栈（~k、!clrstack -all）。3) 查 Helix API 工作项详情，名称需 URL 编码；Files 的 URI 可能失效，下载用 ListFiles 端点。崩溃表现为负值或较大 ExitCode，并有 .dmp 或 .crashreport.json；无则停止并建议用 ci-analysis。4) 下载优先 .crashreport.json 与 .dmp；重复转储时 Windows 优先 (1) 的 createdump 版本，Linux 优先 coredump..dmp。
调试：dotnet-dump 版本需与转储运行时匹配，可用 dotnet tool install -g dotnet-dump --prerelease；匹配不到时用 cdb。先做 modules -v，用 setclrpath 指向 payload 运行时二进制。Windows 原生崩溃用 cdb，Linux/macOS 用 lldb + SOS；NativeAOT 不用 SOS。管理型崩溃从 pe 与 clrstack -all 开始。
限制：Helix 工件 20 天过期，AzDO 构建也受保留策略限制；移动端/WASM 转储不覆盖；dnceng 内部作业需代理没有的认证，应转交用户。分析后需报告构建链接、退出码含义、崩溃线程堆栈、托管异常、已有相关 issue 链接，并结合 PR 改动判断原因。