Capturing StandardOutput AND StandardError from a Process

I recently revived a program I had written to do an automated build and deploy of a solution containing a Visual Studio Database Edition project as well as a client UI in WPF. The build program runs a bunch of command-line programs, capturing all the output along the way and keeping track of errors, etc. When I was going through the code, I noticed a bug. I am using ProcessStartInfo and Process and I thought I was capturing both StandardOutput and StandardError but I wasn’t. My code looked like this:

      psi.UseShellExecute = false;
      psi.RedirectStandardOutput = true;
      psi.RedirectStandardError = true;
      Process p = Process.Start(psi);
      string output = p.StandardOutput.ReadToEnd();
      string error = p.StandardOutput.ReadToEnd();
      p.WaitForExit();

So I “fixed” the code so now it looked like this:

      ...
      string error = p.StandardError.ReadToEnd();
      ...

But when I ran it, one of the programs seemed to hang forever. I was able to determine that the program did in fact finish, and was actually my code that hung forever. It turns out that if you use ReadToEnd() on both StandardOutput and StandardError, you can reach a blocking situation that hangs your code. This is even documented on MSDN here:

“A deadlock condition results if the parent process calls p.StandardOutput.ReadToEnd followed by p.StandardError.ReadToEnd and the child process writes enough text to fill its error stream. The parent process would wait indefinitely for the child process to close its StandardOutput stream. The child process would wait indefinitely for the parent to read from the full StandardError stream.”

This is exactly what was happening in my code. I was up until 4am updating the Build program, and at this point I wanted a quick solution. The MSDN documentation hinted at the solution (asynchronous threads) but did not provide code outright. I did some searching on the Internet and found some solutions out there, but they were all much heavier than I wanted. I wanted something simple, preferably just a few lines of code and very modular, so after I couple hours of sleep and some coffee, I came up with a solution. First, I created a very simple class, which could be called from a new Thread, to capture the output of a stream:

  class MyStreamReader
  {
    StreamReader _sr = null;
    string _text = null;
    public string Text { get { return _text; } }

    public MyStreamReader(StreamReader sr)
    {
      _sr = sr;
    }

    public void Go()
    {
      _text = _sr.ReadToEnd();
    }
  }

Then I used that class to capture the standard error and standard output from my newly launched process, as follows:

      ProcessStartInfo psi = new ProcessStartInfo(commandToRun);
      psi.UseShellExecute = false;
      psi.RedirectStandardOutput = true;
      psi.RedirectStandardError = true;
      Process p = Process.Start(psi);

      // Create my objects to capture output asynchronously
      MyStreamReader msr_stdout = new MyStreamReader(p.StandardOutput);
      MyStreamReader msr_stderr = new MyStreamReader(p.StandardError);

      // Create the thread objects to run the code asynchronously
      Thread t_stdout = new Thread(msr_stdout.Go);
      Thread t_stderr = new Thread(msr_stderr.Go);

      // Launch both threads
      t_stdout.Start();
      t_stderr.Start();

      // Wait for both output and error streams to finish
      t_stdout.Join();
      t_stderr.Join();

      p.WaitForExit();

      // retrieve the output and error text
      string output = msr_stdout.Text;
      string error = msr_stderr.Text;

      Console.WriteLine(output);
      Console.WriteLine(error);

I tested out my new code now everything works properly – now I just need to thank the developer who checked in the post deployment scripts that caused the errors, otherwise I might not have caught this problem to begin with!