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?

Cigarette

To rule out AV, create the process with sysinternals filemon running and see if anything is poking about with the new processes executable – Thursby

How do you kill the Thread? Why do you kill the Thread? Do you check for errors in Bgw.Completed? – Weald

@Alex If the program is restarted it runs like normal again. So it is hard to reproduce, which means filemon would probably run just fine. – Cigarette

@Henk. The killing of the thread is just a workaround so the app continues running as it should. The program invoked with Process.Start() has run and done its stuff. Still, the .Net code is hanging there which it should not. So I kill the thread with an Abort. I do not kill the BG thread. I have moved the Process.Start out into a new method which creates a thread and kills it if no return. Process.Start is blocking the thread. There are no errors raised. – Cigarette

@Alex. I used filemon and then procmon. I can not see anything accessing the program before it runs, but I do not know if procmon would notice system hooks on misc calls on the underlying DLLs. – Cigarette

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.

Laicize

Probably has to be this. The workaround for me was just to run the Process.Start in its own thread, then kill the thread if it never returns. – Cigarette

With UseShellExecute=false I get an "Access is denied" exception. With it =true, I get the problem of the call never returning. So I'm damned if I do and damned if I don't. Any more ideas? – Kutzenco

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

Garlen

The external program is a 3d party program that makes sure only 1 instance is run. That is, whenever the program is invoked with arguments it is sent to the allready running instance of the program and exits itself. It is not a console program so there should be no output(?). I do not know what kind of communication is used doing the one-instance-running-check. The Process.Start is run alone and not simultaneously with another call. To be more precise. A call to the same program is done with a .WaitForExit + Sleep(500ms) on the GUI thread before this one is called in the BG thread. – Cigarette