3

I made a simple application that uses the Windows Api to creates files and modify their permissions.

I used Visual Studio 2017 to compile and run this application, and it works perfectly fine on my computer. However, if a transfer this executable to a fresh Windows 10 x64 virtual machine, I get the following errors:

The code execution cannot proceed because VCRUNTIME140D.dll was not found. Reinstalling the program may fix this issue.

The same error pops up after clicking OK, except with MSVCP140D.dll, and then ucrtbased.dll.

When checking my installed programs, I noticed that I had the Microsoft Visual C++ 2017 Redistributable (x86) installed, while my VM only had the 2008 version installed. Could this be the reason the .dll's were missing? Would I have to install this redistributable in my executable?

Edit: Based off the answers provided, the issue is most likely that the respective redistributable is not installed. So I would like to slightly modify my question and ask, how would I go about verifying if this redistributable is installed, and if it ins't, install it myself.

Edit 2: The executable was built in release mode, not debug mode.

Edit 3: I have found the solution. VS was building my release executables with the Multithreaded DLL runtime library, instead of the normal Multithreaded runtime library. This setting may be changed in: Project properties > C/C++ > Code Generation > Runtime Library. For release configuration, select "Multithreaded", for debug configuration select "Multithreaded debug".

Michael Smith
  • 1,271
  • 1
  • 8
  • 31
  • The redistributable only includes the release DLL files, not the debug DLL files, so even if you installed it you still have a problem because you are trying to run a debug application. Note the D at the end of the name. – Retired Ninja Oct 22 '17 at 19:10
  • 2
    Duplicate is for older VS version, but the behavior is by design & does not change. Build the release executable. – MSalters Oct 22 '17 at 19:11
  • @MSalters I have built the release executable. I always used the release executable when testing on virtual machines. It was not a debug build of the executable. – Michael Smith Oct 22 '17 at 19:13
  • @MSalters Could you remove this duplicate flag as it is not a duplicate of the linked question? – Michael Smith Oct 22 '17 at 19:16
  • 2
    If it refers to `MSVCP140D.dll` at least *some* part of the executable is built in debug mode. – Bo Persson Oct 22 '17 at 19:31
  • @BoPersson I do not know what to tell you. I have built the project as a release. What else could I do? – Michael Smith Oct 22 '17 at 19:36
  • Theoretically the problem could be that you changed the "Release" settings in Visual Studio to link against the Debug DLL, but the more common problem is that yes, you are actually running a debug version, despite what you're expecting. You wouldn't be the first to copy a new executable to `Program Files` while the shortcut points to `Program Files (x86)`, for instance. – MSalters Oct 22 '17 at 19:40
  • You have to check any libraries you link to. One of them might still be in debug mode. If everything is compiled in release mode, it will not refer to any `*D` dlls. – Bo Persson Oct 22 '17 at 19:41
  • Save yourself the hassle and just *statically* link to the runtime. Your program will no longer depend on any C++ runtime DLL and will just run on any Windows machine without the need to install redistributables. Open your project's properties > C/C++ > Code Generation > Runtime Library. For release configuration, select "Multithreaded", for debug configuration select "Multithreaded debug". That's it. – zett42 Oct 22 '17 at 19:43
  • @MSalters Here are the logs of the release build: https://pastebin.com/CHwQ0vuD. I used the executable generated inside the respective file. I have triple checked this, and I even forced a full rebuild. I am 100% positive that I am testing the release build. – Michael Smith Oct 22 '17 at 19:45
  • @zett42 Thank you very much, this has solved my problem. – Michael Smith Oct 22 '17 at 19:48
  • @MichaelSmith: The standard tool for DLL problems is Dependency Walker. It will show you _why_ Windows is loading `MSVCP140D.dll`. – MSalters Oct 22 '17 at 19:52
  • @MSalters Proof this is not a duplicate, as zett42's suggestion has solved my issue. Please remove this incorrect tag. – Michael Smith Oct 22 '17 at 19:53
  • @MichaelSmith: Obviously static linking removes the dependency on _any_ DLL, whether release or debug. And it would have been an "answer" for the original issue as well (static linking goes back at least to VC1.5, 25 years ago). – MSalters Oct 22 '17 at 20:04
  • @MSalters: The standard tool for DLL problems *used* to be Dependency Walker. Unfortunately, it hasn't been updated in years, and completely missed [The Great C Runtime (CRT) refactoring](https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/). Today, the standard tool is to enable loader snaps, using [GFlags](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags) (`gflags /i +sls`). – IInspectable Oct 23 '17 at 08:47

0 Answers0