You probably have a pipe or socket as a handle. There was no data in the buffer. Therefore you will block until data is written to the pipe/socket, or the other side handle is closed. Unless you provide the pure perl line we can't really help you (in the watch window look at my_perl->Icurcop on threaded perls, or PL_curcop (I think, I rarely use no-threads perl) to find out where you are pure-perl wise). Also your callstack is probably garbage due to a lack of symbol files. That looks like a VC callstack, when there are symbols, the c funtion prototypes and their values are shown, when there are no symbols you get a function name and 1 hex offset. Also, if the function is NOT exported, and you do not have symbols, the name on the function can be completely wrong. The "name" you see without symbols, follows this algorithm, take the instruction pointer, then look at the export table of the DLL, find the nearest previous function call instruction pointer wise, use its name, then write the offset to the instruction pointer. msvcr80 looks correct, so does kernel32 and ntdll. Those 3 used stripped symbols (semi-private). libperl is probably guessed. All 4 functions you showed are exported from perl51*.dll. Some of the msvcr80 functions are not exported, so there a symbol file took effect. All functions Perl_runops_standard will call, begin with Perl_pp_*. Perl_runops_standard will never call Perl_reentrant_size. Either a tailcall happened (symbols won't help you), or frame pointer omission (more likely this scenario, symbols for libperl.dll will help).