Background: I'm building a plugin for a large simulation framework. I'm compiling a DLL using Visual Studio C++ 2010.
After much bughunting and googling I believe I have a problem which stems from having multiple versions of CRT linked to my DLL. I'm getting a segfault in tidtable.c (from msvcr100.dll), in the function _CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue(). Reading this thread (there are multiple problems discussed, but towards the end this function is mentioned) is where I got the idea, and if I check the linking part of my project I see msvcr90.dll, ´msvcp100d.dllandmsvcr100d.dll`.
I'm using several external libraries, and I've been able to recompile all but one of them using VS2010. The last one is not open source however (it's a library belonging to the framework), and I guess that is where the dependency would come from. I'm not certain however, how could I check this?
Given that I'm right about where the dependency is coming from, what can I do?
You are linking to the release runtime from Visual Studio 2008 and debug runtime of Visual Studio 2010 ... you shouldn't mix and match release and debug in general. If you need the debug VC9 you'll need to install Visual Studio 2008 (install before 2010 to be safe)
However I'd probably just rebuild all projects and dependencies against VC10. You may be able to get away with installing the redist for VC9 if it's missing from your system for release only.
Edit: Link to Dependency Walker which is invaluable for determining missing or conflicting dependencies.
Related
I'm building a pure Win32 program (no clr or any assembly) by VC 2012 (VC 2012 (VC11) as my compiler). It uses boost 1.58, wxWidget 3.0.2 series,gsl 1.8, jsoncpp, Open CV 2.4.10, etc... The development box is running Win7 64bits. I would like it to be a single executable and is able to run on both Win 7 32/64 so I built all of the above packages as libs myself by the same VC 2012. (thanks for cmake)...
It works fine on development box but not on a clean one that only installed VC redistribution packages. I got the error message box ask me to use the sxstrace and the message in event log has side-by-side error like below and I also tried the sxstrace and got similar error.
"D:\Release\xxxx.exe" 的啟用內容產生失敗。 找不到依存組合 Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"。 請使用 sxstrace.exe 進行詳細的診斷。
I've been searching around. All and answers simply says I should use all release build for all libs. Yes, it's true if I didn't I couldn't have the single executable at first place. It won't be able to link. (I learned it by made lots of mistakes) I've tried both MD or MT build for my program (not mix them together. They are separated test.). Either of the mode works. The same error remains. I've also installed over lots of VC2008 9.0.21022, -.30729.17, -30729.4148, -30729.6161, VC 2010 10.0.40219, VC 2012 11.0.61030 (x86/x64)
I really don't understand. It's pure win32 release build made by VC 2012. How come it requires VC90 debug dll?
I'll really appreciated if someone can give me more precise advice about how to resolve or even determine where and what goes wrong with the code or the lib I build.
I will suggest that you use the following tool: Dependency walker.
By loading your executable on your PC (where it works) you should find out all the DLLs it uses and so discover any hidden dependencies in the (medium sized) library list on which your project depends (and in turn their dependencies).
This should help you point out DLLs that you have on your PC but not on freshly installed machines.
A pure Win32 release build should not depend on DEBUG CRT dlls, that's for sure. The only project setting to control that is basically that MT/MD ("Runtime Library") setting. You want MT.
I would guess that you have the Debug CRT dll referenced somewhere in the source code (e.g. one of the libraries requires it to be linked in for whatever reason, maybe because there is #define DEBUG or something, thus overriding project settings.
You could try searching #pragma comment(lib, ...bla-bla-bla...) in the source code.
It's resolved by myself. The project is about migrating a big legacy project. So there's a very small lib built by VC90 without source code. So be a detail person is the key to do this kind of job.
I uploaded my (VS2013) project folder and provided it to the other members of my team, but when they tried to build/run it, using Visual Studio 2012 they got this error, it also happened on their version of Visual Studio 2013.
The program can't start because MSVCR100D.dll is missing from your computer. Try reinstalling the
program to fix this problem.
They reinstalled VS2010 but no go.
I also tried to statically link my project by using /MT in the Code Generation options but now I get:
Unresolved External Symbol __free_dbg libcmptd.lib cout.obj
....25 more...
How can I get it so my project can be build/ran on my team members pc? How do I resolve the unresolved externals? It seems to happen purely with regular Microsoft files.
You are mixing C++ libraries built with different versions of the compiler (and as we know some of them are linked against debug dynamic version of VC10 runtime library). This is not supported, as different compiler versions have different ABIs.
To fix the mess you need to find libraries built with parameters that match parameters of your project. They should be built:
with the same compiler version (ex. VS 2013)
with the same configuration (Debug/Release)
against the same platform (x86/x64/ARM)
against the same runtime library variant (static/dynamic + debug/release)
You could either try to find prebuilt versions on the web or to build libraries yourself from source codes. Often, you will want to have multiple configuration/platforms for your project and, thus, you will need multiple versions of your libraries.
If your search will not succeed (for example if there is no VS2013 build for a closed source library) you could roll back your project to another version of compiler and to start over.
Any attempts to link incompatible libraries even if somehow succeeded will lead to random crashes.
This message generally states that the dll is referred to directly or indirectly in your application and is missing.
The 'D' at the end show us this is the Debug version of the file, this is DLL file is provided with the Visual Studio 2010 installation. So the MSVCR100D.dll would be provided with the installation of Visual Studio 2010.
Of course, you could be missing other versions 2008 (MSVCR90D) 2010 (MSVCR100D) 2012 (MSVCR110D) or the 2013 (MSVCR120D), each dll is provided according to the Visual Studio version.
There are a few ways to solve this:
Check to be sure that you're compiling all the components of your
project in Release mode. If this does not solve the issue continue
to the next steps.
You could solve this locally by installing Visual Studio 2010 on your
machine. This is not what I would recommend, but it would surely
overcome the issue
You could also download the file from this third party website and
copy it to your projects bin:
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
This option is the LEAST recommended option.
Run dependency Walker and see what file depends on the MSVCR100D.dll
and the try and fix that file in order to break your dependency. You can download depends here: http://www.dependencywalker.com/
Check to be sure that you're project is linking the correct version of
the CRT and any other libraries you may be using (e.g., MFC, ATL,
etc.)
Note: Installing the redistributables alone will NOT solve this problem, since the redistributables only contain the release version of the file MSVCR100.dll (notice no 'D')
Would it be possible that in your project you are somehow using some component/library built with Visual Studio 2010, which requires the MSVCR100D DLL?
My application when opened in others computer will give an error missing msvcr"something".dll, I found out that to fix this they need to install the following:
http://www.microsoft.com/en-us/download/details.aspx?id=40784
Which is Visual C++ Redistributable Packages for Visual Studio 2013.
I would like to compile the program with the dlls in the executable already, is such thing possible?
If not possible, where can I get all the dlls to put in the compiled project folder?
Try to set /MT for Release and /MTd for Debug in Project Settings->C/C++->Code Generation. This will make your program not dependent on Visual Studio libraries. But beware that all the libraries/ projects you will link with should also have the same option there, otherwise you'll get nasty linker errors.
You may also wish to select v120_xp in General->Platform Toolset for your program to be able to run on Windows XP
Because a lot of Programms use the functionality of these dll's they are dynamically linked.
So your filesize stays small and in case of fixes within the dll you dont have to recompile your program.
If you dont want this behaviour you can set in the projectsettings the dll's to "static linked" (/MT).
That way they will be compiled into your executable
Here is a relevant MSDN-article
Which is Visual C++ Redistributable Packages for Visual Studio 2013.
For Visual Studio 2013, you need:
http://www.microsoft.com/en-us/download/details.aspx?id=40784
If you were building with Visual Studio 2012, then you would need:
http://www.microsoft.com/en-us/download/details.aspx?id=30679
If you were building with Visual Studio 2012, then you would need:
http://www.microsoft.com/en-us/download/details.aspx?id=5555 (x86)
http://www.microsoft.com/en-us/download/details.aspx?id=14632 (x64)
The point is, you are probably going to need a runtime if you are writing portable C/C++ code by using functions like new, malloc, delete, free, etc.
You might be able to avoid the code if you use the Win32 API. For example, HeapAlloc and HeapFree, etc. Installers often use the Win32 API, and that's one of the reasons they usually don't need a runtime installed prior to running them.
I would like to compile the program with the DLLs in the executable already, is such thing possible?
Yes, its possible. Its called Static Linking (as opposed to Dynamic Linking).
But you will probably still need a runtime.
If not possible, where can I get all the DLLs to put in the compiled project folder?
Retired Ninja gave you this answer: Microsoft Visual Studio ~ C/C++ Runtime Library ~ Static/dynamic linking.
My application when opened in others computer will give an error missing msvcr "something".dll" ...
Another possible solution is to build your project with Visual Studio 2005 or Visual Studio 2008. The runtime used by VS2005 and VS2005 are usually available on Windows Vista, Windows 7, and Windows 8. So the computer may already have them.
But usually you just build your installer to carry around what you need. I use Inno Setup because it allows you to include both x86 and x64 components side-by-side. At install time, you just install the right components based on architecture (x86 vs x64), including the correct runtime. (At the time I choose Inno, Wix did not allow mixing architectures and I wanted a unified installer).
I am running Microsoft Visual Studio Express 2012 for Windows Desktop on a 64 bit machine with windows 8.
I create a completely new Win32 Console Application (in C++) and accept the default options. I then build and run the solution in both debug and release modes and it works all find and dandy. Next I configure the include and library directories for the dynamic SFML library. I link to the debug and release .lib files and put the debug and release .dll files in the proper directories. I then add some simple code which uses the library, build and run the application in debug mode and I get this error: "The program can't start because MSVCR100D.dll is missing from your computer. Try reinstalling the program to fix this problem." If I build and run the application in release mode it works with no errors. (And yes I have the redistributables installed 32 and 64 bit.) Now from what I understand and according to this thread that .dll file is for debugging only and is not included in the redistributable package (which would explain why it doesn't work in debug mode). The answer says that developers have it installed with visual studio by default. This is obviously not the case as evidence from the error and I've reinstalled visual studio and restarted my computer twice now.
In conclusion, how do I simply compile my solution in debug mode without getting this error?
I'm afraid someone will mark this as a duplicate so here we go:
LINK - "...you appear to be linking to the debug version of the runtime, it is not normal to distribute apps linked against the debug version of the runtime."
Doesn't pertain to me because I'm not distributing this app, just trying to run it in debug mode.
LINK - "I compiled my program using Microsoft visual c++ 2010 Express Edition and tried to run it on another machine that did not have the same compiler."
This person get's the error when he runs what hes compiled on a different computer, not when actually compiling the application.
LINK - "If you get this error for your release build..."
I dont.
LINK - "You can compile your project in "Release"..."
My project is not ready to be released therefore I should compile my project in debug mode.
MSVCR100D.dll is the dll for Visual Studio 10, so somewhere something is depending on it (the SFML dlls?). Whatever you compile (in debug mode) with Visual Studio 2012 will require MSVCR110D.dll, which you should have available on your machine as part of the installation.
I suggest you build SFML yourself on your own version of Visual Studio, it's pretty easy. In fact, the binaries available on the site as part of the SFML 2.0 RC are rather old and you'll do yourself a huge favor by building from the latest sources, as a lot of fixes and improvement were applied in the meantime.
(Also, definitely use 2.0 instead of 1.6. The site is rather misleading, but on the SFML forums virtually everyone will recommend you use the last version)
This message generally states that the dll is referred to directly or indirectly in your application and is missing.
The 'D' at the end show us this is the Debug version of the file, this is DLL file is provided with the Visual Studio 2010 installation. So the MSVCR100D.dll would be provided with the installation of Visual Studio 2010.
Of course, you could be missing other versions 2008 (MSVCR90D) 2010 (MSVCR100D) 2012 (MSVCR110D) or the 2013 (MSVCR120D), each dll is provided according to the Visual Studio version.
There are a few ways to solve this:
Check to be sure that you're compiling all the components of your
project in Release mode. If this does not solve the issue continue
to the next steps.
You could solve this locally by installing Visual Studio 2010 on your
machine. This is not what I would recommend, but it would surely
overcome the issue
You could also download the file from this third party website and
copy it to your projects bin:
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
This option is the LEAST recommended option.
Run dependency Walker and see what file depends on the MSVCR100D.dll
and the try and fix that file in order to break your dependency. You can download depends here: http://www.dependencywalker.com/
Check to be sure that you're project is linking the correct version of
the CRT and any other libraries you may be using (e.g., MFC, ATL,
etc.)
Note: Installing the redistributables alone will NOT solve this problem, since the redistributables only contain the release version of the file MSVCR100.dll (notice no 'D')
MSVCR100D is part of the 2010 Visual Studio package - indicating that some components of your system are compiled with the older version of Visual Studio, so you will need to install the Visual Studio 2010 version - you can probably still develop with the 2012 version, just as long as [parts of] the 2010 is on the machine.
Or you need to recompile some components that your application depends on to use the 2012 (msvcr110d) libraries - if you have all the source code, that would be my preferrred method.
My C(++) program, written and compiled using Visual C(++)/Visual Studio, runs fine on my own machine, but refuses to run on another machine. The error message I get is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If you write a C++ program, it links dynamically to the C Runtime Library, or CRT for short. This library contains your printf, your malloc, your strtok, etcetera. The library is contained in the file called MSVCR80.DLL. This file is not by default installed on a Windows system, hence the application cannot run.
The solution? Either install the DLL on the target machine through VCREDIST.EXE (the Visual C++ Redistributable Package), or link to the CRT statically (plug the actual code for the used functions straight into your EXE).
Distributing and installing VCREDIST along with a simple application is a pain in the arse, so I went for the second option: static linking. It's really easy: go to your project's properties, unfold C/C++, click Code Generation, and set the Runtime Library to one of the non-DLL options. That's all there is to it.
The problem here is a missing DLL dependency, such as the CRT (C Runtime Library). A good tool for diagnosing this sort of problem is Dependency Walker (depends.exe), which you can find here:
http://www.dependencywalker.com/
You would run this program on the computer that generates the error message you posted, and use it to open the exe that's generating this error. Dependency Walker will quickly and graphically indicate any DLLs that are required but not available on the machine.
Chances are high that you miss the runtime libraries of Visual Studio (CRT amongst others), you can either get rid of those dependencies (link statically) or install the VC redist packages on the target computer.
Depending on the Visual C++ version you use, you have to install different packages :
Visual C++ 2005
Visual C++ 2005 SP1
Visual C++ 2008
Warning : those packages only contain release versions of the libraries, if you want to be able to distribute debug builds of your application you'll have to take care of the required DLL yourself.
It is much the simplest to link to the runtime statically.
c++ -> Code Generation -> Runtime Library and select "multi-threaded /MT"
However, this does make your executable a couple hundred KByte larger. This might be a problem if you are installing a large number of small programs, since each will be burdened by its very own copy of the runtime. The answer is to create an installer.
New project -> "setup and deployment" -> "setup project"
Load the output from your application projects ( defined using the DLL version of the runtime ) into the installer project and build it. The dependency on the runtime DLL will be noticed, included in the installer package, and neatly and unobtrusively installed in the correct place on the target machine.
The correct VC Redist package for you is part of your Visual Studio installation. For VC 8, you can find it here:
\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
POSSIBLE SOLUTION........
EDIT: (removed most of my post)
Long story short, I was having similar problems, getting the "Application Configuration Incorrect" messages, etc etc.
Depends.exe was only finding ieshims.dll and wer.dll as possible issues, but this is not the problem.
I ended up using the Multithreaded (/mt) compile option.
What HAS worked though, as a workable solution, is making an installer with InstallShield.
I've selected several merge modules in installshield builder and this seems to have fixed my problem. The modules selected were:
VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT, and the CRT WinSXS MSM merge module.
I'm pretty sure its the WinSXS merge module that has fixed it.
DEBUG CRT: I noticed somewhere that (no matter how hard I tried, and obviously failed thus far), my Release version still depended on the DEBUG CRT. If this is still the case, the InstallShield merge module has now placed the DEBUG CRT folder in my WinSXS folder :) Being somewhat of a novice with VC++ I assume that this would normally be used to distribute debug versions of your programs to other people. To test if this is what fixed my problem I removed the DEBUG CRT folder from the WinSXS folder and the application still worked. (Unless something is still running in the background etc etc - I'm not that into it)
Anyway, this has got things working for me on an XP SP3 fully updated machine, and also on a VMWare XP SP3 machine with the bare bones (.net 3.5 and VC++ 2008 RTM basically) - and also on a mate's XP machine where it previously wasn't working.
So give these things a try, you might have some luck.
First thing you must use
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
or add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the preprocessor directives.
The problem is related to binding and the manifest types, you can find more http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/
By doing this your application will run with a larger range of runtime libraries versions.
Often times this error is the result of attempting to run the debug version of an application that uses .NET. Since the .NET redistributable package doesn't include the debug versions of the dlls that are installed with Visual Studio, your application will often get this error when running it on any other machine that doesn't have Visual Studio installed. If you haven't already, try building a release version of your application and see if that works.
Note also - that if you change to static runtime, you will have to do the same for MFC if your app uses MFC. Those settings are in properties->Configuration/General
I ran into this problem and was able to fix it very simply.
Visual studio gives you the option (on by default) to build a manifest for each build.
The manifest was put in the release folder, but it was a different release folder than the exe.
Even when using the setup utilities it was not packaged.
You should look for a file names something like myprogram.exe.indermediate.manifest
If this is in the same folder as the exe (and you have all the dlls) it should run