我来帮你梳理几个常见的崩溃转储获取途径，结合你在Windows 10构建服务器上的场景（系统用户运行、GitLab Runner环境），你可以按以下步骤排查：

1. 检查Windows错误报告（WER）的默认存储位置 #

Windows默认会将崩溃报告存储在以下路径（需要管理员权限访问）：

• C:\ProgramData\Microsoft\Windows\WER\ReportArchive：归档的崩溃报告文件夹，每个崩溃对应一个以应用名+时间戳+报告ID命名的文件夹
• C:\ProgramData\Microsoft\Windows\WER\ReportQueue：临时队列中的报告

你可以用事件日志里的Report Id: 50c971eb-e126-4a05-ad73-b56a570a7abe去匹配文件夹名称，找到对应的崩溃包，里面的.dmp文件就是转储文件（通常是小转储，已经包含基础栈追踪信息）。

2. 查看是否配置了本地崩溃转储 #

如果服务器提前配置了本地崩溃转储（通过注册表或组策略），转储文件会存在指定路径：

• 打开注册表编辑器（regedit），导航到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe
• 查看DumpFolder值：这里就是自定义的转储存储路径
• DumpType值：如果是2表示完整转储（包含所有进程内存），1是小转储（足够获取栈追踪）

如果没有配置，建议手动添加这个注册表项来强制生成转储：

1. 右键LocalDumps项，新建项，命名为MyApp.exe
2. 右键新建的MyApp.exe项，新建字符串值，命名为DumpFolder，值设为你想要的路径（比如C:\CrashDumps）
3. 新建DWORD值，命名为DumpType，值设为2（完整转储）或1（小转储）
4. 新建DWORD值，命名为DumpCount，值设为10（保留最新的10个转储）
5. 确保C:\CrashDumps文件夹给SYSTEM用户分配了完全控制的权限（因为你的应用是系统用户运行的）

3. 用Sysinternals ProcDump手动捕获转储 #

如果默认转储没生成，或者你需要更灵活的捕获方式，可以用ProcDump工具（微软Sysinternals套件里的免费工具，无需安装）：

• 下载ProcDump后，在GitLab Runner的测试脚本里，把启动MyApp的命令替换成：

  procdump -e -t -w MyApp.exe C:\CrashDumps
  

  参数说明：
  • -e：捕获未处理的异常
  • -t：捕获进程终止事件
  • -w：等待MyApp进程启动后再附加
    这样应用崩溃时，会自动在C:\CrashDumps生成带栈追踪的转储文件。

4. 用调试器自动生成转储 #

如果可以在服务器上操作，你也可以用WinDbg或Visual Studio调试器来自动捕获转储：

• 用WinDbg命令行的方式，在测试脚本里启动MyApp：

  windbg -g -G -c ".dump /ma C:\CrashDumps\MyApp_crash.dmp; q" MyApp.exe
  

  参数说明：
  • -g：忽略初始断点
  • -G：忽略进程终止断点
  • -c：指定崩溃时执行的命令（生成完整转储后退出调试器）
    这样应用崩溃时会自动生成完整转储，你可以用WinDbg或Visual Studio打开.dmp文件查看栈追踪。

另外，事件日志里的0xc0000005是访问违规错误，通常是因为非法访问内存（比如空指针、越界读写），转储文件里的栈追踪会帮你定位到具体的代码行，记得要配合MyApp的PDB符号文件（编译时生成的）一起分析，这样才能看到准确的函数名和行号。

备注：内容来源于stack exchange，提问作者Alexey Starinsky