I have a lot of users reporting that they get the "msvcp100.dll is missing" error.
Instead of having users keep reporting this and reply that they need to install the C++ redistributable I would like to change the error text into something more meaningful, e.g. tell them that they need to install C++ redist.
Is this possible?
If you don't want to force users to install the redistributable, you can statically link to the runtime. Go to your Project Settings and find C/C++ >> Code Generation. Change the runtime library setting to multithreaded (/MT) instead of multithreaded dll (/MTd).
I am not sure if it is possible to change the error message. I highly doubt this because it is an error of the loader of the OS.
So why don't you create an installer for your application that will do the checking and if necessary the installation of the redist package?
You can also include in your application's release version the dll's that your application are needed
Related
I have a simple application which reads a few text files does some calculations and writes a few text files. Works perfect on my development machine (Server2008R2 VC++ 2010). I can't get it to run on a Win7 machine even thought I have installed/run the vs2010 redistribute x86.
The first error I got was missing mfc100ud.dll (yes, I'm using debug, if I try the release it just crashes, as debug tells you what's wrong). I put mfc100ud.dll in the application's directory, now fgets asserts as shown below. str is not null and the file did open successfully.
What have I missed?
My goal here is to just run the MFC app on the Win7 machine without have to install vs2010.
Another consideration, the only reason I am using MFC is for the COleTimeDate functionality. I've looked for alternatives but haven' found anything workable or as simple to use.
Thanks.
Assertion Error
This error occures if the file stream pointer (provided by fopen) is NULL.
Is it possible that you don't have any error checking after you used fopen?
Basically use "static linking" to the MFC and CRT. Than there is no Need to install and copy any runtime files.
Redistributable assemblies are only available for release builds. If you really want to distribute a debug build, you have two options:
link your app statically, so you don't need any shared DLL (such as mfc100ud.dll)
distribute together with your app (in your app folder) all the dependent DLLs. you can check the dependencies with depends.exe
Is it possible that I need to install both a vcredist for vs2012 AND for vs2010?
I just had an error where my app couldn't load a .dll and it suddenly started working after I did an unrelated installation, which prompted me to guess that it must have installed an older vcredist which fixed the issue.
However I'm sure I'm using c++11 features.
Deployment is a job on its own. And I hate it, I hate the way you have to write installations on Windows. …So that feel better now…
You only need one vcredist. The one the linker decided to link your program to. If you have the "Windows SDK's" installed you will find the actual redist in:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\vcredist_x86
If you install all updates including the not important ones, Microsoft will update your redist in that folder!
Maybe you have an executable, which do not want to run, you need the dependency walker. A tool, so usefully that Microsoft had to remove it from the Visual Studio. Download the program and open your exe in it. You do not need to understand what really happen. As long as no Dialog comes up during opening, everything is okay, even if there are exclamation marks in the bottom window. If a Dialog comes up with something like "Could not resolve" than look in the bottom window. Usually there is now in the lower window something like
"msvcr.dll" or "msvcr100.dll" or "msvcr110.dll".
If it includes an "d" before the extension like "msvcr100d.dll" the executable was compiled in debug mode and your journey ends on a system without installed compiler. If not, the name is telling you which vcredist you need:
msvcr100 = VS 2010 redist (32bit) (64bit)
msvcr110 = VS 2012 redist (32/64bit?)
sometimes it is not msvcr but it always starts with "ms". Of course the program will tell you every dll which is missing, not only microsofts and which command in the dll is used. This is sometimes extremely useful.
You have to do that with every dll in the folder of your executable as they can also have unresolveable dependencies.
Back to your first question. Your program can only link to msvcr100 or msvcr110, not to both, that is the reason you only need one vcredist per executable.
As mentioned in a commentary, A third party DLL can be guilty of using a different msvcp version. So yeah, you have to search all DLL's you use and you have to install both vcredist some times.
PS: There are always at least two of them, msvcr and msvcp.
I solved this problem as follows (on Windows 7):
I tried to load the library and it failed showing "The application failed to start because its side by side information is incorrect."
I opened "Computer management" window: Start -> right click on Computer->Manage.
In the "Computer management" window I selected "Event Viewer"->"Windows logs"->"Application".
The log corresponding to the error said that a DLL for a certain version of Microsoft.VC90.CRT was not found. In my case the version was 9.0.30729.6161 and the search for it in Google revealed I needed to install an "unusual" version of redistributables from here.
The dependency walker did not help for me (it only confused me by reporting unnecessary dependencies).
If you want to know which runtimes are needed, you can try using the "Dependencies" tool from lucasg on github (https://github.com/lucasg/Dependencies) which works on modern systems like win10.
You'll just have to look for MsVcR##.dll o VcRuntime###.dll (where # stands for a digit) in the dependency tree..
HTH
PS: The old-and-faithful "dependency walker" we've been using for years seems to be unable to handle the way newer OS handle delayed dependencies, marking them as "missing", while they are not missing, just delay loaded in a way it doesn't know...
If your OS is Vista or later (not XP), use the built-in SxStrace.exe to generate a log of which DLL's are being loaded and what module requires them. It will clearly show you if multiple CRT DLL versions are being loaded, and for what DLL's (3rd party or no).
The VS2012 redistributable is put into, e.g. "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\redist".
-- David
I am working on application which should be running on any Windows NT machine. Today I was trying to deploy my application on new machine and suddenly get error that msvcp100.dll is missing. I've started digging into that problem and found solution. Only what I had to do is in project configurations change Run time library From /MDto Multi-threaded (/MT).
But after switching to current mode I am getting link error. Not sure why and how to fix it. Could you please help me to figure that out? Thanks!
You aren't supposed to deploy debug builds. Compile with Release settings (including release version of the run-time library) and you won't have that problem. (You can enable debug information on a release build... it's use of the debug libraries that causes problems)
The error comes from that when compiling in debug mode, you'll need to change your project to link with link with debug libraries, ie msvcmrtd.lib instead of msvcmrt.lib and msvcrtd.lib instead of msvcrt.lib
Deploying debug binaries to other machines may/will cause runtime problems though since the debug version sof the DLLs aren't (afaik) redistributable, what you probably want to do is to fix your release build.
I've created a DLL file using VC++ 2008 with following settings:
Configuration type: Dynamic Library (.dll)
Use of MFC: Use Standard Windows Libraries
Use of ATL: Not using ATL
Common Language Runtime support: Common Language Runtime support (/clr)
The created DLL is working perfectly on my machine (the machine it's created on) but it can't be used on another machine (I tested with 3 machines). For more details, I load this DLL file via JNI (Java Native Interface). On my machine it works, but on others it showing the error of "java.lang.UnsatisfiedLinkError:: The application failed to start because its side-by-side configuration is incorrect...."
My question is:
1. Did I miss any configuration when creating the DLL that can't be worked on multiple environment?
2. Can we created a DLL file that will work on different machines?
Thank you so much!
You need to make sure that the VC++ 2008 Redistributables have been installed on the other machines. To double check this is the problem run Dependency Walker on the other machine and it'll show you what it's looking for:
http://www.dependencywalker.com/
You can find the VC 2008 redist EXE on the microsoft web site:
http://www.microsoft.com/en-us/download/details.aspx?id=29
or the actual DLLs are in the redist folder in the VC 2008 install folder.
Actually you can google for "side-by-side configuration is incorrect" and you will find a lot of hints what the reason could be.
But ... giv this a try first:
In VS, project settings, C/C++, Code Generation: Set "Runtime Library" to "Multi-threaded" (or "Multi-threaded Debug".
(Btw: Do you need Common Language Runtime support?)
Besides what #snowdude says, which is correct, there is another possible problem: if these other PCs don't have VS2008 installed, and you linked to the debug MSVCR* libraries, you're out of luck. Only Release mode binaries can be deployed to user systems without hoop-jumping.
I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.
What is required to run programs compiled with MSVC 9?
Can I just include some dlls for it to work everywhere?
Either link statially against the runtime library (select multithreaded instead of multithreaded-dll) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying.
You could be missing the MCVC9 runtime library, try copying that over to the Windows System32 folder...
It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.
What does your program contains? Dependencies on dynamic C/C++ runtime? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.
One easy step is to check with Dependency Walker what dependencies your application has.
It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.
If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.
If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter
drwtsn32 -i
to install Dr Watson as the post mortem debugger, and
drwtsn32
to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).