C# .NET Core 捕获外部进程stdout实现双路输出的故障排查

先讲你现在遇到问题的本质：

• 只要开了UseShellExecute = false + RedirectStandardOutput = true，.NET运行时就会在调用CreateProcess时，把子进程的stdout句柄直接替换成父进程生成的匿名管道写端。这个操作会彻底切断子进程和自身控制台窗口的stdout连接，子进程往stdout写的所有内容都会直接进管道，根本不会流到自己的控制台屏幕，窗口自然就是空白的。
• 你的父程序是Windows桌面输出类型（编译后是WinExe），进程启动时根本不会关联任何控制台设备，Console.Out对应的就是个无效空流，哪怕你在后台线程里调Console.Out.WriteLine，内容也没地方去，更不可能跑到子进程的控制台窗口上。

要同时满足「全量捕获子进程stdout存本地文件」+「子进程控制台窗口正常显示输出」，核心是做stdout流的分支分流（和Linux下的tee命令效果完全一致），让同一份输出同时流向两个目的地：本地存档文件、子进程自己的控制台屏幕。

核心实现逻辑 #

• 放弃使用.NET内置的单向stdout重定向，改用Windows原生API实现带分流能力的管道
• 创建中介管道对，把管道的写端设置为子进程的stdout继承句柄，让子进程正常往管道写内容
• 父进程通过后台线程持续从管道读端读取所有输出内容，同时执行两个操作：
  • 逐行写入本地文本文件存档
  • 通过Windows控制台API把内容转发到子进程关联的控制台屏幕缓冲区，保证控制台窗口能正常显示输出

关键实现约束 #

• 不能为了让控制台正常显示就设置UseShellExecute = true，这种方式是通过系统Shell启动子进程的，父进程完全拿不到子进程的stdout管道句柄，根本无法捕获内容做存档
• 启动子进程时不要设CreateNoWindow = true，必须保留子进程的独立控制台窗口，才能正常关联控制台句柄
• 管道句柄要配置为可被子进程继承，避免子进程因为找不到有效stdout句柄直接崩溃
• 管道读取逻辑必须放在独立的后台线程持续运行，避免管道缓冲区写满导致子进程阻塞
• 要同步处理stderr的分流逻辑，避免子进程输出大量错误内容时触发进程阻塞

为什么你之前的调试思路行不通 #

只要你开了.NET内置的输出重定向，子进程的stdout就已经和自身控制台完全断开了——哪怕你把读到的内容再往回流，因为Windows控制台句柄是进程隔离的，你没有权限把父进程读到的内容直接写到子进程的控制台缓冲区（除非你用底层API显式关联子进程的控制台句柄），所以单纯靠在父进程里调Console.Out.WriteLine是永远不可能把内容显示到子进程窗口上的。

简化实现参考 #

可以参考下面的核心API调用逻辑替换原有代码：

// 首先定义Windows API所需的结构和导入
[StructLayout(LayoutKind.Sequential)]
private struct SECURITY_ATTRIBUTES
{
    public int nLength;
    public IntPtr lpSecurityDescriptor;
    public int bInheritHandle;
}

[DllImport("kernel32.dll", SetLastError = true)]
private static extern bool CreatePipe(out IntPtr hReadPipe, out IntPtr hWritePipe, 
    ref SECURITY_ATTRIBUTES lpPipeAttributes, int nSize);

[DllImport("kernel32.dll", SetLastError = true)]
private static extern bool SetHandleInformation(IntPtr hObject, uint dwMask, uint dwFlags);

原有进程启动逻辑替换要点：

1. 初始化可继承的安全属性结构，创建双向分流管道
2. 把管道的写句柄配置到子进程启动参数的stdout字段，让子进程正常输出
3. 后台线程持续读取管道内容，同步写文件、转发到子进程控制台

注：如果不想自行封装底层Windows API逻辑，可以直接使用社区封装好的控制台分流组件，适配现有代码的成本很低，不需要改动业务流程。

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