This application has failed to start because the application configuration is incorrect RRS feed

  • Question

  • Hi, I am just starting programming using Visual C++ 2005 Express Edition. I have had some limited practice in other languages and older versions of C++, so I have some idea whats going on but not much...

    Anyway I made a short program which perfroms a bubble sort on an array of numbers which the user enters (I know its nothing to write home about but its a start), it works fine on my PC and when I sent it to a freind who also had VC++ 2005 Express Edition it worked fine for him.

    However I then sent it to a freind without it (in a fairly poor attempt to persuade him to download it) , and my program didn't work on his PC giving the error: "This application has failed to start because the application configuration is incorrect". I was wondering if there was anything I could do to make it work on PC's without VC++ (and I think the .NET framework or something, that is with it), or if they have to have the above programs for it to work.

    Thanks in advance for any help.
    Sunday, August 14, 2005 12:34 AM


All replies

  • A first guess would be due to side by side (SxS) issues:

    Take a look at this link for more details on SxS and distributing applications:

    In addition, Nikola's blog has lots of info on SxS:

    Here is a related post that deals with a similar issue:

    Of course if you share out a code sample and a build log, I can probably dig out more details.

    Also, if your application is a managed one then you will need the .net framework on the machine running it.

      Ayman Shoukry
      VC++ Team.
    Sunday, August 14, 2005 6:24 AM
  • Thankyou for the advice, I will include the code below along with the build logs. I say logs as I was not sure whether I was supposed to build in debug mode or release mode so I did both, although they both work/don't work on the same computers. Also I didn't know whether my application is a managed one as I am not familiar with the concept.

    There is only one file in the project which is called sorter but is in a folder called hello, as a renamed it after I converted the code from a 'hello world' program. The file is sorter.cpp and is as below (although the original is indented though I doubt this makes a difference):

    // Simple Number Sorter with no Validation

    #include <iostream>

    #include <conio.h>

    using namespace std;

    int x, total,temp, flag;

    int arr1[100];

    void main()


    cout << "RAOUL PRODUCTIONS C++ NUMBER SORTER" << endl;

    cout << "Enter the quantity of numbers you wish to enter(maximum 100): ";

    cin >> total;

    for (x=1; x<=total; x++)

    cin >> arr1[x];


    cout << "Sorting..." << endl;




    for (x=1; x<total; x++)


    if (arr1[x]>arr1[x+1])









    cout << "Your numbers in order are: ";

    for (x=1; x<=total; x++)

    cout << arr1[x] << " ";

    cout << endl << "Press any key to exit...";



    The build log for the Debug version:
    Build started: Project: Sorter, Configuration: Debug|Win32

    Command lines:
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\RSP00002410283128.rsp" with contents
    /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /GS- /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c /Wp64 /ZI /TP ".\sorter.cpp"
    Creating command line "cl.exe @"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\RSP00002410283128.rsp" /nologo /errorReport:prompt"
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\RSP00002510283128.rsp" with contents
    /OUT:"Debug\Sorter.exe" /INCREMENTAL /MANIFEST /MANIFESTFILE:"Debug\Sorter.exe.intermediate.manifest" /DEBUG /PDB:"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\Sorter.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86  kernel32.lib


    Creating command line "link.exe @"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\RSP00002510283128.rsp" /NOLOGO /ERRORREPORT:PROMPT"
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\RSP00002610283128.rsp" with contents
    /out:".\Debug\Sorter.exe.embed.manifest" /notify_update /manifest

    Creating command line "mt.exe @"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\RSP00002610283128.rsp" /nologo"
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\BAT00002710283128.bat" with contents
    @echo Manifest resource last updated at %TIME% on %DATE% > ".\Debug\mt.dep"
    Creating command line """c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\BAT00002710283128.bat"""

    Output window:

    Embedding manifest...


    Build log was saved at "file://c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Debug\BuildLog.htm" Sorter - 0 error(s), 0 warning(s) 

    The build log for the Release version:
    Build started: Project: Sorter, Configuration: Release|Win32

    Command lines:
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\RSP00002C10283236.rsp" with contents
    /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /c /Wp64 /Zi /TP ".\sorter.cpp"
    Creating command line "cl.exe @"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\RSP00002C10283236.rsp" /nologo /errorReport:prompt"
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\RSP00002D10283236.rsp" with contents
    /OUT:"Release\Sorter.exe" /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:"Release\Sorter.exe.intermediate.manifest" /DEBUG /PDB:"c:\documents and settings\ashley\my documents\visual studio 2005\projects\hello\hello\release\Sorter.pdb" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /MACHINE:X86  kernel32.lib

    Creating command line "link.exe @"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\RSP00002D10283236.rsp" /NOLOGO /ERRORREPORT:PROMPT"
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\RSP00002E10283236.rsp" with contents
    /outputresource:".\release\Sorter.exe;#1" /manifest

    Creating command line "mt.exe @"c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\RSP00002E10283236.rsp" /nologo"
    Creating temporary file "c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\BAT00002F10283236.bat" with contents
    @echo Manifest resource last updated at %TIME% on %DATE% > ".\release\mt.dep"
    Creating command line """c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\BAT00002F10283236.bat"""

    Output Window:
    Embedding manifest...


    Build log was saved at "file://c:\Documents and Settings\Ashley\My Documents\Visual Studio 2005\Projects\hello\hello\Release\BuildLog.htm"
    Sorter - 0 error(s), 0 warning(s)

    Sorry about the excessive length (and poor formatting) of the post, I was not sure what you needed. Also it may be a stupid question but am I right to be sending just the exe file to other people or am I supposed to give them something with it?

    Sunday, August 14, 2005 9:01 PM
  • Below described steps are a workaround that only applies to VS2005 Beta2. This does not work with the final release of VS2005


    You need to copy CRT DLL into your application local folder together with the manifest. Please take a look on this post on my blog, http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx. Basically go to windows\winsxs folder. Find a folder like x86_Microsoft.VC80.CRT and copy DLL from there to your application local folder. From what I see in your code you need msvcrt80.dll and msvcp80.dll (perhaps msvcrt80d.dll and msvcp80d.dll if this is Debug mode application). Then go to windows\winsxs\manifests folder and copy x86_*_Microsoft.VC80.CRT*.manifest to Microsoft.VC80.CRT.manifest to your application local folder. Take a look on my blog, it has detailed instructions.


    Monday, August 15, 2005 6:03 PM
  • This error message is uselessly vague.  Is there a way to get the Visual Studio 2005 linker to tell you which DLLs you need to destribute?  and which manifest file?  It should copy these into the binary directory with the application and tell you about it.  With 2005 it has just gotten harder to build a program and copy it to another machine.  Why should it?

    Do I need to create a setup project?
    Wednesday, December 7, 2005 7:23 PM
  •  Gerry Rempel wrote:
    This error message is uselessly vague.  Is there a way to get the Visual Studio 2005 linker to tell you which DLLs you need to destribute?  and which manifest file?  It should copy these into the binary directory with the application and tell you about it.  With 2005 it has just gotten harder to build a program and copy it to another machine.  Why should it?

    Do I need to create a setup project?

    Actually I disagree with a statement that it became harder to understand what DLLs has to be redistributed. In VS2005 the manifest clearly describes dependencies of an application and as long as they are installed on another computer, the application works fine. Linker is not meant to do any magic and prepare an app for redistribution. The only reason for the linker to exist is to link final binary from object files and what it successfully does.

    Overall deployment of VC++ applications is described in http://msdn2.microsoft.com/en-us/library/zebw5zk9(en-US,VS.80).aspx. You may follow steps described in http://msdn2.microsoft.com/en-us/library/ms235265(en-US,VS.80).aspx in understanding all dependencies of an application. Steps for creating a setup project are described in http://msdn2.microsoft.com/en-us/library/ms235285(en-US,VS.80).aspx

    Wednesday, December 7, 2005 7:37 PM
  • I've found that what I need to do is create a setup project, and then copy the MSI file to the machine I want to run my application on, and then install it.  If I do this it installs: msvcm80, msvcp80, msvcr80 and odbc32.dlls, and x86_Microsoft.VC80.CRT.manifest as well as my application.

    I cannot find this manifest in my developement directories, I guess it lives in the Windows folders. 

    Prior to this upgrade, I could just copy an exe, and run it.

    BTW, what C++ compiler and link settings do I need to build for an AMD 64 bit Athon?  When I try it with Visual Studio it builds the objects, but won't link them.

    Wednesday, December 7, 2005 8:04 PM
  • A more useful response would be to link statically instead of with the DLL versions of the run-time libs.
    Thursday, December 8, 2005 4:46 PM
  •  troff wrote:
    A more useful response would be to link statically instead of with the DLL versions of the run-time libs.

    I am trying to do exactly this, but I'm still getting the (worthless) error message.  I have an MFC-based application, which also uses (as Linker Input) winmm.lib and opengl32.lib.  It also uses "#pragma comment" to include the following:


    This application also includes four of my own libraries.

    All four of my libraries, and the main app are built with Unicode, /MT, static MFC.

    All I want is a standalone executable... what am I doing wrong?  I even started over with a dialog-based static MFC application generated by the Application Wizard... this program worked fine (but did nothing) on whatever machine I copied it to... until I added my code and linked in the above MS libs and my own libs.

    Tuesday, December 13, 2005 1:15 AM
  • Something I noticed: Nikola's steps for installing applocal from August 15th no longer works for RTM.  For that purpose, the CRT manifest in c:\windows\winsxs\manifests has the wrong version number.  After copying it to your applocal subfolder (Microsoft.VC80.CRT) and renaming to Microsoft.VC80.CRT.manifest, instead of 8.0.50727.42 you need to put in 8.0.50608.0.  Leaving it at 8.0.50727.42 will cause the same application configuration error.

    This is especially important for VC Express users, as the \program files\microsoft visual studio 8\VC\redist\x86\Microsoft.VC80.CRT folder (which does all of the above for you) does not exist.
    Tuesday, December 13, 2005 4:04 AM
  • Hi, Ted. It seems strange that although the ver number in manifest becomes 8.0.50608.0 in RTM, but the ver of the corresponding dll is still 8.0.50727.42 (both in VC\redist\x86 & Windows\WinSXS).
    Tuesday, December 13, 2005 4:36 AM
  • vbvan, I agree it is strange, however they did do this so that any application that happened to be written for older versions of the CRT (e.g. beta 2) would automatically redirect to the RTM versions of the CRT (8.0.50727,42)

    Richard Grimes has written an article that explains it somewhat (although, his conclusions about it being a quality control issue, are, I believe incorrect, i.e. I believe they purposely kept it at 8.0.50608.0 for the reasons I mentioned):

    The article is here (please try to ignore the anti-Microsoft comments as it is still a good article overall)


    Tuesday, December 13, 2005 5:19 AM
  •  Schpidah wrote:
     troff wrote:
    A more useful response would be to link statically instead of with the DLL versions of the run-time libs.

    I am trying to do exactly this, but I'm still getting the (worthless) error message.  I have an MFC-based application, which also uses (as Linker Input) winmm.lib and opengl32.lib.  It also uses "#pragma comment" to include the following:

    Update.  I feel a little silly... it appears that my problem is due to use of OpenMP.  So, now I just need to figure out how to statically link OpenMP.
    Tuesday, December 13, 2005 12:35 PM
  • You can only link dynamically to OpenMP.


    Tuesday, January 3, 2006 11:12 PM
  • I was also stuck by this problem. I developped an app with VS 2005 Pro on WinXP SP2 but could not ran it on WinXP SP1, though i was using both 2 MSDN's deployment methods (). Finally, installing Windows Installer 3.1 (Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\WindowsInstaller3_1) helped me solve this problem.


    Wednesday, January 11, 2006 1:59 AM
  • Hi,

     I run accross this same problem when trying to run a simple application using the SDL library on another Windows XP machine than which I compiled the software on. I managed to resolve the problem thanks to a number of instructions here and on other sites.

     Now I am, however, curious to know is there a correct way to create software with Visual C++ 2005 Express Edition so that the software would actually run without the need to copy and rename directories and tweak manifest files?

     Browsing the web and VS help files there was a lot of mentioning about different deployment models and publishing wizard, but it seems these are not included with VS C++ 2005 Express Edition? Can somebody let me know how this deployment problem is meant to be solved?

     Dan Silfvast

    Sunday, January 15, 2006 2:55 PM
  • Until Microsoft releases a vcredist_x86.exe that's downloadable from the Microsoft site (and hopefully that has built-in support for Windows Installer 3.1 bootstrapper instead of having to install separately), officially there is only one way to install to WinSxS if you only have Visual C++ Express - that is, use the merge modules provided in \Program Files\Common Files\Merge Modules with your favorite setup program, Wix, etc.

    But as you say there are a myriad of other ways to get your app to run (either using or not using WinSxS), many of which I have written about in other posts. 


    Sunday, January 15, 2006 5:22 PM
  • I have spent a few hours on this topic today, and have not succeeded in the slightest.  I am trying to install an EXE in another office of the company, and have not succeeded.  Helps I have seen have not been helpful, requiring several complex steps and often refering to panels/panes that do not exist, though it might help if they had mentioned which EXECUTABLE the panels belong to....

    I stil have a nice, 10+ year old compiler from another manufacturer that gives me an EXE that just ships without surgery or the need to waste hours reading vague, incomplete, inaccurate help or shipping DLL's that are far bigger than the EXE itself.  Even shipping the DLL's has not helped: is there some extra 'security' in place?

    Does no one remember the term KISS?  Keep It Simple, Stupid....

    Tuesday, February 28, 2006 6:48 PM
  • Hi!

    I am also seeing this very unhelpful message!?!?!?!

    I have developed an application using Visual C++ Express.

    All I want to do is to run the application from the flash drive with neccessary DLLs. One executeable, the two runtime DLLs, msvcp80.dll & msvcr80.dll, and one third party DLL for demostration purspose and part of the research work that I do.

    I had a look around vary web-sites and it seems that I need to create a msi or msm, manifest or whatever the different deployments methods that are available. I am not interested in created an installation package or using any of the differnt deployments for this application. Also, I moving from computer to computer for the demostration and I don't want to be installation or copying or whatever onto these computers and then uninstalling it. I just want to be able to run it directly from the flash drive. I can get this application to work without any problems whatsoever on win2k from the flash drive. By the way. this is how I find out what runtime DLLs that I needed to have. On win2k it told me what are the missing DLLs etc. where on winXP it didn't even tell me that; hence, the error messages are getting worst. I don't even make any API calls to the registry or to INI file so the error message is completely wrong!!!! If it told me what the real problem is then I can fixed it.

    So how do I run it without all this headaches on winXP????

    As the last poster stated, why do we have this completely unneccessary complex method just to be able to run an application on a different computer??????????????????  Keep it simple .... !!!!

    Tuesday, March 7, 2006 4:23 AM
  • It's very, very easy, just create one file and copy the rest as described in this post (marked as answer) now known affectionately as the "due to popular demand" post:


    or, link statically (with /MT instead of /MD)

    Also, OShah has written an excellent article about the multitude of ways of installing and distributing the CRT, as well as some tools to help out.  I suggest you read this:


    Tuesday, March 7, 2006 6:21 PM
  • Thanks Ted!

    That fix the problem!  ;-)

    Wednesday, March 22, 2006 3:02 AM
  • I found that if I saved the files Microsoft.VC80.CRT.manifest and Microsoft.VC80.MFC.manifest into the executable's deployment directory, that solved the problem.

    These can be found in the Program Files/Visual Studio 8/VC (do a search on it).

    Hopes that helps,



    Wednesday, May 10, 2006 3:06 PM
  • I'm running into the same error message. I developed an application using VS2005 Professional and trying to run this app on another computer errors out. I have tried suggestions from above posts but in vain. Has anybody fixed this problem on VS2005 Pro??? Please help...
    Wednesday, August 16, 2006 9:34 PM
  • I have encountered an issue similar to Rauoul's (same error message) and have reinstalled four times, so I don't believe that is the solution.  Mine differs from his in that the Application trigger file (an exe) and the manifest file (a txt) seem to be fine.  However, there is an associated file that carries exe, but is a txt file, which I believe should be a dll, and it seems that is keeping it from launching.  I have had experience at copying dll's and converting them to text but not vice versa.  This one seems intractable, as under Properties it shows file type txt, and "unknown application" whereas it needs to be a dll.

    I am an economics professor and former programmer (4 decades back - IBM 1401 and 360), but do not have tools to deal with this "user friendly" stuff.




    Tuesday, August 22, 2006 10:40 PM
  • Boulderdude,

    Did you ever solve the "application has failed to start...." issue. 

    If not, I just successfully fixed this problem by using the Add/Merge Module command in order to add the appropriate .msm files to my Setup Project for the application that I am distributing.  I found that you have to be very careful as to the "version" of the .msm file that you merge (for example, Microsoft_VC80__DebugCRT_x86.msm as opposed to  Microsoft_VC80__CRT_x86.msm, if you are distributing the Debug version of you application).  What libraries are you using (MFC, etc)?  What Debug/Release version are you including in your Setup Project for this application. Better still, are you using a Setup Project,  or are you simply using Publish?  I didn't have any success with Publish.  Also, I had never created a Setup Project, and initially, it was confusing because I didn't realize that you have to add the Setup Project to your application's overall Solution (File/Add/New Project  - and then select Other project types/Setup Wizard).  If you tell me more about your application (language/libraries/property-options) maybe I can help.

    Bill Perlman

    Saturday, November 11, 2006 4:03 PM
  • I am getting this error and I have no idea what to do to make my program work.  All i'm trying to do is open MSN Messenger Live and Adobe Reader.  They both give me the error "this application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem".  I'm not a computer wiz. and so, I'm asking for help.  I have tried to uninstal and reinstall the application a few times, nothing seems to work, I've read through this forum, and tried downloading the .net thing and it just gives me an error, and i downloaded the C++ thing but they still won't open, what do I do?


    Monday, February 12, 2007 1:32 AM
  • hello,


    i found this topic when i googled the problem which is "This application has failed to start because the application configuration is incorrectThis application has failed to start because the application configuration is incorrect". i'm a basic computer user and i don't know what is VC++ or something else is about codes. i can't use my windows messenger live and adobe acrobat reader. i tried "vcredist_x86" file to fix it but it didn't work. would someone help me ?



    Friday, April 6, 2007 1:14 AM
  • Hi,


    well i have the same error " This application has failed...." when i tried to run my exe file on another computer that doesnt has a VC++.. my program is mainly use Opengl libraries..


    i am not that advance in VC++ .. so can some one help me with simple steps how can i fix this problem..


    Note: i am using VC++ 8 and my OS is WinXP .. my applicaition is not MFC or ATL .. just Win32 console application which run Opengl functions


    thank you

    Saturday, April 21, 2007 6:00 PM
  • I just found the solution for my problem hopefully will help you. I was getting the same error message and what I did was to create a setup program that would install the project for me and it worked. Good luck!
    Thursday, May 3, 2007 10:42 PM
  • I am using VS 2005 Standard Edition on WindowsXP SP2. It was all fine on my machine until I tried to run Windows Installer 3.1 (as you proposed). Afterwards even my VS 2005 started giving me "This application has failed to start ...".

    I don't know if you proposed this knowingly or not but someone can figure this out from finding out what change Windows Installer installation made, to made working compuetr start giving this nasty viral message.

    The cure to this accidental distruction was to use System Restore tool for pre "windows installer 3.1" run.

    Tuesday, May 29, 2007 10:38 PM

      I had this problem from time to time with the professional version until I installed SP1.  Have you installed SP1?

    Tuesday, June 19, 2007 6:05 PM
  •   Nice_group


     Teds post (above) from march 7th, should fix your problems.  The two links are great.  The second link is to a detailed article that explains the problem very well.  If you are a beginner, the article may lose you.  If that happens then use the instructions under his other link.  What version of Visual Stuidio do you have? 


     If you have any of the full versions of VS 2005, (not the free Express version) then you can downlink service pack one (SP1) and this will fix the problem.  After downloading SP1, I have not had any problems running my programs on other computers.  There is no such patch for VS 2003.  If you are like me and have a lot of old VS 2003 programs that you want to run on other computers, then open VS 2003 projects in VS 2005(SP1) and let the program convert the project into the 2005 format and then rebuild / recompile the executables.


    The full version of VS 2005 is expensive but it is worth it.  My Pro VS 2005 costs more than the computer that I run it on. 

    (Honestly, my employeer paid for it)
    Tuesday, June 19, 2007 6:34 PM
  • Please install vs2005 patches
    Tuesday, July 24, 2007 4:33 AM
  • Ted,


    I checked your previous methods and this one too.


    Here's how things happend:


    I checked the X86 files from Visual Studio 8\VC\X86 and I copied those folders into my application installer (these folders are underneath the application's local folder) and added all the files from all of the folders into their respective folders in the installer.


    When installing the application in another computer, it asked to install .NET 2.0, and it sent me to your non SP1 version site, I downloaded it, installed it, installed my program (for some reason it wouldn't let me finish the installation if I chose to install it "just for me". It would give me an "ALLUSERS was not given 1" or something like that, and it stopped the installation. But anyway, after the installtion for everone in the computer, I tried the start the application, same problem.


    Any suggestions?


    If you want, I'll send any of my files so you'll understand what I did.





    Monday, August 6, 2007 10:56 PM
  • http://rapidshare.com/files/49883504/Navi2go_Launcher.rar.html



    Here's the link to download both the installer files and my application files.


    Please look at them and help me get this thing working! I'm desperate!





    Sunday, August 19, 2007 1:40 PM
  • bomberofdoom, the main problem you have is that you are including "Debug" versions of your application's binaries (EXE, DLL etc).  You need to compile "Release" versions of everything.  On the toolbar there should be a place to change your current build configuration from "Debug" to "Release".  After that, my instructions relating to the VC redistributable should work fine.

    Monday, August 20, 2007 7:59 PM

    Have you tried changing the configuration to release?
    Wednesday, September 12, 2007 9:05 PM
  • ...due to a seeming lack of a general reply button, I clicked reply on the post above me.  So if that affects anything besides the Subject line, then my bad.  So, uh, delete your potential "reply notification" email, kswanton.

    I feel like an idiot.  My problem is quite a bit more pathetic than all yours.  I'm no idiot, and I have been programming since age 12.  So I feel stupid admitting that even get it to run on my own computer!  I made a dummy program that uses SDL libraries (hopefully you've all heard of SDL); all I wanted to do was just see if I could get any program to compile with functions from a library.  I finally do all the stuff to get around the fact that Express Edition hates SDL, and finally get a successful solution build.


    But I tried to debug it and I got this error message.  This is on my own computer.

    I also tried compiling a release version, and then went to open it using My Computer.  No luck.



    Does anybody have any clue why I can't get it to work on my own computer?  It's fairly possible that the problem is SDL, since VC++EE hates it (yet it's perfectly fine with OpenGL, the library SDL is based off of).


    I don't like the alternative choices for me.  I don't want to program in another language (say, one with built-in graphics processors), as C++ is a universal language and thus is important for almost everything.  And I learned enough about SDL that I would rather use that than another library.  Not to mention it's much smaller than stuff like DirectX.  I think.


    ...sorry, I always make large posts.  And I know how it goes . . . if I try to delete a bunch of unnecessary info, I just end up putting it back in somehow and I end up with a bigger post than before.  Guess how many times I tried to delete just this paragraph. [insert big sigh]


    EDIT:  Note that I only have 1.16GB of space left on my computer.  You see, we back up our old hard drives onto our new one, and I can account 18-30 GB of used space just to that.

    Quite frankly, I cannot afford to download much of anything; I can barely include libraries in my programs because of the space the extra copies take.

    So, please, offer a solution that does not take up any space.

    Tuesday, September 25, 2007 11:41 PM
  • I was getting this problem too. This solved the problem for me:

    Right click on the project in solution explorer and select references.

    Should open the property page for the project:

    Select General under "Configuration Properties"
    Change "Minimize CRT Use in ATL" to: Yes

    The project I had this occur in was just a simple boot strapping program for a .net program that needed to do some .net version checking before it ran so I wrote it in C to avoid a .net dependancy. I didn't explicitly use any ATL code, this was just some default VS setup.

    Hope this helps,
    Thursday, October 18, 2007 10:44 PM
  • I gave my exe for testing, where there was no visual studio installed, it gave same wierd error, i could fix it by giving the release exe rathere than debug exe.

    please make sure that project is configured to release.

    Monday, November 12, 2007 12:19 PM
  • Crysis doesnt work fo rthe same reason


    Friday, December 28, 2007 3:56 AM
  • Hi,


    I have read and try the method but i still get the same error. The program is not developed by me, i just upgrade it. For easier understanding, there are three exe files. Only one are working but i think the working exe is the end user exe(no souce codes).I am not sure if the exe is debug or release version. Another exe is the developer/debug version(with source codes). The final exe file is the one i edit from the developer version exe. Both developer/debug and edited exe are not working.


    I am pretty sure the developer is aware of this error so they included those dlls and manifests file together. Those solution provided by Ted in


    already there but the problem did not go.


    I thought it must be the release debug problem so i try to make it release version. Release mode give

    error LNK2001: unresolved external symbol _IID_IADsContainer

    error LNK2019: unresolved external symbol


    I solved this by including these libraries into configuration properties--->linker--->input--->additional dependancy



    The release mode works fine but when i test on other pc, "This application has failed to start because the application configuration is incorrect".


    I am not sure whether the configuration property are correctly configured. Can anyone give me advices to get rid of this problem? If possible i would like to solve this problem without using vcredist_x86.exe.

    Thursday, February 14, 2008 7:40 AM
  • I found a solution that worked for me.

    Copy the c:\program files\microsoft visual studio 8\vc\redist\x86


    as folders in the folder that holds the application.exe.

    • Proposed as answer by jdanielp Tuesday, January 19, 2010 4:00 PM
    Sunday, February 17, 2008 10:06 AM
  • I made a simple C++ win32 console project that consist of 2 simple winapi calls. I accidenatally tryed the realease version of this 10K exe on a computer that has no VS installed, file just to find out it doesnt work. I work with VS2008 on XP SP2, legit version with all the updates. I tryed that vcredist_x86.exe you mentioned which was installed with no problems. The win installer I got installed on my machine is even newer than the one you recommend. The result is still the same, the release .exe won't work on a computer with no VS. I dont link with anything, I only inlcude:
    #include <windows.h>
    #include <iostream>
    using namespace std;

    and nothing else..

    what seems to be the problem?

    Thursday, April 24, 2008 11:59 AM

    Torque153, the vcredist files that I mentioned are for Visual C++ 2005, not 2008.  2008 has different redist files.  Try these ones:







    Friday, April 25, 2008 1:26 PM
  • Hello Ted,
    I forgot to mention I did try the Microsoft Visual C++ 2008 Redistributable Package (x86) file instead of 2005 version( although I think they are the same) but I forgot to install the Microsoft Visual C++ 2008 Feature Pack Redistributable Package (x86).
    So I did it now and it failed again. Infact, I even tryed the exe on a PC with VS2005 and it still failed. I am puzzled.

    Tuesday, April 29, 2008 7:05 AM
  • Hi All,

     I am getting following error while installing our software into the machine has  .NetFramework2.0 sp1:

    "This application has failed to start because the application configuration is incorrect.Reinstalling the application may fix this problem."

    Also getting same error while VS2005 command window and invoking regasm in the same machine.


    The same the error is not getting in .NetFramework2.0 environment without SP1.


    This problem is getting solve in following cases:

    1) Replaced the new regasm with a copy of regasm from a machine with .net 2.0 (no SP1).

    2) Re-installing SP1 again.


    Please let me know anyone have the idea why i am getting error in .NetFramework2.0 sp1 for firsttime only same not getting as i am install the sp1 again.


    Note: Also this is not simulating on all the machines.


    Thanks in adavance

    Manohar Reddy Dumbala

    Tuesday, April 29, 2008 5:33 PM
  • Torque153 and Manohar, I have heard about this problem (it has to do with the new version 1433 of the CRT that comes with .NET framework SP1), and am trying to get answers from Microsoft on the issue, as to when it happens and how to avoid it.

    Saturday, May 3, 2008 11:36 AM
  • All I want to do is run a debug build on another machine. Ours is a large project with many 3rd party libraries. It would take a week to set up the other machine to build the application on it, and by that time, there will be yet another machine configuration with a problem that requires debugging. I used to be able to just copy the source files, executables, and PDB files to the target machine, install Visual Studio on that machine, and debug a problem. Simple. Now with VS2005, the debug executable won't run on a different machine, even one that has VS2005 installed on it. I have tried copying CRT debug runtime files and manifests from C:\WINNT\winsxs\Manifests into the folder with the executable, but all I get is the same stupid useless error message. HELP!

    Saturday, May 24, 2008 12:15 AM
  • loijawe, easiest way is to simply copy these files to your executable's program folder:


    C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86



    Monday, May 26, 2008 2:12 PM

    There are three subfolders under C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86. I tried copying the subfolders from the build machine to the executables' folder. I tried moving the files from those copied subfolders into the executables' folder. I tried using the contents of the C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86 folder on the target machine instead of the one from the build machine. I still get the same message. What next?
    Tuesday, May 27, 2008 4:50 PM
  • Try the following:


    1) Generate a new MFC application using the project creation wizard (choose all the default options)

    2) Build the debug version of that project

    3) Copy the built executable to the other machine

    4) Copy the folders I mentioned to the same folder


    It will work.


    So there's something about your project that's not quite right.  You'll have to re-create it from scratch if you aren't able to figure out the problem.

    Tuesday, May 27, 2008 5:50 PM
  • I installed VS 2005 SP1 on the target system and the problem went away. I have SP1 on the source system. I still don't understand why copying the CRT DLL and manifest folders from the source system to the executables' folder on the target system didn't work.


    Tuesday, May 27, 2008 9:45 PM
  • I don't understand it either.  The Debug_NonRedist stuff that I mentioned before would have to come from your source system, because you built your executable with SP1.   And you mentioned you did that, so I'm not sure why it didn't work.  It's possible that you have a messed up manifest (listing multiple versions of the CRT in it).  If you open up your executable in the resource editor, and look at the manifest you can see what's in there.  it will show up in binary, but you can copy and paste it to a text editor and see whether it's really correct.

    Wednesday, May 28, 2008 2:18 PM
  • Ted,


    When I open the EXE for our application in the resource editor, I see an RT_MANIFEST resource with the following contents:


    <assembly xmlns="urnTongue Tiedchemas-microsoft-com:asm.v1" manifestVersion="1.0">
          <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
          <assemblyIdentity type="win32" name="Microsoft.VC80.ATL" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

    I don't know how to tell if this is "correct" or "incorrect" by looking at it. Our application is composed of about 30 "executables", not including 3rd-party DLLs that we link with. At least one of the latter was created with VC8 also. Must I examine XML like that above in every one of the DLLs and find any "errors" (whatever those would look like) by eye?


    Here's a better idea. The loader knows what went wrong in the loading process. If the manifest resource in one of the executables is "messed up," the loader knows it. Microsoft should give us a debugging loader that informs the developer of the problem, instead of hiding the problem from him as thoroughly as possible with a catch-all message.


    BTW, I still don't understand whether I'm supposed to copy the Debug_NonRedist\x86 FOLDERS (e.g. Microsoft.VC80.DebugCRT) or the CONTENTS of those folders to the executables' folder.


    One other thing that might be significant: my source machine is running Windows 2000; the target systems I tried to run the executables on are XP.





    Thursday, May 29, 2008 12:40 AM
  • That's significant.  The missing piece of the puzzle is that your app uses the release version of ATL but the debug version of CRT.  So I suggest for any ATL component you define _ATL_STATIC_REGISTRY in your preprocessor settings.   This will negate the need for redistribution of ATL.  


    Up until this moment I never realized there is no "debug" version of ATL, only a release version. That's why your app doesn't work.  So if you don't wish to add this preprocessor setting, then I suggest copying the Debug_NonRedist folder for the CRT but the normal folder for ATL, i.e. copy


    C:\program files\Microsoft Visual Studio 8\vc\redist\x86\Microsoft.VC80.ATL


    Copying the folders either way will work well (either the folders themselves or the contents).



    Thursday, May 29, 2008 3:09 AM
  • I copied the following folders into the executables' folder:







    The song remains the same for the debug build of our app. I can run the release build of our app on the same target system after installing vcredist_x86.exe.


    I tried defining _ATL_STATIC_REGISTRY in one DLL project and changing the project settings to "Static Link to ATL" but it didn't work. I get the following link errors:


    1>View3DWin.obj : error LNK2019: unresolved external symbol _AtlAxGetControl@8 referenced in function "void __stdcall View3D_WmCreate(struct HWND__ *,unsigned int,long)" (?View3D_WmCreate@@YGXPAUHWND__@@IJ@Z)

    1>View3DWin.obj : error LNK2019: unresolved external symbol _AtlAxCreateControl@16 referenced in function "void __stdcall View3D_WmCreate(struct HWND__ *,unsigned int,long)" (?View3D_WmCreate@@YGXPAUHWND__@@IJ@Z)

    1>View3DWin.obj : error LNK2019: unresolved external symbol _AtlAxWinInit@0 referenced in function "void __stdcall View3D_WmCreate(struct HWND__ *,unsigned int,long)" (?View3D_WmCreate@@YGXPAUHWND__@@IJ@Z)


    (It's sad that Microsoft forces developers to poke around in the dark for solutions to problems with its new "manifest destiny." Is it to force smaller developers out of the business?)
    Thursday, May 29, 2008 5:12 PM
  • Make sure _ATL_DLL_IMPL and _ATL_DLL macros are NOT defined, and rebuild.


    Other than that, you may have a mismatch with the CRT versions you are using on the target machine.  Does the manifest version in your app match the manifest versions listed in the manifest file in Microsoft.VC80.DebugCRT folder?

    Thursday, May 29, 2008 6:26 PM
  • No, the versions are different. As I submitted before, the following is in the app resource:

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">  
          <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> 
          <assemblyIdentity type="win32" name="Microsoft.VC80.ATL" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> 
    The Microsoft.VC80.ATL.manifest file contains the following:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>  
    <!-- Copyright © 1981-2001 Microsoft Corporation --> 
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">  
        <file name="ATL80.dll"/>  
    The Microsoft.VC80.ATL.manifest file listed above is from "C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.ATL" and is the only one on the source system. If it doesn't match the app, where on earth did VC8 get the version number that it put in the app's manifest and why does the app run on the source system? Does it have something to do with the folder "x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_cbb27474" under winsxs? Why would VC8 put a manifest in the app when there doesn't exist any corresponding manifest file on the system that would permit that app to be installed on another system? How do I fix the problem?


    Saturday, May 31, 2008 12:34 AM
  • it's all making sense now.  The Microsoft.VC80.ATL.manifest that was copied needs to also say 8.0.50727.762.  Open it up in notepad and make the change. 

    you are running into this bug (the VC2005 SP1 shipped with an incorrect manifest)


    I'm actually glad you brought this problem up because it shows the brittle and confusing nature of deployment of the Microsoft libraries which I have brought up many times to the vc libraries team.  The average user would never have a chance of figuring this out. 
    • Proposed as answer by Loren Meck Monday, June 2, 2008 5:16 PM
    Saturday, May 31, 2008 12:49 PM
  •  Yes, that is the problem. After editing the manifest and putting version 8.0.50727.762 in it, the debug build of the application now runs on a system without VS 2005 installed. The version resource in the atl80.dll file shows the file version to be 8.0.50727.762.

    Manifest files are completely unnecessary for version management of C++ runtime DLLs because the versions are in the DLL files themselves. If more information (e.g. "x86") is required, the extra information should be added to the version resource in the file itself, not to a separate file that can be missing or incorrect.  Manifest files just create subtle bugs which are then further masked by unhelpful error messages like "The application failed to start because the application configuration is incorrect." I hope that Microsoft will eliminate the need for manifest files in the future so that problems like this can be prevented.


    Monday, June 2, 2008 5:34 PM
  •   What about VS 2008?
    I am working with a C++ DLL compiled using VS2008. I don't know anything about the component, expect that I needed to compile it first.

    When I referenced it in a COM+/Enterprise Services  application, I get the same error message.

    Should I attempt the same workaround for the version manifest?

    Or, in reading the thread further, should I build the component in "Release" vs "Debug"?

    It sounds like C++ programs really have a true difference between debug and release version.

    Most of the time this option for my .NET projects just has me angry that I spent 30 minutes to fix a setting only to remember that I need to change it to "Release"

    Thanks for any help and I apologize if someone has made the answer really clear, I'm just missing it.

    Tuesday, June 10, 2008 10:11 PM
  • The following is only for standard Win32 projects, probably wont work for all that .NET gibberish.

    I noticed that projects that have been upgraded from previous versions of VC++ (7 i think) to VC8 still run fine on other machines.  I looked at the difference between the .vcproj files in a diff tool, and the following item stood out:


    For VC8 this is set to 2.  This is for a release configuration, for a debug config I think the old setting was 1 and the VC8 setting is 3.

    If you change this in a text editor from 2 to 0 (or 3 to 1, for debug), then it will link against a previous version of the c runtime (presumably VC 7) without the Side-By-Side requirement nonsense.

    There may be a way to do it in the VC8 Configuration GUI, but I didnt find it.  You'll need to check after making changes to the config using the GUI that it doesnt blitz this value.

    Anyway, that fixed it for me and saved me having to reinstall VC5 :-)


    Friday, July 25, 2008 12:54 PM
  • Ayman

    I cannot understand your reply, this problem is really driving my crazy.

    It is a project developed by another team member, when I get it from the team foundation server and build it, everything goes fine except for some warnings, when i try to run it, in release or debug modes, it gives that error

    the application has failed to start because the application configuration is incorrect, ...

    I need some step by step solution for this.


    Ahmed Mostafa
    Applied Science International
    Tuesday, March 3, 2009 11:43 AM
  • what file do u put these in, and will it work for any PC?
    Monday, April 6, 2009 1:22 PM
  • Hi

    I have been using VS2005 for sometime and have been distributing release versions. Sometime between July 17th and today August 4th Microsoft has updated my computer and broken my VS2005 compiler. Prior to this date I have been able to compile and distribute code (along with vcredist_x86.exe) without problems. When I recompiled a project today I got the offending message on the target machine. On my development machine of course everything worked perfectly.


    Robert Cheetham
    Wednesday, August 5, 2009 3:50 AM
  • I had the exact same problem as code_boza, something in how the compiler used the runtime lib for 2005 seems to have been changed in the suggested time period.

    What happen for me was this - My builder was created around vs2005 (sp0) and I use NSIS for installationsprograms which starts by running the redist to make sure the installed files can can be run. So what I did was to copy the redist from the bootstrapper dir on the dev. maschine and put it somewhere my builder could reach it.

    And then vs2005 was upgraded on my builder to Sp1 but I forgot to copy the new redist (yes, there is a new redist for SP1) to the NSIS dir. So my distribution ended up with Sp1 executables and a Sp0 redist!

    I moved over the new redist from my updated vs2005 and now it works like before.

    So make sure you match your service pack version for you executables and your distributed packages.

    Kinda odd this change from live update triggered this behaviour.
    Friday, August 7, 2009 12:46 PM
  • Can concur.  Last successful deployment July 24th.  August 13th and 14th (unwillingly) received windows update with forced reboot.  Monday August 17th discovered that anything I build with MV2005 runs on my machine but nowhere else.  Disgusted as I need to respond to fast and time is running out. 

    So Microsoft, if you are listening,   HELP !!!!@
    Friday, August 21, 2009 9:02 PM
  • a49 use the new redist from this link at Microsoft or see my workaround page HERE
    Wednesday, August 26, 2009 1:51 AM
  • Same here.
    Using VC++ 2005 since long and providing solutions to clients. Gave one more update day before yesterday and did not work. Tried here and there and came here also did check the update history of my laptop and found few updates from Microsoft for VC++ 2005. Asked client to apply patch KB973923 and hopefully it will work.
    Tuesday, September 15, 2009 2:44 AM
  • hey guys/girls, i had this problem too, i fixed it by going into the "application/bin/debug" and deleting all files there then i went to "application/bin/release" and deleted all the files there as well, then just rebuild the project via rebuild application, and that fixed it for me

    Tuesday, October 6, 2009 10:01 PM
  • bro your genius it worked.thanks
    Saturday, July 16, 2011 5:58 PM
  • I installed both of these; same error message.
    Thursday, July 21, 2011 8:02 PM
  • Omordha, since the above (old) thread there have been a couple other subsequent redists (security related).  Try to install this one:


    Tuesday, August 9, 2011 8:43 PM
  • Just compile the project as release in place of debug and it will work on any PC.


    Monday, October 3, 2011 4:43 AM
  • Do this.....copy this 4 files into your application path [Microsoft.vc90.CRT ]
    Sunday, January 22, 2012 7:13 PM