Process.Start is blocking/hanging randomly on some clients

Question

(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?

Answer 1

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.

Answer 2

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...