My guess is that the DLL is getting unloaded "too soon". You might put a break point in the unload code of the DLL and see if that trips before the assertion. There have been problems with code explictly unloaded while the type is still "in use" in a non-obvious way.

Robert Ramey

From there, something goes horribly wrong. What is ffffffff()? It seems

I'm really at a loss as to why this is happening. Here's the call stack: NwNetworkD.dll!_onexit(int (void)* func=0x0012fa94) Line 81 + 0x2e C ffffffff() boost_serialization-vc71-mt-gd-1_33_1.dll!0032aa2e() NwNetworkD.dll!boost::archive::detail::interface_oarchive<boost::archive::te xt_oarchive>::operator<<<nw::Manager::ManagerNode const >(const nw::Manager::ManagerNode & t={...}) Line 78 + 0x4a C++ NwNetworkD.dll!nw::Manager::save(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & filename={...}) Line 236 C++ After calling my method "save", it walks a map and serializes my ManagerNode classes. As you can see from the call stack, it then enters a function in the serialization DLL. like a bad pointer is getting dereferenced or something. Then the very next action is NwNetworkD.dll!_onexit(). I can tell you that our code is NOT unloading that DLL. At the current time, our code is single threaded and the DLL in question is not actually dynamically loaded/unloaded ever. It's statically loaded by the runtime on application start (we just link against the .lib for that DLL). Scott