Ok, my last suggestion is to set num_threads=1 when constructing the io_service.
This worked for the first time I ran the tests... but the second time the problem resurfaced. What baffles me is that none of the other serial applications on my computer seem to be dropping bytes...
Just because it may have worked on an older ASIO means little.
I actually haven't tried any other version of ASIO with this code. It may or may not have worked before.
An boss of mine said "never use any serial API not used by HyperTerminal" and I think he was right.
I'm beginning to think this myself, and further, this could probably be generalized for a lot of more proprietary programming APIs... at least based on my limited experience thus far. Still, I am not sure the problem lies with the serial code alone. async_read_until's behavior does not conform to its documentation-- that is certainly a bug. This is from the Boost.Asio async_read_until docs: Parameters: ... void handler( // Result of operation. const boost::system::error_code& error, // The number of bytes in the streambuf's get // area up to and including the delimiter. // 0 if an error occurred. std::size_t bytes_transferred ); If I'm interpreting this correctly, error and bytes_transferred cannot be errorless and 0, respectively. This is exactly the behavior I'm observing. The question is, I guess, what is causing this. Like you said, it could very well be a bug in Windows that is leaking through the Boost.Asio implementation of async_read_until. Regardless of whose fault it is, currently async_read_until does not conform to its documentation. I'll keep probing at it as work permits, but I'm unfamiliar with most of Windows's APIs so I have my doubts that I'll be able to trace the problem. Thanks for the help!