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,
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(
, 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.