This msvcp100.dll is the Microsoft Visual C++ Redistributable dll that is needed for projects built with Visual Studio 2010. The dll letters spell this out.

MS = Microsoft V = Visual CP = C++ 100 = version

If you create a C++ project in Visual Studio 2010, this file is probably needed.

MSVCR100D.dll

The MSVCR100D.dll is almost the exact same file only the D at the end stands for Debug. This file has debugging enabled and is not considered redistributable.

Why the error?

Ok, so recently I switched to Visual Studio 2010. I had a C++ application that worked perfectly in Visual Studio 2008. Once I compiled it with Visual Studio 2010 and ran it on a clean 2008 server (fully patched but otherwise clean), it failed to run with the following error.

TestWin32.exe – System Error

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

Here is the screen shot:

The same things happens with the debug version of the file, only it is a the debug version of the same DLL as noted by the fact that the DLL name ends with D.

Autorun – System Error

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

The screen shot is identical except for the D in the dll name.

I create a new project in Visual Studio 2010 using the project type of C++ Win32 Project and without making a single change to the default project, I built the file and tested it on my clean machine and the same issue occurred.

So obviously that is not acceptable. It seems like this should just not happen by default, but unfortunately it does.

Solution

It was actually really easy to resolve for my one project.

Here is what I did.

You can solve this any of the following ways:

Statically link to the dll files so they are compiled into my executable instead of referenced as separate dll files.

Included the dll in the same directory as the exe (I actually didn’t try this but I assume it would work).

Forced everyone to install the VC++ Runtime Redistributable before running the app.

The first option seems the most stable and robust and easiest for a single executable. So that is the one I am going to use.

The second option doesn’t really make sense to me and I would probably never do it. Maybe if I had dozens of executable files that all required the same DLL and I didn’t have an installer, and I wanted to conserve size, which probably wouldn’t happen for me since I am pretty good at creating a quick installer. Though you might be in this a situation.

The third option would make sense if I was planning on running my executable after an install. During the install I could include the VC++ Runtime Redistributable and all would be fine.

Statically Linking the DLLs

Make sure you resolve it for both Release and Debug. The steps are slightly different.

Release

In Visual Studio, I went to the project Properties.

I changed my Configuration to Release.

I went under Configuration Properties | C/C++ | Code Generation

Look at the Runtime Library setting. It is set to this: Multi-threaded DLL (/MD) Change it to this: Multi-threaded (/MT)

Rebuild.

Debug

Almost exactly the same as release.

In Visual Studio, I went to the project Properties.

I changed my Configuration to Debug.

I went under Configuration Properties | C/C++ | Code Generation

Look at the Runtime Library setting. It is set to this: Multi-threaded Debug DLL (/MDd) Change it to this: Multi-threaded Debug (/MTd)

Rebuild the debug

It might be a good idea for me to figure out how to change the project so when I create a new project of this type, those settings are the default.

Install the VC++ Runtime Redistributable

Release

Download the appropriate version of VC++ Runtime Redistributable:

File Version

VC++ Runtime Version

MSVCR100.dll

Microsoft Visual C++ 2010 Redistributable Package (x86)

MSVCR110.dll

Microsoft Visual C++ 2012 Redistributable Package (x86)

MSVCR120.dll

Microsoft Visual C++ 2013 Redistributable Package (x86)

MSVCR140.dll

Microsoft Visual C++ 2015 Redistributable Package (x86)

Just google these and you will find the download links. Install the correct version and you are good to go.

Debug

If you are missing MSVCR100D.dll, then that is a debug dll and is not part of the free to download Visual C++ Redistributable package. So you pretty much are stuck with copying it from your dev box. Copy it to the C:\Windows\System32 directory. You need admin privileges to do this.

This is called "side-by-side deployment" and is intended for the case where you have need for a specific version of a DLL, but do not want to force the user to install the entire package that contains the one DLL you need.

Using this side-by-side deployment, different programs you deploy can have different versions of the same DLL without conflict.

Or, conversely, you can deploy different versions of the same program in different directories, and each version of your program gets the correct version of support DLL.

I new I needed to switch from DLLs to static linking but I believed the option to be found under the Linker node. Only after reading your article I realized the use of a run-tume linked DLL requires additional code such as calls to LoadLibrary(), GetProcAddress(), FreeLibrary().

This is a very lackluster and undeveloped feature of the game, and brings the multiplayer experience down a little. Sony will start sending emails out to all customers shortly with details on how to sign-up for the program. Nothing has been confirmed, and it appears that this service, if it is indeed in development, will not be available until at least 2013.

also I checked with dumpbin after adding the appropriate paths to the dlls and everything Microsoft loses 50 points for making this so difficult This is the third time I thought I had it working but didn't

The last thing I learned was to use dumpbin /dependents instead of dumpbim /depends

Hope this helps anyone else out there struggling with this odd problem

thanks for the solution.. but i still can't solve it. I use VC++2008 instead of 2010. I tried using the 3rd solution. But, after I install Visual C++ 2008 Redistributable Package (x86), the missing msvcp100.dll still occured. help plz..?

Thank you. But your suggestion of statical linking does not work. In VS 2010, I selected /MT for Code Generation in 64 bit release DLL and rebuilt. Size increased (from 32K to 93K). But Dependency Walker still shows MSVCR100.DLL as used. Currently, did not find a way to link without this DLL.

So, had to search another ways. Force Redistributable setup - problems to detect whether already installed, a lot of GUIDs for different versions. And I have also VM which have msvcr100 without Redistributable installed. So, my current solution in Setup - try to load msvcr100.dll. If fails, redistribute it in Program Files.

Just having to figure out where C/C++ node is in VS2010 was troublesome. I had to add a dummy cpp file (and then I deleted it) to view the node in the configuration properties (whereas my project already include cpp files...).

Yes, you either have to increase size by including the vcredist installer, or add the dlls to your own installer, or static link. They all increase size just in different ways. There is no way to avoid increased size in one way or the other.

I was able to get past the error using several methods above, static link, moving the .dll in with the package, etc. Now I get a "The application was unable to start correctly (0xc000007b)" error.

Honestly Microsoft, just kill off the .dll nonsense already. Its a nightmare, it causes way more problems than it was ever designed to solve, and nobody (but nobody) needs to save memory the way dlls were designed to do.

So the follow up is that installing visual studio on the target machine fixed the issue. This solution really stinks, but it is good enough for right now. Note that both the machine used to generate the application and the target (which is one foot away) are both running windows 7 64 bit. None of the other solutions worked.

For those who get the same "unable to start correctly" error, it probably means that you copied the wrong .dll . For 64-bit applications, you have to copy the dll from "C:\Windows\SysWOW64" instead of "C:\Windows\System32". Also, note that sometimes you need more than "msvcr100d.dll", the next error could be for "msvcp100d.dll", and that means that you got the first file ("msvcr100d.dll") right.

Had this same issue. Apparently I "did it right", because then I got the msvcp100d.dll error. Installed only Windows 64 Redistributable before, went through and installed the x86 Redistributable, and it all works good now.

I get this error.... but don't have Visual Studio.... The only thing I can think of is that a co-worker sent me a presentation video recently and I've been receiving this message ever since.... Thoughts on how to fix it?

Oh my gosh, I wish I found you 3 weeks ago.... What a small and stupid setting change that worked! You are the man, thank you so much. Also, I really appreciate the walk through too often people assume that you will know exactly what buttons to click. I wish everyone on the internet could answer questions this easily. As a side note, I will never understand why Microsoft assumes that just because I know how to write a program that I will know every single compiler setting to get the program ready for release.

Hi, I think you forgot about the issue Scharl mentiones. The problem is that if you are using extra static libraries, they have to be compiled with the same 'Runtime Library setting' as your program, where you want to use them. Otherwise an error like Scharl's will appear. You should update this information in your post. Well written otherwise, maybe a download link for the right .dll would be helpful for some. You can look here: http://stackoverflow.com/questions/3162325/after-building-exe-using-vs-2010-c-missing-msvcp100-dll to see how the issue can be solved.

I also get this problem, I have been trying to statically link msvcr100d into my program but I get the message "Command line error D8016: '/clr' and '/MTd' command-line options are incompatible" and can't use No common language runtime support.

Ahm... What`s the effect if my msvcr100.dll is remove from my system32??? Will my computer be broken or something??? Will my computer be slow??? what if I edited it for example I replace my original msvcr100.dll that has a size of 752b to 732b or vice versa...

My other blogs

Entries (RSS) and Comments (RSS). Copyright ® Rhyous.com Linking to content on this site is allowed without permission and as many as ten lines of any article can be used along with such link. Any other use of the content is allowed only by permission of Rhyous.com.