I ran into this problem today and it took me quite a while to figure it out. I was starting a process from within IIS, redirecting it's standard output and error output so when the process exited I'd be able to generate a log with it. Everything was running fine on my machine, but not so well after I published it.
The process was supposed to work for just a while and then exit, however it just wouldn't. It'd simply stop responding, holding resources like sockets. After quite a while, I was able to identify the cause of the problem: the log generated was too big. After commenting Console.WriteLine
from the running process, everything worked just fine.
Just for clarifying how I started the process:
Process process = new Process();
process.StartInfo.FileName = path;
process.StartInfo.Arguments = arguments;
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardError = true;
process.EnableRaisingEvents = true;
process.Exited += Process_Exited;
process.Start();
And how I handled it's exit:
private static void Process_Exited(object sender, EventArgs e)
{
Process process = (Process)sender;
File.WriteAllText(path, process.StandardOutput.ReadToEnd() +
"\r\nEXCEPTIONS\r\n" + process.StandardError.ReadToEnd());
}
Even though I already know how to fix it, I'd still like to know what really happened and why, since there must be a way for me to create a log as big as I'd like.
The documentation for RedirectStandardOutput describes not one, but two possible deadlock scenarios (how's that for a useful and non-dangerous class library?!)
One occurs when both StandardOutput and StandardError are both redirected, and when the stream being read is full. This seems to perfectly describe your situation.
A pretty annoying situation, but read the full documentation and they describe how to avoid it occurring.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With