I wanted to ask on the mailing list about an issue I'm having with Boost.Asio on Windows 7 before making a bug report. System information: Windows 7 64-bit Professional running on an Intel quad-core i7 with 4 GB of RAM, using Visual Studio 2012 for C++ development. Used VS2012 compiler to compile Boost 1.55 libraries by following instructions found in the documentation online. In case it matters, here are the C++ preprocessor defines I'm using: WIN32;_DEBUG;_CRT_SECURE_NO_WARNINGS;NOMINMAX;WIN32_LEAN_AND_MEAN; _WIN32_WINNT=0x0601; The project was compiled with the default debug settings for Visual Studio 2012, meaning no optimizations. The problem: While using Boost.Asio to communicate with a serial device (an Arduino, 250000 baud, 8n1), sometimes async_read_until would pass to the handler both a bytes_transferred of zero and an error condition indicating success. According to http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/ async_read_until/overload1.html, this should never occur (if I'm interpreting the documentation correctly). Specifically, under parameters, under handler: // The number of bytes in the streambuf's get // area up to and including the delimiter. // 0 if an error occurred. The odd thing about this problem is that it is not easily reproducible... I think it may be a race condition. The files I'm attaching include the wrapper class I made to access the serial port in Windows, with a small main function at the bottom of the implementation .cpp file. I almost couldn't reproduce the error with this setup-- it took me a few dozen runs to get it to manifest itself. I can guarantee that the problem does not lie with the Arduino or the UART communication-- I have been running USBPcap to make sure that USB communication is taking place. I can see all data travelling to and from the Arduino by analyzing the USBPcap output through Wireshark. The Arduino I have has a set of ASCII serial commands it supports. The only one I use in the included code is "?\r", which makes it return "ACK\r\nArduino\r\n". Based on my searching, the closest bugs to what I'm experiencing seem to be these ones: https://svn.boost.org/trac/boost/ticket/8933 https://svn.boost.org/trac/boost/ticket/8967 I considered disabling IOCP for testing, but serial port communication depends on IOCP in Windows. The original problem is far more reliably reproduced-- using Visual Studio's unit testing framework, I am running essentially the same code included in the main function of the included code. I'd say about one of every three or two runs results in the error using the unit testing framework. Running the code in the actual application I'm developing also reliably reproduces the problem (MFC application). The attached .zip file includes the stripped down version of the project used to reproduce the problem, the stack frame of the error as caught by the assert inside readUntilComplete, and a core dump with the heap for the stripped project when the error occurred. The debugging symbols for the core dump are also included in the top-most directory of the .zip file. I would greatly appreciate any input/suggestions on the issue. If people are having trouble reproducing the problem, I seemingly can occasionally reproduce it so I can do more analysis, if someone were to point me in the right direction. Thank you for your time! Sincerely, Gabriel E. Marcano