Process.WaitForExit() does not appear to wait indefinitely

  • Thread starter Thread starter psstone
  • Start date Start date
P

psstone

The documentation for Process.WaitForExit() indicates that it will wait
indefinitely for its associated process to exit. It appears that this call
will return after int.MaxValue milliseconds even though the process which it
references is still running.

This is hard to test because it requires waiting a bit less than 25 days to
reproduce the problem but I have observed it on 4 different systems running
both Vista and XPSP2.

Is this a know issue and if so, is there a hot fix available for it?
 
psstone said:
The documentation for Process.WaitForExit() indicates that it will wait
indefinitely for its associated process to exit. It appears that this call
will return after int.MaxValue milliseconds even though the process which it
references is still running.
This is correct. Process.WaitForExit() is implemented as waiting for
precisely 2 147 483 647 milliseconds.

This appears to be a design error, because the documentation for the
..WaitForExit(int milliseconds) method states:

"The amount of time, in milliseconds, to wait for the associated process to
exit. The maximum is the largest possible value of a 32-bit integer, which
represents infinity to the operating system."

This is plainly false. An infinite timeout is represented to the operating
system with the value -1, the bit pattern of which happens to be the largest
possible value of an *unsigned* 32-bit integer.
This is hard to test because it requires waiting a bit less than 25 days to
reproduce the problem but I have observed it on 4 different systems running
both Vista and XPSP2.

Is this a know issue and if so, is there a hot fix available for it?

Not that I know of. However, it's easy enough to circumvent by calling
Process.WaitForExit(Timeout.Infinite) instead. This *should* wait forever.

However, because Process.WaitForExit expects 0x7ffffff to be used as the
magic "infinity" value, there is a small problem if you have redirected I/O
for the process, because (unlike normally) the wait will return before I/O
on the streams has finished. This means the wait may return with the streams
in an invalid state, which may cause unexpected exceptions and/or loss of
data. If you haven't redirected I/O, this is not a problem.
 
Back
Top