Ok, this is interesting point... Make sure that all
DLLs you are using
are compiled correctly with Same MSVC runtime **DLL** (with correct import flags) and not mixed DLL/static library/
You were right about that cause of that crash: i had mixed Release and Debug DLLs (that is a problem in its own right as typically you aren't in control of other DLLs)
So I do not understand fixing correct runtime solved your problem or not?
So reproducing it wasn't too hard after all (once i realised the DLL thing). This code should crash quite reliably: http://www.doc.ic.ac.uk/~awl03/locale_test.zip
Turns out its not a COM problem but a general DLL problem <snip> < Basically what happens is that the DLL sets the global locale when it is loaded. Great. We work away doing stuff and everything is fine ...
Then at some point the DLL is unloaded. But the global locale is still pointing at an object whose definition was provided by the non-unloaded DLL. Disaster! The next time anything tries to use a locale (like a simple stream op) we crash with an access violation.
The problem here is setting a locale 'owned' by the DLL. Is there a way round this?
If anyone uses Boost.Locale with COM (or any other situation where DLLs are unloaded) they will run into this problem.
Many thanks.
This code reproduces the issue of crash when you set global locale and then you do not unload it, at least I see that you do not call std::locale::global(std::locale::classic()) . Am I right? If so.. this is your problem and not Boost.Locale one. It can be recreated even on Linux with shared objects, if you create global locale in dynamic library and unload the library you will crash when you would try to create an locale instance - clearly. .......... Does it crashes when you call on library unload: std::locale::global(std::locale::classic()); If so, are you 100% sure it is called? Have you triyed to just create a global object with constructor and destructor (without writing DllMain) -- because it is more portable? If you cleanup it with: std::locale::global(std::locale::classic()); So normal object is created instead of boost.locale Now there is interesting point. If DLL sets some object owned by dll when you set std::locale::classic() to global locale... Then blame standard library, because classic instance should point to standard library runtime and not DLL and this has nothing to do with Boost.Locale. If so you may try to set std::locale classic just after unloading library. If it does not help... You should not set global locale in loadable module or move to other platform where dynamically loaded libraries are not so brain-damaged. (no offense all Windows users :-) ) In any case: - It seems to be rather standard library issue then Boost.Locale one - Any DLL that would create its own facets and set global locale would have this issue. Artyom