We have encountered a problem during deserialization via boost::archive::text_iarchive. It is somehow related to the gcc (4.4.1 via MinGW) Windows implementation of the std::stream, that is the parameter of the constructor of text_iarchive. The exact same code caused no problems on a Linux machine (with gcc 4.4.1 as well). The setup is a multi-threaded application (that causes the issue) with frequent deserializations on different threads. The problem is in short: 1: MessagePtr msg; // the structure to be deserialized below 2: std::istringstream archive_stream(buffer); // buffer contains the data, it is a simple char[] array 3: boost::archive::text_iarchive archive(archive_stream, 0); //constructor of the text_iarchive for deserialize 4: archive >> msg; // the deserialization The line causing the problem is the second and third one: in the MinGW implementation of istringstream handling there seems to be some static variables working in the background, and without proper protection of these lines, eventually the application is terminated improperly. Important, that the buffer above is thread-binded, thus it is surely not modified in the background. Using global boost::mutex-es solve the problem: boost::mutex istringstream_locker; //global , local mutexes doesn't work as the behaviour is bound to the std::stream implementation (...) istringstream_locker.lock(); std::istringstream archive_stream(buffer); boost::archive::text_iarchive archive(archive_stream, 0); istringstream_locker.unlock(); (...) However this being a frequently used code, we are wondering if there is any better (more time effective) solution or workaround. (Note: we tried using the boost/format/alt_sstream, but we couldn't get it to work.) Or maybe we can substitute text_iarchive with something else that doesnt require an std::stream? Thanks for reading this!