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::operator<<(const
nw::Manager::ManagerNode & t={...}) Line 78 + 0x4a C++
NwNetworkD.dll!nw::Manager::save(const
std::basic_string &
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
