Release Application looking for MSVCR110d.dll

Question

I've built a c++ application with Visual Studio 2012. I've tried to get it to run on another machine without VS2012 installed but it will not run. It keeps looking for msvcr110d.dll (not msvcr110.dll), I have built the application in release mode, and I have my runtime library set for multi-threaded dll (/MD) (although I have tried all of the options with no avail). I have no idea why this isn't running. The target machine does have the redistributable installed. Any suggestions?

Answer 1

The d.dll suffix means debug version of C++ runtime DLL. This means your exe is debug build, which requires MSVCR110d.dll.

You should deploy release build of your exe, which requires MSVCR110.dll.

Ask the user to install VC2012 runtime redistributable, MSVCR110.dll will be installed.

Answer 2

The problem is most likely that freeglut is a debug library, not a release library, and is therefore trying to link against the debug-mode DLL. There probably exists a release-mode version of freeglut as well, and you need to change your project configuration to use that freeglut library instead.

However, there's a deeper issue here: How can you check this for certain? What if there's another library causing the issue, or what if it's some obscure setting in your own executable file? I've found the tool Dependency Walker to be very helpful. Its page claims that it's included with Visual C++, but I couldn't find it in any of my Visual C++ installs (perhaps because I did not install all optional components). Note that the included help file didn't work for me either, but you can view the help file contents on the web page.

A view of freeglut.dll's dependencies. I've highlighted the particular C Runtime used by this version of FreeGLUT--yours is probably different. The list of functions on the right shows you what MSVCRT exports, and the highlighted ones are the ones that appear to be used. For example, it looks like this version of FreeGLUT uses operator new. If your names are mangled, hit F10 to undecorate the C++ names and see what the functions are. All the missing DLLs appear be "delay-loaded" DLLs (see the hourglass), so they are probably not an issue.

I've used Dependency Walker to figure out a number of nasty DLL issues. While it's perhaps overkill for your particular problem, I think it's nice to know what tools let you actually see the problem, instead of just inferring that it's there.