The basic problem with IPC::Open3, is that if the output buffer on either of the output handles of the slave process, fills, the slave process will block pending the master reading some data from its end of that pipe so that the buffer is no longer full.

But if the controlling process is currently in a blocking read on the other pipe waiting for input, the slave process won't produce any more output to that pipe, until the other pipe has been read; which it never will.

On *nix, the programmer using IPC:Open3 can set the two pipe handles non-blocking and use select to only read from pipes when they have something ready to be read.

But Windows implementation of pipes does not support non-blocking pipes (it provides equivalent but incompatible, functionality through NamedPipeRead())

Hence, IPC::Open3 (and most of the attempted substitutes) are always unreliable on Windows.

The simplest potential work around I am aware of would be to extend Win32::Socketpair to include a winopen3() function in addition to the winopen2() and winopen2_5() functions it already contains. That module (originally by salva) dups the pipe handles to socket handles, which can be set non-blocking and used with select.