在不同的机器Process.WaitForExit不一致 [英] Process.WaitForExit inconsistent across different machines

问题描述

这code运行正常在大量的机器。然而在一个特定的机器中，调用 WaitForExit（）似乎被忽略，而事实上标记为退出过程

This code runs as expected on a large number of machines. However on one particular machine, the call to WaitForExit() seems to be ignored, and in fact marks the process as exited.

static void Main(string[] args)
{
    Process proc = Process.Start("notepad.exe");
    Console.WriteLine(proc.HasExited); //Always False
    proc.WaitForExit(); //Blocks on all but one machines
    Console.WriteLine(proc.HasExited); //**See comment below
    Console.ReadLine();
}

请注意，与类似的问题，被调用的过程是 NOTEPAD.EXE （用于测试的原因），所以这是不可能的过错在于它 - 即，它不会产卵第二子进程和关闭。即便如此，也不能解释为什么它适用于所有的其他机器。

Note that unlike a similar question on SO, the process being called is notepad.exe (for testing reasons), so it is unlikely the fault lies with it - i.e. it is not spawning a second sub-process and closing. Even so, it would not explain why it works on all the other machines.

在有问题的机器，到了第二个电话 Console.WriteLine（proc.HasExited））返回真连虽然记事本依然清晰开阔，无论是在屏幕上，在任务管理器。

On the problem machine, the second call to Console.WriteLine(proc.HasExited)) returns true even though notepad is still clearly open, both on the screen and in the task manager.

本机运行的是Windows 7和.NET 4.0。

The machine is running Windows 7 and .NET 4.0.

我的问题是;什么条件特定的计算机上可能会造成这个？我应该怎么检查？

My question is; what conditions on that particular machine could be causing this? What should I be checking?

修改 - 事情我已经试过到目前为止/更新/可能相关的信息：

• 重新安装.NET。
• 关闭所有过程我不知道在任务管理器做的。
• 的Windows尚未启动这台机器上。
• 在评论意见之后，我试着让使用现有的进程ID GetProcessesByName 但这只是返回有问题的机器上的一个空数组。因此，很难说的问题是，即使 WaitForExit ，因为这个过程是通过调用 GetProcessesByName 之前不会返回调用 WaitForExit 。
• 在有问题的机器，所产生的记事本进程的PARENTID是记事本程序的code手动启动，或者换句话说，记事本是产卵一个子进程，并终止自己的ID。

• Reinstalled .NET.
• Closed any processes I don't know in task manager.
• Windows has not yet been activated on this machine.
• Following advice in the comments, I tried getting the 'existing' process Id using GetProcessesByName but that simply returns an empty array on the problem machine. Therefore, it's hard to say the problem is even with WaitForExit, as the process is not returned by calling GetProcessesByName even before calling WaitForExit.
• On the problem machine, the resulting notepad process's ParentID is the ID of the notepad process the code manually starts, or in other words, notepad is spawning a child process and terminating itself.

推荐答案

现在的问题是，默认情况下Process.StartInfo.UseShellExecute设置为true。有了这个变量设置为TRUE，而不是自己开始的过程中，你所要求的壳启动它。这可以说是相当useful-它可以让你做的事情一样执行的HTML文件（shell将使用相应的默认应用程序）。

The problem is that by default Process.StartInfo.UseShellExecute is set to true. With this variable set to true, rather than starting the process yourself, you are asking the shell to start it for you. That can be quite useful- it allows you to do things like "execute" an HTML file (the shell will use the appropriate default application).

它不是当你想执行它（如你发现）后，跟踪应用程序，因为启动应用程序有时会弄不清楚哪个实例应该跟踪这么好。

Its not so good when you want to track the application after executing it (as you found), because the launching application can sometimes get confused about which instance it should be tracking.

在这里的，为什么出现这种情况的内部细节很可能是超出了我的能力，答案 - 我不知道，当UseShellExecute == true，则框架使用的ShellExecuteEx的Windows API，而当它UseShellExecute ==假的，它使用CreateProcessWithLogonW，但为什么人们会导致可追踪流程和其他不，我不知道，因为他们似乎都返回的进程ID。

The inner details here of why this happens are probably beyond my capabilities to answer- I do know that when UseShellExecute == true, the framework uses the ShellExecuteEx Windows API, and when it UseShellExecute == false, it uses CreateProcessWithLogonW, but why one leads to trackable processes and the other doesn't I don't know, as they both seem to return the process ID.

编辑：一个小挖之后：

这个问题指着我到的 SEE_MASK_NOCLOSEPROCESS 标志，这确实似乎使用的ShellExecute时设置。该文档屏蔽值状态：

This question pointed me to the SEE_MASK_NOCLOSEPROCESS flag, which does indeed seem to be set when using ShellExecute. The documentation for the mask value states:

在某些情况下，当执行通过DDE满足如   交谈中，无柄将返回。调用应用程序   负责关闭手柄，当它不再需要。

In some cases, such as when execution is satisfied through a DDE conversation, no handle will be returned. The calling application is responsible for closing the handle when it is no longer needed.

因此​​，它确实表明，在返回的进程句柄是不可靠的。我还没有得到足够深，可以知道哪些特定的边缘情况下，你可能会在这里打不过。

So it does suggest that returning the process handle is unreliable. I still have not gotten deep enough to know which particular edge case you might be hitting here though.

这篇关于在不同的机器Process.WaitForExit不一致的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！