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
[download]

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.