Identifying process completion
-
I've started a process that runs a command line executable and takes several seconds to return. I've attached/enabled events (OutputDataReceived and ErrorDataReceived) to enable the returning of STDOUT and STDERR messages from the process as they appear. All works fine, and all events return the lines of text as they should for stdout and stderr as they appear. But I've noticed that the OutputDataReceived and ErrorDataReceived events continue to be fired and return output *even after* the process.Exited() event has fired. I would have thought that the process had not yet completed until the last of Error and Output events have been caught/raised, but perhaps there is some kind of buffering going on within the Process that I am unaware of. If this is so, how can I know when the Process has *truly* completed-- as in the OUT and ERR data have fired for the last time *and* the process has truly exited? Ideally I would not read the contents of the OUT and ERR until the process is truly completed, therefore telling me that there is no output to follow the Exited() event.
-
I've started a process that runs a command line executable and takes several seconds to return. I've attached/enabled events (OutputDataReceived and ErrorDataReceived) to enable the returning of STDOUT and STDERR messages from the process as they appear. All works fine, and all events return the lines of text as they should for stdout and stderr as they appear. But I've noticed that the OutputDataReceived and ErrorDataReceived events continue to be fired and return output *even after* the process.Exited() event has fired. I would have thought that the process had not yet completed until the last of Error and Output events have been caught/raised, but perhaps there is some kind of buffering going on within the Process that I am unaware of. If this is so, how can I know when the Process has *truly* completed-- as in the OUT and ERR data have fired for the last time *and* the process has truly exited? Ideally I would not read the contents of the OUT and ERR until the process is truly completed, therefore telling me that there is no output to follow the Exited() event.
Your observations of redirected output continuing after the Exited event has fired is accurate. The Microsoft examples are misleading but buried somewhere in the documentation is the information you need, which is that the redirected streams send
DataReceivedEventArgs.Data == nullwhen they close. Process.Exited on it's own isn't much use when outputs are redirected and for all practical purposes it's best to wait until all redirected streams have sent null before declaring the process complete. Alan. -
Your observations of redirected output continuing after the Exited event has fired is accurate. The Microsoft examples are misleading but buried somewhere in the documentation is the information you need, which is that the redirected streams send
DataReceivedEventArgs.Data == nullwhen they close. Process.Exited on it's own isn't much use when outputs are redirected and for all practical purposes it's best to wait until all redirected streams have sent null before declaring the process complete. Alan.Thanks for the response, Alan. A quick check confirms what you stated--that the OutputDataReceived and ErrorDataReceived are raised with a Nothing value for e.data as the last call after returning their respective data. Since this call happens only once (for each Received event) and *only* after the data is completed, I can set a local flag within the process for each Received event when that happens. Between the two flags and the process.hasexited() property I can raise a custom event along the lines of: If Process.HasExited() and OutputDataReceived_IsCompleted and ErrorDataReceived_IsCompleted then Raise Event Process_HasTrulyCompleted() EndIf This seems to be the only guaranteed manner of knowing that all the conditions are met.