I think you hit a bug in Win32::API.
2013-06-27 Win32::API v0.76_02 bulk88
..........
- Fixed, Win32::API::More::Import created Win32::API objs,
not Win32::API::More
upgrade to 0.76_02 or newer (Win32::API::More objects do automatic packing and unpacking of pointers to numbers, Win32::API objects require you to call pack and unpack yourself to convert the string/buffer filled with C-style binary numbers to Perl numbers)
or convert the
Win32::API::More->Import( to
Win32::API->Import(, then pad out
$bAvail with
$bAvail = "\x00" x 4;, then after PeekNamedPipe, if successful, do
unpack('L', $bAvail). Previous sentence is a summary of
Win32::API.
What happened was, because there isn't automatic packing
my $bAvail = 0; was stringfied to "0", which is 1 byte long. The C function PeekNamedPipe wrote 4 bytes to $bAvail, even though $bAvail had only 1 byte space. An anti-memory corruption detector in Win32::API caught the mistake.