这篇文章可能过时了，但我发现它通常挂起的主要原因是由于堆栈溢出的redirectStandardoutput或如果你有redirectstandderror。

由于输出数据或错误数据比较大，在不确定的时间内仍在处理，会造成挂起时间。

为了解决这个问题:

p.StartInfo.RedirectStandardoutput = False
p.StartInfo.RedirectStandarderror = False

我也有同样的问题，但原因不同。但是在Windows 8下会发生，而在Windows 7下不会。下面这行似乎是导致这个问题的原因。

pProcess.StartInfo.UseShellExecute = False

解决方案是不禁用UseShellExecute。我现在收到一个Shell弹出窗口，这是不需要的，但比程序等待什么特别的事情发生要好得多。所以我添加了如下的解决方法:

pProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden

现在唯一让我困扰的是为什么在Windows 8下会出现这种情况。

问题是，如果你重定向StandardOutput和/或StandardError，内部缓冲区可能会满。不管你用什么顺序，都会有一个问题:

如果在读取StandardOutput之前等待进程退出，进程可能会阻塞尝试写入它，因此进程永远不会结束。 如果你使用ReadToEnd从StandardOutput中读取，那么如果进程从未关闭StandardOutput(例如，如果它从未终止，或者如果它被阻塞写入到standderror)，那么你的进程就会阻塞。

解决方案是使用异步读取来确保缓冲区不会被填满。为了避免死锁并从StandardOutput和standderror收集所有输出，你可以这样做:

编辑:请参阅下面的回答，了解如何在超时发生时避免ObjectDisposedException。

using (Process process = new Process())
{
    process.StartInfo.FileName = filename;
    process.StartInfo.Arguments = arguments;
    process.StartInfo.UseShellExecute = false;
    process.StartInfo.RedirectStandardOutput = true;
    process.StartInfo.RedirectStandardError = true;

    StringBuilder output = new StringBuilder();
    StringBuilder error = new StringBuilder();

    using (AutoResetEvent outputWaitHandle = new AutoResetEvent(false))
    using (AutoResetEvent errorWaitHandle = new AutoResetEvent(false))
    {
        process.OutputDataReceived += (sender, e) => {
            if (e.Data == null)
            {
                outputWaitHandle.Set();
            }
            else
            {
                output.AppendLine(e.Data);
            }
        };
        process.ErrorDataReceived += (sender, e) =>
        {
            if (e.Data == null)
            {
                errorWaitHandle.Set();
            }
            else
            {
                error.AppendLine(e.Data);
            }
        };

        process.Start();

        process.BeginOutputReadLine();
        process.BeginErrorReadLine();

        if (process.WaitForExit(timeout) &&
            outputWaitHandle.WaitOne(timeout) &&
            errorWaitHandle.WaitOne(timeout))
        {
            // Process completed. Check process.ExitCode here.
        }
        else
        {
            // Timed out.
        }
    }
}

在阅读了这里所有的帖子之后，我确定了Marko avlijaovic的统一解决方案。 然而，它并没有解决我所有的问题。

在我们的环境中，我们有一个Windows服务，计划运行数百个不同的.bat .cmd .exe，…等等，这些文件积累了多年，由许多不同的人以不同的风格编写。我们无法控制程序和脚本的编写，我们只负责调度、运行和成功/失败的报告。

所以我尝试了这里所有的建议，并取得了不同程度的成功。Marko的回答几乎是完美的，但是当作为服务运行时，它并不总是捕获标准输出。我一直没搞清楚为什么不行。

我们发现在所有情况下都有效的唯一解决方案是:http://csharptest.net/319/using-the-processrunner-class/index.html

我试图通过考虑Mark Byers, Rob, stevejay的回答，创建一个类来解决你使用异步流读取的问题。这样做，我意识到有一个与异步流程输出流读取相关的错误。

我在微软报告了这个漏洞:https://connect.microsoft.com/VisualStudio/feedback/details/3119134

简介:

You can't do that: process.BeginOutputReadLine(); process.Start(); You will receive System.InvalidOperationException : StandardOut has not been redirected or the process hasn't started yet. ============================================================================================================================ Then you have to start asynchronous output read after the process is started: process.Start(); process.BeginOutputReadLine(); Doing so, make a race condition because the output stream can receive data before you set it to asynchronous:

process.Start(); 
// Here the operating system could give the cpu to another thread.  
// For example, the newly created thread (Process) and it could start writing to the output
// immediately before next line would execute. 
// That create a race condition.
process.BeginOutputReadLine();

============================================================================================================================ Then some people could say that you just have to read the stream before you set it to asynchronous. But the same problem occurs. There will be a race condition between the synchronous read and set the stream into asynchronous mode. ============================================================================================================================ There is no way to acheive safe asynchronous read of an output stream of a process in the actual way "Process" and "ProcessStartInfo" has been designed.

对于您的情况，您最好使用其他用户建议的异步读取。但是您应该意识到，由于竞态条件，您可能会错过一些信息。

在我的情况下，我有一个错误，所以我只是徒劳地等待一个正常的输出。

我改变了顺序:

string result = process.StandardOutput.ReadToEnd();
string error = process.StandardError.ReadToEnd();

:

string error = process.StandardError.ReadToEnd();

if (string.IsNullOrEmpty(error))
    string result = process.StandardOutput.ReadToEnd();