C#远程PowerShell执行Perl调用PsKill时输出流入错误流问题

1. 排查Perl脚本对外部程序输出的处理差异 #

• 对比异常脚本与正常PsKill脚本的代码，重点看调用外部程序（PsKill/CoreInfo）的语句：
  • 检查是否显式做了STDERR重定向，比如是否使用pskill.exe ... 2>&1这类写法，将工具的错误流合并到标准输出流。本地执行时，控制台会同时显示两个流的内容，但远程PowerShell会将未重定向的STDERR识别为错误记录。
  • 检查Perl调用外部程序的方式：用system()直接执行，还是用qx///反引号捕获输出，或是用IPC::Open3等模块处理流。不同方式对外部程序的STDERR传递逻辑不同，比如system()默认会把外部程序的STDERR直接传递给父进程（远程PowerShell），而某些模块可以手动合并流。

2. 远程PowerShell运行空间的流处理特性 #

• 远程WinRM会话对外部程序的输出流处理和本地PowerShell存在差异：
  • 本地PowerShell中，外部程序的STDERR仅会打印到控制台，不会进入PowerShell的错误流；但远程会话中，WinRM会将外部程序的STDERR映射到PowerShell的错误流（对应C#中ps.Streams.Error集合），这是远程输出序列化的默认行为。
  • 空行被转为System.Management.Automation.RemoteException，是因为远程会话在序列化输出时，会将空行或非标准输出包装为异常对象，属于WinRM传输的特性。

3. 检查Sysinternals工具自身的输出行为 #

• 部分Sysinternals工具（如PsKill、CoreInfo）的设计是将正常日志输出到STDERR而非STDOUT，这是工具本身的实现逻辑：
  • 本地执行时，控制台不区分STDOUT和STDERR，所以看起来输出正常；但远程PowerShell会将这些STDERR内容判定为错误，进入错误流。
  • 对比正常的PsKill脚本，是否调用参数不同？某些参数可能会让PsKill将输出切换到STDOUT，或是脚本中做了流重定向抵消工具的默认行为。

4. C#端PowerShell实例的配置与调用方式 #

• 检查C#中创建远程运行空间的配置：是否设置了影响流处理的参数（如OutputBufferingMode），是否有特殊的错误捕获规则。
• 尝试在C#的AddScript中直接添加流重定向，比如修改为：

  ps.AddScript($"perl.exe {perlScriptPath} {perlScriptArgs} 2>&1");
  

  把Perl进程的STDERR合并到STDOUT，统一从输出流获取内容，避免被远程PowerShell识别为错误。

5. 排查远程会话的环境差异 #

• 确认远程运行空间的环境变量、权限与本地手动执行时是否一致：
  • 比如远程会话的PATH是否包含Sysinternals工具的路径，是否有执行权限差异导致输出行为变化（不过用户提到手动执行正常，此点优先级较低）。

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