C# 和 psexec 进程输出重定向问题
我正在尝试创建一个在集中式设备上运行的小程序。该程序将运行
“psexec \服务器netstat -na | findstr“正在监听””
从远程节点收集 netstat 数据(应将输出重定向到字符串),然后解析数据并与已知列表进行比较。我可以在 cmd 行中运行上面的 psexec
cmd,而不会出现任何问题,但是当我尝试在 C# 程序中运行与进程相同的命令时,不会返回任何数据进行解析。我可以看到 netstat
正在运行(cmd 窗口闪烁着 netstat 结果),但 process.standardoutput 没有捕获流。如果我使用 ping 或除 psexec
之外的任何其他内容作为参数,流将被捕获,结果将显示在我的文本框中。我还尝试将文件名设置为 psexec.exe 并指定参数,但得到相同的结果。最后但并非最不重要的一点是,如果我在没有任何参数的情况下运行 psexec,我会在文本框中返回帮助回扣信息。如果我运行 psexec.exe
作为文件名,或者如果我运行 cmd.exe
作为文件名,并将“/c psexec”指定为 args<,则情况如此。 /代码>。
我只是想在本地执行时捕获 psexec 输出。稍后我会担心 psexec 到远程计算机。任何帮助将不胜感激。
这是代码:
System.Diagnostics.Process pProcess = new System.Diagnostics.Process();
pProcess.StartInfo.FileName = "cmd.exe";
pProcess.StartInfo.Arguments = "/c psexec netstat";
pProcess.StartInfo.UseShellExecute = false;
pProcess.StartInfo.RedirectStandardOutput = true;
pProcess.Start();
string strOutput = pProcess.StandardOutput.ReadToEnd();
pProcess.WaitForExit();
if (pProcess.HasExited)
{
textBox1.Text = strOutput;
}
else
{
textBox1.Text = "TIMEOUT FAIL";
}
I'm trying to create a small program to run on a centralized device. This program will run
"psexec \server(s) netstat -na | findstr "LISTENING""
to collect netstat data from remote nodes (should redirect output to string), then parse the data and compare against a known list. I can run the psexec
cmd above without any issues from the cmd line, but when I try to run the same command as a process within my C# program, no data is returned to be parsed. I can see that the netstat
is being run (cmd window flashes with netstat results), but the process.standardoutput is not catching the stream. If I use ping or pretty much anything other than psexec
as an argument, the stream is caught and the results are shown in my text box. I've also tried setting the filename to psexec.exe and specifying the arguments but I get the same results. Last but not least, if I run psexec without any arguments, I get the help kickback info returned in my textbox. This is true if I'm running psexec.exe
as the filename OR if I run cmd.exe
as filename with "/c psexec" specified as args
.
I'm just trying to get psexec output to be caught when executing locally at this point. I'll worry about psexec to remote machines later. Any help would be MUCH appreciated.
Here's the code:
System.Diagnostics.Process pProcess = new System.Diagnostics.Process();
pProcess.StartInfo.FileName = "cmd.exe";
pProcess.StartInfo.Arguments = "/c psexec netstat";
pProcess.StartInfo.UseShellExecute = false;
pProcess.StartInfo.RedirectStandardOutput = true;
pProcess.Start();
string strOutput = pProcess.StandardOutput.ReadToEnd();
pProcess.WaitForExit();
if (pProcess.HasExited)
{
textBox1.Text = strOutput;
}
else
{
textBox1.Text = "TIMEOUT FAIL";
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我建议还捕获标准错误输出,以防那里报告任何内容。
此外,如果您在 64 位操作系统上运行,则 psexec 的“位数”与您的应用程序之间可能会出现脱节。如果是这种情况,请更改项目的平台以匹配 psexec 的平台,而不是构建为任何 CPU。
I would recommend also capturing the standard error output in case anything is being reported there.
Also, you may have a disconnect between "bitness" of psexec and your application if you are running on a 64-bit OS. If this is the case, change the platform for the project to match that of psexec rather than building as Any CPU.
遇到了一些需要更改的事情,但您关于捕获标准错误输出的建议是完全正确的,并且是一个良好的开始。事实证明,一些信息被发送到错误输出(即使实际上不是错误,只是从 psexec 运行状态 0),所以我知道此时 psexec 不仅仅吃掉所有输出。一旦我开始尝试将远程主机作为参数传递,我就开始获取用户/传递错误数据。如果我想为 proc 运行提供凭据,还需要捕获标准输入。添加一些 str 文字和远程执行的凭据,效果很好。感谢您的帮助。这是更新后的代码——
Came across a few things to be changed but your recommendation of capturing standard error output was dead on and a good start. Turns out some info was being sent to the error output (even though really wasn't error, just run status 0 from psexec) so I knew at that point psexec wasn't just eating ALL the output. Once I started trying to pass remote hosts as args, I started getting user/pass error data back. Also needed to catch standard input if I wanted to supply credentials for proc run. Threw in some str literals and credentials for the remote exec, works perfectly. Thanks for the help. Here is the updated code--