Hi all, I have been experiencing problems with weird crashes on Windows using libpion (http://www.pion.org/projects/pion-network-library) and the problem is still there with pion 1.0.10 but it changed a little and might shed some new light on the Let me just outline the situation. I have a simple project with an app and two libs, both using boost 1.36 at this time. The app links against those two libs, and one of the libs links against pion. So does the app of course. I've built pion as debug dll with boost 1.36. This runs on Windows and Linux. Now on Linux everything is fine, no problem at all, no dangerous valgrind output, nothing. On Windows however, the application crashes as soon as I do something with pion, and the callstack leads me to believe it's got something to do with boost asio. Usually it happens within asio win_mutex and looks a lot like this: http://trac.atomiclabs.com/ticket/32 To me this looks like an uninitialized mutex is being used. Not entirely however. I get this: First-chance exception at 0x7c91100b in myapp.exe: 0xC0000005: Access violation reading location 0x00000028. it's in win_mutex.hpp int do_lock() { #if defined(__MINGW32__) // Not sure if MinGW supports structured exception handling, so for now // we'll just call the Windows API and hope. ::EnterCriticalSection(&crit_section_); return 0; #else __try { -> ::EnterCriticalSection(&crit_section_); // CRASH } __except(GetExceptionCode() == STATUS_INVALID_HANDLE || GetExceptionCode() == STATUS_NO_MEMORY ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) { if (GetExceptionCode() == STATUS_NO_MEMORY) return ERROR_OUTOFMEMORY; return ERROR_INVALID_HANDLE; } return 0; #endif } This exception repeats many times until eventually the app crashes because 'this' is invalid, pointing somewhere it shouldn't. The Bug occurs several seconds after the application has started, but I don't have to actually access pion's http socket for that. I think it might not be pion's fault at all. The whole thing only happens on Windows and renders both pion useless on that system. I know, it's only Windows but I've been debugging around that for some months now and I'd really like that solved at some point. Any ideas? Thanks a lot... Stephan PS: I can't go to boost 1.37 because of: https://svn.boost.org/trac/boost/ticket/2541 With Chris apparently not responding or posting about ASIO any more is there any chance of this being fixed in the next release? Is ASIO maintained at all? Cause nobody seems to care about that bug. Again, I know it's only Windows but as long as Windows is officially a supported system an imporant lib like ASIO should work on it.