System.Diagnostics.Process.Start weird behaviour

Question

I'm writing an application to start and monitor other applications in C#. I'm using the System.Diagnostics.Process class to start applications and then monitor the applications using the Process.Responding property to poll the state of the application every 100 milisecs. I use Process.CloseMainWindow to stop the application or Process.Kill to kill it if it's not responding.

I've noticed a weird behaviour where sometimes the process object gets into a state where the responding property always returns true even when the underlying process hangs in a loop and where it doesn't respond to CloseMainWindow.

One way to reproduce it is to poll the Responding property right after starting the process instance. So for example

_process.Start();
bool responding = _process.Responding;

will reproduce the error state while

_process.Start();
Thread.Sleep(1000);
bool responding = _process.Responding;

will work. Reducing the sleep period to 500 will introduce the error state again.

Something in calling _process.Responding too fast after starting seems to prevent the object from getting the right windows message queue handler. I guess I need to wait for _process.Start to finish doing it's asynchronous work. Is there a better way to wait for this than calling Thread.Sleep ? I'm not too confident that the 1000 ms will always be enough.

Answer 1

Now, I need to check this out later, but I am sure there is a method that tells the thread to wait until it is ready for input. Are you monitoring GUI processes only?

Isn't Process.WaitForInputIdle of any help to you? Or am I missing the point? :)

Update

Following a chit-chat on Twitter (or tweet-tweet?) with Mendelt I thought I should update my answer so the community is fully aware..

• WaitForInputIdle will only work on applications that have a GUI.
• You specify the time to wait, and the method returns a bool if the process reaches an idle state within that time frame, you can obviously use this to loop if required, or handle as appropriate.

Hope that helps :)

Answer 2

I think it may be better to enhance the check for _process.Responding so that you only try to stop/kill the process if the Responding property returns false for more than 5 seconds (for example).

I think you may find that quite often, applications may be "not responding" for a split second whilst they are doing more intensive processing.

I believe a more lenient approach will work better, allowing a process to be "not responding" for a short amount of time, only taking action if it is repeatedly "not responding" for several seconds (or however long you want).

Further note: The Microsoft documentation indicates that the Responding property specifically relates to the user interface, which is why a newly started process may not have it's UI responding immediately.