In porting a project from iOS to Windows 8, I'm continuing to use Boost 1.49 to save the state of the program. I'm having what seems to be problems with a compiler bug. I'm wondering if anyone has found a workaround? Thought it's probably not necessary, I'll explain exactly what I'm seeing in detail in case it's helpful. If one creates a new Visual Studio project from the C++ Metro style Direct3D application template, simply adding these lines to the main function works just fine: std::stringstream memStream(std::ios_base::binary | std::ios_base::in | std::ios_base::out); boost::archive::binary_oarchive oa(memStream); However, when I add the rest of the project files (even if I don't instantiate any of the classes - just adding the modules does it), the two same lines in the main function crash. I eliminated all the code from the modules that refer to serialization and archive classes, because I noticed that there was a lot of static initialization of singletons of templated archive classes. Even with minimal static initializers, still, the code fails to run. Closest thing I can tell is that the compiler is not correctly translating the this pointer when moving from a class's initializers into a superclasse's constructor when multiple inheritance is involved (and perhaps lots of templating is required too). To be specific, in one specific run of the application (note that I've removed the template parameters for brevity): Inside binary_oarchive_impl ctor, the this pointer is: 0x0091fcb8 moving into its superclass constructor, basic_binary_oprimitive, the this pointer is: 0x0091fcc1 That would suggest that the superclass is 9 bytes into the derived class, however: back inside the binary_oarchive_impl ctor, using the debugger: (boost::archive::basic_binary_oprimitive*)this : 0x0091fcc4 offsetof(basic_binary_oprimitive, m_sb) = 0 (offsets retrieved by inspecting/altering memory, since you can't get the offset of a reference type) offsetof(binary_oarchive_impl, m_sb) = 12 Which clearly indicates that the superclass is 12 bytes into the derived class. In the superclass, it initializes m_sb - which is a reference to the stream buffer the archive writes to. Stepping back out of the superclass constructor, back into the derived class constructor, m_sb points to the wrong memory, of course. Has anyone else experience this with C++/CX? Is there an existing bug report? We've got a Microsoft contact that's helping us iron out issues. Does anyone know a concise repro that'll help MS solve this problem faster? Thanks for any information.