How bad is it to mix and match Visual C++ runtime DLL files in one process?

Question

I have an application that is built with Visual Studio 2012, and thus it depends on MSVCP110.DLL and MSVCR110.DLL. I'm using another DLL file, which seems to have been built with Visual Studio 2010 and depends on MSVCP100.DLL and MSVCR100.DLL. Yet another DLL I have was build with Visual Studio 2008 and depends on MSVCR90.DLL.

Is this a bad thing? A really bad thing? Should I be worried? The reason I ask is that the runtime heap allocator is complaining about heap corruption. Could this be related to the mixed runtime versions?

Answer 1

It's not safe to mix and match Visual Studio runtimes from different compiler versions mainly because each runtime will create its own independent heap. Since the heaps will be totally independent you can not allocate memory using 1 heap and free it in a different heap. Doing so will corrupt your heaps. The corruption does not usually cause an immediate crash since the corrupt part of the heap may not be accessed on the next few allocations or deallocations so it can be very hard to debug.

For the case of a single dll having a different heap than the application it is possible to work around the problem in a very limited way. You would have to isolate the dll such that all allocations and deallocations of dll happens only inside of the dll. And also isolation would have to go the other way as well. The dll will not be able to safely free memory from the applicaton without isolation.

More info on heap corruption caused by mixing CRT versions can be found here: http://siomsystems.com/mixing-visual-studio-versions/

Edit (April 1, 2020): The answer above predates Visual Studio 2015. Visual Studio 2015 through 2019 are binary compatible with each other but not compatible with any previous version.

The following link discusses the binary compatibility between these versions: https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2019