System.Diagnostics.Process运行编码PowerShell命令加注释行报错

这个报错和新增行是注释、不会被PowerShell执行没有任何关系，问题出在Windows创建带用户凭据进程时的命令行长度硬限制：

• 当ProcessStartInfo配置了Domain/UserName/Password凭据参数，且UseShellExecute = $false时，.NET底层会调用Windows原生API CreateProcessWithLogonW启动进程。该API对传入的完整命令行字符串有强制长度限制：最多支持1024个Unicode字符，超出后会直接返回"参数不正确"错误，进程根本不会启动，自然也轮不到PowerShell解析命令里的注释内容。
• 不传入凭据时，底层调用的是CreateProcessWAPI，命令行长度上限为32767个Unicode字符，长度冗余充足，即使新增注释行总长度也不会超限，所以可以正常运行。
• 你新增的注释行虽然不会被执行，但它属于脚本块的文本内容，会和其他代码一起被编码进-EncodedCommand后的Base64字符串中。Base64编码本身会让原文本长度膨胀约33%，新增的注释内容刚好把拼接后的完整命令行长度推过1024字符的阈值，直接触发API层报错。

在调用$Process.Start()前加一行代码输出命令行长度，就能直观看到差异：

Write-Host "完整命令行总字符数: $($ProcessStartInfo.Arguments.Length)"

新增注释行前长度低于1024，新增后长度超过1024，和报错的触发条件完全吻合。

• 精简脚本块内容：删除不必要的注释、空行、冗余字符，把最终拼接的命令行总长度控制在1024字符以内。
• 改用文件传参：不要把全部脚本逻辑直接塞进-EncodedCommand，可以把核心脚本写入临时.ps1文件，启动PowerShell时用-File参数指向该临时文件，命令行只需要传文件路径，长度会大幅缩短。
• 绕开API限制：如果必须执行长脚本，可以通过计划任务等其他方式启动带凭据的进程，避开CreateProcessWithLogonW的长度限制。

额外提示：你原代码中–NoProfile参数前的短横是U+2013长破折号，不是标准半角减号，虽然不是本次报错的诱因，但在部分环境下可能导致参数识别失败，建议替换为标准半角减号写法-NoProfile。

内容的提问来源于stack exchange，提问作者Alexey I. Kuzhel