C#托管调用链下Go侧STDERR重定向失效问题排查

你观察到的调试/非调试场景差异，本质是stderr重定向只覆盖了C运行时（CRT）层的文件描述符映射，没有同步修改Windows系统原生的进程标准错误句柄，结合CLR对跨边界未处理异常的特殊处理逻辑，共同导致了重定向失效。

逻辑链路拆解 #

• 现有RedirectStdError的实现仅做了CRT层的重定向：通过_open_osfhandle把error.std的文件句柄绑定为新的CRT文件描述符，再用_dup2替换CRT内部维护的stderr描述符。这套逻辑仅能捕获走CRT标准流（比如fprintf(stderr, ...)、Go的fmt.Fprint(os.Stderr, ...)）的输出。
• 附加VS调试器时，CLR检测到调试器存在，触发的除零异常会被调试器事件机制拦截，异常堆栈输出走CRT标准流路径，刚好被重定向的fd接住，因此可以正常写入error.std。
• 无调试器运行时，CLR发现未处理异常是从非托管边界回调进入的托管方法中抛出的，会直接判定为不可恢复的致命错误，走快速终止流程：
  • 完全绕开CRT标准流层，直接调用Windows原生API GetStdHandle(STD_ERROR_HANDLE) 获取进程启动时绑定的原始stderr句柄写崩溃信息
  • 写完后直接终止进程，不执行任何流刷新、托管层异常处理逻辑
  • 这种场景下CRT层的重定向完全不生效，自然抓不到错误信息。

现有代码的固有缺陷 #

• 重定向范围不完整：仅修改CRT层的fd映射，没有替换Windows系统级的stderr句柄，无法捕获所有路径的stderr输出
• 跨边界异常处理缺失：被非托管代码回调的C#方法如果抛出未捕获异常，CLR会直接终止进程，不会进入任何常规异常处理流程

1. 补全全链路stderr重定向
   打开error.std拿到文件句柄后，先调用Windows原生API替换系统级的stderr句柄，再保留原有CRT层重定向逻辑：

   // 增加系统级句柄重定向
   C.SetStdHandle(C.STD_ERROR_HANDLE, C.HANDLE(f.Fd()))
   // 原有_open_osfhandle、_dup2逻辑保持不变
   

   这样不管是走CRT流，还是直接调用原生API写stderr句柄的逻辑，都会把内容写入error.std。
2. 拦截跨边界的未处理异常
   在被非托管代码回调的C#方法外层包裹全捕获的try/catch逻辑，避免异常直接穿透到非托管边界：

   private static IntPtr SomeMethodWithError(IntPtr messagePtr) {
       try {
           Console.WriteLine("|-C#->Back to C#");
           var a = 0;
           Console.WriteLine("|-C#->ERROR HAPPENS HERE C#");
           var b = 10 / a;
           Console.WriteLine(b);
           return IntPtr.Zero;
       } catch (Exception ex) {
           // 手动捕获异常信息，通过常规stderr通道输出
           Console.Error.WriteLine(ex.ToString());
           return IntPtr.Zero;
       }
   }
   

   这一步可以从根源上避免CLR触发快速终止路径，让所有错误信息都走常规流输出逻辑。

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