You can certainly pass STL objects across DLL boundaries but all involved dlls/exes must be compiled using the same compiler and the same compilation options.

Remember that most of the STL code is inline. This means that every dll will get its own version of the code and that code assumes a particular binary layout of the STL objects. If you compile 2 dlls with different compilation options then it is possible that the binary layout is different so the assumption breaks.

In addition to this, if one dll is debug and one dll is release it means they're using different CRT dlls, msvcrxx.dll and msvcrxxD.dll. That itself is a problem, at a minimum this means that each dll will use a different memory allocator and pointers allocated in one dll can't be freed in another.

Your best bet is to not share things like STL objects and other things which allocate memory across DLL boundaries.  Things like HAS_ITERATOR_DEBUGGING and SECURE_SCL will cause you grief, but other more subtle things can cause huge headaches as well.

For one thing, there is a good chance that you have multiple copies of the C runtime each with a different heap, so allocating in one heap and freeing to another will cause corruption.

Once you have gone to the effort of making all thing things match that will need to match to make it possible to share stuff like STL objects you might as well have just started using static libraries in many cases.

the only supported DLL boundary that STL object can be shared between is your DLL and C++ runtime DLL. Doing otherwise will cause a lot of pain at some point. Do not do it.