Robert – Thanks for your comments! 1) It was a typo – I got input archives and output archives backwards when describing the problem in my original email. I was actually using the as you describe. 2) There were several inline constructors in some derived classes not used by serialization. I removed them. 3) The archives were being closed but not the streams. Now both output archive and output stream are closed before the input stream and archive are created. 4) I also set up all the serialization code using NVPs so I could debug using XML archives based on a comment I saw in another post of yours from 6/15/10. That really makes it a lot easier to understand what’s happening! 5) I rebuilt Boost with the ODR code enabled. Results: I saw no ODR problems with the compile (by the time I did a full compile, I’d done steps 1-4). I saw none of the link warnings when rebuilding the DLL. I’m having much better success with the DLL now. It works almost completely. I’m now only having an RTTI issue that I’m working to resolve. I may post separately about that if my next few tests don’t identify the problem. PS –I’ve gotten pretty familiar with some parts the serialization code as I’ve stepped through it with the debugger. Very cool! It’s a real education on template meta-programming. Thanks for making this available and for doing such a great job with it both in terms of functionality and the artistry of the implementation. --- Steve H. On Thursday, May 22, 2014 10:56:26 AM UTC-7, Hickman, Steve (AdvTech) wrote: I’m using Boost.Serialization on a 64 bit Win7 machine using VS 2012. I have instances from a class hierarchy that I’m serializing through a base class pointer. I’m building a 32 bit debug console application. I’m serializing to an input text archive then extracting the stringstream and deserializing via an output text archive. Hmm looks like a typo. I would expect to serialize to an output text archive and de-serialize from an input_text archive. The stream used for the output text archive could be any output stream including string stream and the stream used for text_input would likely be a mirror image of the original output archive. In this case I would expect this to be a string stream. <snip> I’ve checked the following things: <snip> 2) The serialize code is in the .cpp files (not headers) along with the instantiations for the archive I use so I don’t have multiple instantiations of the serialize methods Hmmm - quadriple check this. are there inline functions in the derived classes? <snip> 4) The output archive is closed before I open the input archive, so there shouldn’t be characters missing at the end of the stringstream. is the stream closed as well? <snip> I believe that this might be due to a violation of ODR. This is explained in lines 58-71 of the file basic_serializer_map.cpp . This code traps such violations but is commented out as too many users complained that it inhibited their programs from running. Try uncommenting this code, re-building the serialization library, and then rebuilding and re-running your DLL. Robert Ramey <snip> Example link warnings when building the DLL: 1>RawUIEvent.obj : warning LNK4217: locally defined symbol ??$serialize@Vbinary_iarchive@archive@boost@@@RawEvent@Input@@IAEXAAVbinary_iarchive@archive@boost@@I@Z (protected: void __thiscall Input::RawEvent::serialize<class boost::archive::binary_iarchive>(class boost::archive::binary_iarchive &,unsigned int)) imported in function "public: static void __cdecl boost::serialization::access::serialize(class boost::archive::binary_iarchive &,class Input::RawEvent &,unsigned int)" (??$serialize@Vbinary_iarchive@archive@boost@@VRawEvent@Input@@@access@serialization@boost@@SAXAAVbinary_iarchive@archive@2@AAVRawEvent@Input@@I@Z) This above is a red flag.