Well, overlapped (=async) IO was what ultimately overwrote stack memory. The hazard pattern I recognized from previous experience. Of course exception in the q

Well, overlapped (=async) IO was what ultimately overwrote stack memory. The hazard pattern I recognized from previous experience. Of course exception in the queued APC was the reason why select's WFSO was prematurely interrupted and stack rewound, so the bug was of course there. It's pretty dangerous to execute code in the context of a waiting thread. While the solution to fix it by using heap allocation is a bit ugly in some sense, if your choices are to abort execution completely or to infrequently leak some bytes of memory, I know I'd choose to leak and perhaps log what just happened. There are rare cases when the I/O never completes and CancelIo doesn't complete either. Probably hardware faults or kernel driver bugs. Stuff that should absolutely never happen, but can still be defensively programmed around.