Sunday, December 30, 2007

Visual C++/Studio: Application configuration incorrect?

If you have just written a program in Microsoft Visual C++ or Visual Studio (2005 and above, I believe), try to run it on another machine, and get the error message “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.” then you want to read on. If you just want to see me rant at Microsoft, read on as well.

The problem is really simple. 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.

Now comes the rant part: how much effort it took me to figure all this out. You have been warned.

“This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.” What kind of error message is that? It's like saying “sorry, your car does not work, because the engine won't start; please buy a new car.”
In the very least, you could tell me that I'm missing a DLL. Preferably also tell me which particular DLL.

Reinstalling the application, like the error message suggested, did of course not fix my problem. But the message also does not give a hint where to go looking for the error. It took some web searching to figure that out: the Event Log. Itself hidden quite well inside Windows, it told me which particular DLL was missing on the system. The Dependency Walker, that also comes with Visual Studio, told me that MSVCR80.DLL was indeed the culprit.
The error message should at least point toward the more useful information: “See the Event Log for details.”

I searched around on the web for MSVCR80.DLL and found its purpose. It turned out to be possibly the most basic library any C programmer could wish for. So why the heck is it not installed on any Windows system? It turns out that some older versions of the CRT are installed with Windows, but these are really ancient and buggy, and I honestly wouldn't know how to make Visual Studio link against them.
So why, in these days of automatically updating systems and always-on internet connections, is this small (612 kB) but very essential DLL not included in service packs, or in Windows Update?

Now, to fix the problem, I had to install the DLL on the target system. Simply dropping it alongside my application didn't work, because nowadays DLLs actually need to be installed. This is because modern DLLs are what Microsoft calls Side-by-side (SxS) Assemblies, which have been introduced in a brave attempt to diminish DLL hell. I don't know the gory details; it's something to do with manifests, and probably lots of candles, pentagrams and holy water as well.
Anyway, you cannot download the VCREDIST installer straight from the Microsoft website, because there's only an old version there. Or is there? A newer page does give you what you want, and there's a 2008 version too.

Thinking that it must be possible to link statically to the C Runtime Library, I looked into the project options in Visual Studio. I could not find the option there. Not very surprising, considering its name: “Runtime Library.” What runtime library? The Grand Unified DLL of Making Coffee? Or is this just a general option relating to runtime libraries in general? The default value (“Multi-threaded DLL”) seems to suggest this. I dared not touch this option for fear of breaking my application. It's a common problem with Microsoft: they often use a very generic-sounding name for something very specific.
Had the thing been called “C Runtime Library linkage” instead, I would immediately have grasped its meaning.

On a not completely unrelated note, I'm pleased to announce that this bug in Taekwindow has finally been resolved.

My coworker is getting this same error message on his computer that doesn't have Visual Studio. Unfortunately, I have Visual Studio 2008, which doesn't seem to have a redistributable executable like VS 2005.

Instead all you get is a bunch of DLLs in C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86 and no instructions for using them.

You can still use depends.exe to find out which of these DLLs your program depends on, but guess what, depends.exe is no longer included in Visual Studio 2008!

So I found out with an old version of depends.exe. And when I got my coworker to put the proper .dlls and .manifest files in the same folder as my .exe, guess what happens when he runs the .exe? Nothing at all! No error message, no application window. Grr.

Seriously, this has been so frustrating. Thank you for your simple explanation. It even explained what some of the complicated articles I have been reading about this stuff were talking about more than the articles themselves did. Apparently Microsoft does not know how to write a document explaining things without using acronym after acronym, referencing complicated files, and massively long procedures. I could not understand how a program as advanced as Visual Studio 2008 professional couldn't compile a simple c++ program that would run on any other windows machine. I guess they only want computer scientists to purchase this software. Even their "limited" version of visual c++ express did not contain any better explanation.

Hello again. My co-worker lost interest in running my code, so it was a long time until I finally got a chance to run my program on a machine that didn't have Visual Studio installed. One of the awful things about this error message is that you don't get it unless you run it on a computer without VS installed, which for many developers means it's not their machine, which may mean it's inconvenient to go mucking around in their Event Log. In the worst case your "test user" might not be in the same place as you, so you have to rely on somebody else--a non-programmer--to try solving the problem on their computer. Ugh.

Anyway, it turns out there is a redistributable that works with Visual Studio 2008 called vcredist_x86.exe ...but by now I forgot how to get this file. If anybody needs it, well, I dunno, try searching MSDN's download center.

Thanks Thomas, this seems to be a "problem" recurrent in every new release of Visual Studio (I'm using VS 2008). Beside adjusting the Runtime library to /MT or /MTd, you also have to make sure that the option _AFXDLL gets removed from the C/C++->Preprocessor Definitions list.

I was searching for the solution approximately for 1 day but everywhere I was reading the possible solution, I got overwhelmed with so many foreign words and acronyms (especially at Microsoft pages). But this site was different.

This article was "soooooo" easy to understand, so that it took only 5 minutes to fix that problem.

So, finally IT WORKS for me.Once more "MANY THANKS" to the author of this article.

Wow. Who whould have know it would have been that simple? Thanks you so much for such an "easy-to-understand" article. After scratching my head at other awfully-written articles on the web for about an hour (thank goodness that it was not longer than that) this article saved me from a lot of hassles, broken programs, busted up computers, and other not-so-good reactions to my frustration. Thx.

I struggled with this one for days and spent a lot of time googling it. I stumbled here and WOW! Good, no, fantastic help at last. A lot of people and stuff on the Internet don't have a clue what they're talking about and leave you running around in circles. Thank you very much for this insightful, helpful and technically correct post.

I tried to solve the problem like described below:- link to the CRT statically in the project properties -> it doesn't work, i get a lot of errors when compiling!- second try: use VCREDIST.EXE -> I have the same problem as 'qwertie'... Nothing happens when starting the application!

You could try running depends.exe (Dependency Walker) over your DLL on the other computer, the one on which it doesn't work. This tool is a free download from http://www.dependencywalker.com/ and might also be included somewhere in your Visual Studio directory.

To the anonymous person getting errors about msvcprt.lib: this is the C++ runtime library, not the C runtime library. The errors you're getting probably means that it gets linked in twice: once in CoverageBox.obj, once from elsewhere. That confuses the linker because it can't decide which version to use (even though they're probably identical!). Check your settings to make sure that the C++ runtime library is only linked once for your final output file (EXE or DLL).

I'm very new to all this. I moved a program from one machine to another and have the same problem but only in debug mode and not release. and I tried the second option that you gave i.e., went to project properties ->C/C++ ->code Generation-> runtime library and every option gave me more errors than the Multi-thread DLL(/MD)option which gives me the: This application has failed .... I don't know what else to do. please tell me how to do your first option please. Also what does this mean and how do I do this:Check your settings to make sure that the C++ runtime library is only linked once for your final output file (EXE or DLL). Many many thanks

Hello,In John's message above he says that 2 steps are required. Does anyone know how to do the second step ? I have installed VCredist on target machine - No Joy. Should I see the Msvcr80 dll in teh windows/sys32 after I install ? Because it's not there.Also I get a /MT' and /clr command line options are incompatible when I change the Runtime to non-Dll ?

If you use /clr, you're building a managed assembly, which is a wholly different beast. If you link the CRT statically, you don't need to install VCredist, and vice versa. I would think John's second step is only necessary if your program uses MFC at all.

I changed my configuration from dynamically loading the C++ runtime to statically loading it (by changing the 'Runtime Library' to 'Multi-threaded'), but when i built my application i got a few linker errors. After googling a bit, I resolved them by editing the project properties as follows:

I found that the build fails (there's acheck on afxver_.h) if before changing Code Generation from /MD to /MT you don't state you're using MFC (if using MFC!) in a static library from project configuration properties-->General.

Hi..Thanxs a lot for the post. but still I changed my configuration from dynamically loading the C++ runtime to statically loading it (by changing the 'Runtime Library' to 'Multi-threaded'), but when i built my application i got a few linker errors. After googling a bit, I resolved them by editing the project properties as follows:

Linker -> Input -> Ignore specific library: MSVCRT.lib

I am getting this 6 errors after compliling the CPP code.

Warning 1warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library gg

Thanks a lot, your post saved the day.I work with Visual 2008 and changing to /MT gave me the _AFXDLL error.I changed it back, and it compiled fine, but did not run on other computers.Then I changed the Configuration Properties -> General -> Use of MFC from Shared DLL to Static Library, and that automatically changed the other option to /MT, and it worked fine on the other computer.(Ignoring MSVCRT.lib did not help.)

Bottom line, on Visual 2008, the only thing I had to manually change was Use of MFC from Shared DLL to Static Library and my application worked fine.Thanks again, DavidG.

Great article. It really worked for me. I was not able run my Java application which was using dll built using Visual Studio 2005. I struggled a lot for loading the DLL.Now I am relaxed. Keep up the good work.

Here is a drop of information that my be useful: I have a C++/CLI assembly with similar "side-by-side configuration is incorrect" error on non dev machines when compiling in debug mode. I dropped the "Debug" option from Multi-threaded DLL Runtime library. Still got the silly side-by-side error. Then, by chance, I changed the _DEBUG preprocessor definition to the release definition of NDEBUG (still in Debug configuration). And voila! - my problem was solved!

About Me

Me elsewhere

Taekwindow

Taekwindow is a small and light Windows program that I wrote. It enables you to move windows by Alt-dragging anywhere in their interior, and resizing by Alt-right-dragging, just like in many X window managers.