我来帮你一步步拆解这个问题——退出码-1但ProcDump没触发转储，大概率是因为你遇到的不是原生层面的崩溃（比如访问违规那种会触发AeDebug的场景），而是.NET进程特有的终止逻辑，或者捕获策略没覆盖到对应的场景。咱们从这几个方向入手：

1. 先搞清楚退出码-1的真实原因 #

首先得确认进程到底是怎么退出的：

• 先检查代码里有没有主动调用Environment.Exit(-1)的逻辑，或者有没有未处理的托管异常导致CLR直接终止进程（这种情况AeDebug是不会触发的，因为CLR会自己处理终止流程）。
• 可以先试试让CLR自己生成转储：设置环境变量COMPlus_DbgEnableMiniDump=1，然后启动进程，一旦进程因托管异常崩溃，会在当前目录生成迷你转储，文件名一般是dotnet_<PID>.dmp（.NET Core/.NET 5+）或者对应进程名加PID的格式（.NET Framework）。

2. 调整ProcDump的捕获策略，不要只依赖AeDebug #

AeDebug模式只针对原生SEH异常，对.NET托管异常无效。直接用ProcDump主动监控进程，覆盖托管异常场景：

• 用ProcDump启动你的程序，捕获所有未处理异常：

  procdump -e 1 -f "" -ma YourConsoleApp.exe
  

  参数说明：
  • -e 1：捕获未处理的异常（包括托管异常）
  • -f ""：不筛选异常类型，捕获所有异常
  • -ma：生成完整内存转储，方便后续分析
• 如果程序是后台启动的，也可以附加到运行中的进程：

  procdump -e 1 -f "" -ma <进程PID>
  

3. 优化CDB的调试配置，不要跳过所有异常 #

你之前用sxd av;sxd *;g等于让调试器跳过所有异常直接运行，根本看不到问题触发点。针对.NET进程，要加载SOS扩展并捕获托管异常：

1. 用CDB启动程序后，先加载SOS调试扩展：
   • .NET Framework：.loadby sos clr
   • .NET Core/.NET 5+：.loadby sos coreclr
2. 设置捕获所有托管异常：

   !soe System.Exception 1 1
   

   这个命令会让调试器在抛出任何System.Exception时立即中断，你就可以用!clrstack查看托管调用栈，定位问题了。
3. 最后再执行g让程序继续运行。

4. 检查权限与转储路径问题 #

个人账号运行时，要确保ProcDump有写入转储文件的权限：

• 默认转储会生成在当前目录，检查当前目录是否有写入权限，或者直接指定一个有权限的路径：

  procdump -e 1 -ma -o C:\Dumps\ YourConsoleApp.exe
  

  -o参数表示如果转储文件已存在，直接覆盖。

5. 排查是否是外部因素终止进程 #

退出码-1也可能是进程被外部终止（比如任务管理器、系统资源不足被杀死、其他服务终止）：

• 打开事件查看器，检查这几个日志：
  • Windows日志->系统：找Event ID 10016（权限相关）、Event ID 7036（进程状态变化）
  • Windows日志->应用程序：找.NET运行时的错误日志，里面会记录托管异常的详细信息，甚至是进程被终止的原因。

内容的提问来源于stack exchange，提问作者mark