I don't know about MS, but in Borland a common source of DLL interface problems is not using a common (shared) memory manager.
Thanx Craig, that turned out to be the problem for VC++ as well.
Yep, but shared_ptr is supposed to work in this case, in theory. ;-) I'll look into this. Any more information that can help me find the problem?
It works if the destructor of the object being held in the shared_ptr or scoped_ptr is not implemented inline in the header file. If it *is* then destruction is called in the context of whoever is currently holding the smart pointer to it at the time - and if that is across a dll boundary from the creation site then *bang* (if you have mismatched runtime models). For example - this class would exhibit the problem (well, on VC++ at least): class Awkward { public: Awkward(){} ~Awkward(){} // because the implemention (although empty) is defined here we get a problem }; If you now hold a shared_ptr to an Awkward object that was created within a host process and pass it by shared_ptr into a sink function in a dll (ie a function that allows the shared_ptr to go out of scope when the ref count is 1, thus deleting the object), then it will try to delete it from the *host process' heap*. At least, that is my experience. The simple solution, of course, is to put the destructor implementation in the implementation (cpp) file. On VC++ (and probably others), not defining a destructor has the same effect as defining one in the header file. HTH, [)o IhIL..