Erik,

Ensure that the DLL and the EXE are both built with the same version
of VS and that they both use the DLL version of the 'C' run-time
library - that way they'll use a common native heap. Also - don't mix
debug/release modules.

Dave

(sorry for top-post, OE yet again fails to quote)
native types, such as std::vector, are never instantiated on the managed
heap.

When you say that Cell is a POD type, I assume it is declared as a native
struct in both the application and the DLL?

I have a native DLL which is called from a managed application. One of
the calls to the DLL returns  a std::vector<Cell> (by value) where
Cell is a POD type, everything works fine until the function making
the call to the DLL returns, at which point I get a
CrtIsValidHeapPointer assertion failure.

As I understand things this is because the Cell-objects in the
std::vector are allocated on the DLL's heap but when the function
returns in the managed application (and the automatic variable goes
out of scope) and the std::vector's destructor is called it is
"working" on the managed heap.

Is there a way to solve this without having to rewrite the DLL, I
would prefer not to return a pointer to the std::vector<Cell> since it
(currently) is created on the fly from a much larger, internal,
structure.

--
Erik Wikström

This is a bit late, since you don't want to change the dll. But for what
it's worth, the other suggestions in this thread about matching runtimes
will work but I consider them risky and too easy to break with future
development.

My own approach is that whenever a dll has to allocate memory it gets
passed in an allocator function that allocates in the caller heap. I
will frequently use CoGetMalloc for this.

This way, no matter how the run times shake our, you still have
consistant allocation.

   ++PLS