Process.Start 在某些客户端上随机阻塞/挂起
（有一个非常相似的主题从未得到解决：此处）
我们正在运行一个大型应用程序在几个客户端上，但最近我的一些代码停止工作。添加一些调试代码，我发现代码在调用 Process.Start() 时停止（没有设置 shellexecute=true）。
调用很简单
Process.Start(new ProcessStartInfo("program"))
在BackgroundWorker 线程中的
。 “程序”应用程序执行其应该执行的操作并退出。
当线程在后台时，我们的应用程序会继续运行，但如果应用程序在 GUI 线程上运行另一个 Process.Start，则应用程序会锁定。如果使用 X 按钮关闭应用程序，则应用程序仍会显示在任务管理器中，因为线程仍被 Process.Start 阻止。
问题是这种行为无法重现。它在某些客户端计算机上随机发生。
什么情况会导致 Process.Start() 挂起？ （Program.Main 标记为 [STAThread] ）
我目前刚刚做了一个解决方法，在自己的线程中启动 Process.Start() ，如果到那时还没有返回，则在 5 秒后将其杀死。但对于用户等待代码返回来说，这 5 秒太多了（我不知道我可以将超时设置多低，因为在某些情况下我需要 Process.Start() 的返回值）。
会不会有杀毒软件干扰？ （客户端安装了 Symantec AV）
更新：我假设当我执行
ProcessStartInfo psi = new ProcessStartInfo("ping", "localhost");
psi.UseShellExecute 默认情况下为 FALSE...这是不正确的。它默认为 TRUE。这是正常的吗？
(There is a very similar topic that never got solved: here)
We have a big app running on several clients, but recently some of my code stopped working. Adding some debug code I found out the code stops at a call to Process.Start() (with no shellexecute=true set).
The call is a simple
Process.Start(new ProcessStartInfo("program"))
in a BackgroundWorker thread.
The "program" app does what it should do and exits.
Our application continues as the thread is in the background but if the application runs another Process.Start on the GUI thread, the app locks up. If the application is closed with the X button the app still shows in taskmanager as the thread is still blocked by the Process.Start.
The problem is that this behavior can not be reproduced. It happens randomly on some clients computers.
What could happen to make Process.Start() hang? (Program.Main is marked with [STAThread] )
I have currently just made a workaround that launches the Process.Start() in its own thread, killing it after 5 seconds if it has not returned by then. But that is 5 seconds to much for the user waiting for the code to return ( I do not know how low i can set the timeout as I need the return value on Process.Start() in some cases ).
Can there be antivirus softwares interfering? (the clients has Symantec AV installed)
UPDATE: I assumed that when i did a
ProcessStartInfo psi = new ProcessStartInfo("ping", "localhost");
that psi.UseShellExecute was FALSE by default... This is not correct. It defaults to TRUE. Is this normal?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我知道这个线程有点旧，但如果有人感兴趣，这是由 shell 扩展（在本例中为防病毒软件）引起的。基本上，当您以 UseShellExecute=true（默认）启动时，防病毒软件会干扰 Processor.Start 并使其挂起（似乎是随机的）。有趣的是，该进程启动得很好，只是调用者线程挂起。
我们在客户的一台服务器上启用赛门铁克病毒防护时遇到了同样的问题。我们通过在防病毒软件上设置例外来修复它。或者，您可以禁用 UseShellExecute。
I understand this thread is kind of old, but if anyone is interested, this is caused by a shell extension(in this case, the antivirus software). Basically, when you start with UseShellExecute=true(default), the antivirus software interferes with Processor.Start and makes it hang(seems to be random). Interestingly, the process starts just fine, it's the caller thread that hangs.
We had the very same issue with Symantec Virus protection being enabled in one of our client's servers. We fixed it by setting up exceptions on the antivirus software. Alternatively, you can disable UseShellExecute.
不久前我遇到了一个问题，如果其他进程在错误的时间读取程序输出，则向外部进程进行 shell 处理可能会导致竞争条件。这可能就是你所看到的吗？
有关有关 StandardOutput 的 MSDN 文章的更多信息。
编辑：记忆慢慢恢复。我在 process.WaitforExit() 之后使用 process.ReadToEnd()。输出缓冲区非常小，因此有效地填满然后停止，等待某些东西（我，即进程调用者）读取它。当然它无法做到这一点，因为我的代码仍在等待该过程完成。
将 process.ReadToEnd() 放在 WaitForExit() 之前为我解决了这个问题，尽管听起来很直观。但如果你没有向控制台输出详细的输出，那么它可能完全是另一回事......
I had a problem a while ago where shelling out to an external process could lead to a race condition if something else was reading the program output at the wrong time. Could this be what you're seeing?
More information on the MSDN article on StandardOutput.
edit: Memory slowly returns. I was using process.ReadToEnd() after process.WaitforExit(). The output buffer is quite small so was effectively filling up then stopping, waiting for something (me, i.e the process caller) to read it. Which of course it couldn't do because my code was still waiting for the process to finish.
Putting process.ReadToEnd() before WaitForExit() fixed it for me, couterintuitive though that sounds. But if you're not spitting verbose output to the console then it's probably something else entirely...