MSVCP110D.dll and Visual Studio 2013

Question

I am trying to run a program I compiled in Visual Studio 2013. However, I get the error

The program can't start because MSVCP110D.dll is missing from
your computer. Try reinstalling the program to fix this problem.

This is not a very helpful error. However, after some Googling, I found that it is (apparently) trying to load a standard c++ library dynamically, and that to get around this I need to specify the /MT option rather than the /MD option. This leaves me with a number of questions:

1. What exactly is that doing?
2. What are the benefits of /MD as opposed to /MT? I mean, there must be a reason that it is the default options...
3. How would I go about getting the looked for .dll and getting Visual Studio to use it? I downloaded this, but honestly don't know exactly how to use it.
4. Most importantly, how to I get that error to go away and my program to run?

Some additional info: I am compiling in Release mode using an x64 build.

Answer 1

The problem is that you are mixing different versions of Visual Studio by using Qt that was compiled using a different compiler. Remember that each version of Visual Studio will have its own runtime/CRT. The Qt dlls that were compiled with Visual Studio 2012 and will be dependent on the Visual Studio 2012 runtime. They will not use the 2013 runtime.

The solution to this problem is to recompile all of your code and dependent libraries/dlls with the same compiler.

Warning: Some users will try to just install the dynamic runtime (or recompile dependent libraries with static CRT) from the other version of Visual Studio however this is not a solution to this problem mainly because each runtime has its own independent heap. Having separate heaps can and will lead to random crashes caused by allocating memory in one heap and then trying to free it in a different heap. Since the heaps do not share information about allocations or deallocations this leads to having corrupt heaps. From my experience the problem does not always cause an instant crash. The crash may or may not happen on the next allocation of the corrupt heap so debugging this situation can be very frustrating.