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.

  1. “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.
  2. 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.”
  3. 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?
  4. 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.
  5. 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.

59 comments:

Shubhangam said...

Thanks man.. this helped me a LOT

Anonymous said...

Thank you very much for your post. That dll was giving me such a head ache. At least now I can compile my programs without worries, or asking for someone with an older compiler.

Anonymous said...

Thank's alot, you saved me alot of work.

Anonymous said...

If only all articles on how to fix problems were written this simply.

Qwertie said...

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.

Thomas ten Cate said...

Dependency Walker (depends.exe) can be freely downloaded.

If you get nothing at all, there are two things that come to mind that you might try: look into the event log, and run the program from the command prompt to see whether it spits out any messages.

Anonymous said...

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.

In short, this explanation was amazing! Thanks!

Qwertie said...

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.

Qwertie said...

P.S. oh, that's funny, I don't remember seeing a link to the VS2008 CRT in this entry when I read it before. I guess you updated it... thanks.

Thomas ten Cate said...

I think the link has been there since I originally wrote this. Glad to be of assistance :)

Anonymous said...

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.

Laurent

Bhupesh said...

This is really good article for Microsoft to start with. They should learn from here how basic things affect overall quality of product. Thanks a lot for having such document on net.

Cheers!
Bhupesh Rawal

Anonymous said...

I will start with 4 words:
Thank you very much.

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.

Anonymous said...

Thanks for your sinple explanation. I was struggling with this for a while.

Anonymous said...

Thank you very much. you saved me alot of time and headache. Your support is sincerely appreciated.

Anonymous said...

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.

Anonymous said...

Thanks,
I went around in circles trying to debug this problem.

Anonymous said...

This is so good and incredible, I´ve read enough stuff in Internet trying to solve this problem and you just put it so damn simple. You should win a Nobel Price. Thank you

Anonymous said...

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.

Anonymous said...

I get exactly the same problem...
Only one thing: I use visual C++ 9.0

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!

Can anybody help me?

Thomas ten Cate said...

If you post your compile errors, I might be able to say something about your problem.

Anonymous said...

@thomas ten cate
thanks!
okay, i set the runtime library to 'multi-threaded(/MT) and set the preprocessor definitions to 'NOINHERIT'.
while compiling, I get 128 linking errors like the following:
1>Linking...
1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string char,struct std::char_traits char ,class std::allocator char ::basic_string char,struct std::char_traits char ,class std::allocator char(class std::basic_string char,struct std::char_traits char ,class std::allocator char const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in CoverageBox.obj

Unknown said...

Just to clarify further, the solution is composed of two things:

1) First, statically link CRT using /MT
2) Make sure to statically link MFC DLL also

If you only do #1, your program won't compile, spitting out some _AFXDLL stuff. To fix this compile error, please do #2.

Anonymous said...

So, probably i made a mistake...
But where in the visual studio properties i have to set, that MFC DLL is linked statically?!?

Anonymous said...

Hi, I was hoping to find the solution of my problem... but it is still there....

Here is what I have....

I am creating a DLL that I am loading through a java interface using JNI.
As everyone else on this post... my stuff works on my computer but the dll cannot be loaded on others computer.

I tried to execute the vcdist_x86.exe but it doesn't seem to fix anything. The msvcrt80.dll is on the other computers but am still getting the same error. They are not co-located though.

any help available?
thanks,

simon

Thomas ten Cate said...

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.

Thomas ten Cate said...

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).

Anonymous said...

Thank you so much!!!! You saved me!

Anonymous said...

Hi Thomas,

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

Andrew said...

hey, thanks for this blog, it has REALLY helped.

Anonymous said...

Im a beginner, you hve helped me. THX!

Anonymous said...

Thank you a lot.

Anonymous said...

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 ?

Thomas ten Cate said...

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.

Goblin Queen said...

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 hope this helps anyone who has had this problem before

Anonymous said...

dude...you are a life saver!!
:))
THanks!

Dan Dascalescu said...

Hey Thomas,

Some idiot has just reposted today your content without any attribution or acknowledgment at http://mihirknows.blogspot.com/2009/07/visual-cstudio-incorrect-application.html.

You might want to file a copyright complaint against him.

Thomas ten Cate said...

Thanks Dan, I'll contact him first.

Nanne said...

Dude! what a shithead...

David Wright said...

Thank you so much. This is exactly what I needed!!!
Very well written and explained!

Anonymous said...

I have a problem with a bot that post things about Buy Viagra on my blos

Thomas ten Cate said...

No idea why you are mentioning that here, but try using a captcha :)

Unknown said...

Very useful post - thanks!

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.

Unknown said...

This website is a life saver. Thank you very very much.

Anonymous said...

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

Error 2 error LNK2019: unresolved external symbol __CrtDbgReportW referenced in function "public: char const & __thiscall std::_String_const_iterator,class std::allocator >::operator*(void)const " (??D?$_String_const_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEABDXZ) libcpmtd.lib

Error 3 error LNK2001: unresolved external symbol __CrtDbgReportW libcpmtd.lib

Error 4 error LNK2019: unresolved external symbol __malloc_dbg referenced in function "void * __cdecl operator new(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z) libcpmtd.lib

Error 5 error LNK2019: unresolved external symbol __free_dbg referenced in function "void __cdecl operator delete(void *,struct std::_DebugHeapTag_t const &,char *,int)" (??3@YAXPAXABU_DebugHeapTag_t@std@@PADH@Z) libcpmtd.lib

Error 6 error LNK2019: unresolved external symbol __calloc_dbg referenced in function __Getctype libcpmtd.lib

Error 7 fatal error LNK1120: 4 unresolved externals C:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\gg\Debug\gg.exe 1

Anonymous said...

+ above i am using Vs2008

thanxs
Divya Mehta

Thomas ten Cate said...

Those look like debugging symbols that the linker cannot find. In debug mode, make sure you are linking with the *debug* version of the CRT.

DavidG said...

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.

Unknown said...

Thank you very much, you saved me a lot of time and work !!

Arjen den Hartog said...

Thanks a lot

Anonymous said...

Thanks a lot. After 30' of search I found this 'easy' solution... Migrating projects from a borland c++ 5.02 I dont want to use vcredist...

Anonymous said...

apart from good technical skills, you also have very good writing skills.....
in spite of its technical background, it a real fun to read this article

Sekar said...

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.

Anonymous said...

Just what I was looking for.

Thanks a mil,

John

Anonymous said...

Thanks great article saved my day

malus Diaz said...

Thank you!

Anonymous said...

i had similar problem that could'nt run any programs at all.
just do system restore to fix this.

Anonymous said...

thanks a lot now this is going to help me

Unknown said...

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!