The official source of product insight from the Visual Studio Engineering Team
Weston Hutchins – Program Manager, Visual Studio Shell Team Short Bio: I started at Microsoft as an intern in 2005 and have been working in Visual Studio ever since. I’m currently a PM on the VS Shell Team. No, not the “Isolated” or “Integrated” Shell, but the core VS IDE – it’s UI and services. Prior to my current duties, I was the SKU manager for the Visual Studio Express products. Outside of work, I’m an avid football fan, love winter sports, and always enjoy some quality mac and cheese.
Introduction So, you’re sitting on your couch and all of sudden…epiphany! You’ve got the solution to the code problem you’ve been working on for a few days! You go to fire up Visual Studio, and instead of being treated with a new instance of VS you are presented with this -- the dreaded error: “The application cannot start.”:
“Well, it was working fine this morning!” you say. “What happened!?”
I wish I had a quick, easy, one-line answer for why this happens, but as with most things in life, it isn’t that simple. There are a number of scenarios that will cause the IDE to get into this state, which makes diagnosing this issue rather non-trivial. When Visual Studio is launched, the initialization code branches off and begins to perform a number of tasks such as reading the window layout, importing the saved settings, loading a number of .dlls, creating the main window, etc. If any one of these operations encounters a critical exception from which it cannot recover (which means VS won’t be able to initialize properly), an error is raised and the user is presented with “The application cannot start.”
Now, you may be asking, “Well the least you could do is give me some exception message that would make debugging this easier, right?” Unfortunately, no. Because of the managed to native interop on the initialization thread, all the code gets back is an HRESULT; it loses its error context. There are a few alternative approaches that we are investigating for RTM around providing a more meaningful error message.
Now that I’ve given you the background, what do you do if you hit this? We’ll start with the most common case, at least for Visual Studio 2010 Beta 2.
The Issue In Visual Studio 2010 Beta 2, there are two straightforward ways to get into this state. Both of these issues have been fixed for RTM, and, fortunately, there are workarounds for Beta 2.
The Workaround To workaround these issues, you’ll need to reset your settings file. NOTE: The IDE will be reset to its default state and all customizations will be lost. If you have customizations that you want to save, please copy CurrentSettings.vssettings under “%USERPROFILE%\Documents\Visual Studio 2010\Settings” to another location.
If you’re using a non-Express SKU:
If you’re using an Express SKU your steps will be a bit different:
What we’ve done for RTM As mentioned above, both these issues have been fixed for RTM. Additionally, we’ve also added better fallback scenarios so that if something does go wrong, the IDE will try a few workarounds itself.
What if that didn’t fix the problem? The above workaround should fix the majority of users that run into this issue, but if you’ve tried that to no avail, here are a few other things you can try:
If your still experiencing problems, the best option is to file a Connect Bug so that we can take a further look. To help us debug, please attach the following files to the bug:
Weston Hutchins Program Manager – Visual Studio Shell Team
We have recently found out another possible cause leading to "Application cannot start" message for Visual Studio. This issue has been fixed by .NET Framework team for VS 2010 RTM, but if you're still running the RC1 build you may still run into it.
The problem occurs when the shell is trying to create a new profile file to store the VS settings. The shell calls System.IO.Path.GetRandomFileName() function to obtain a new file name where the profile settings will be stored. Unfortunately the function throws a "File not found" exception. According with a developer in CLR team, "The problem occurs when the code is running on a thread that has a user context without a loaded [Windows] user profile or with a temporary [Windows] user profile. In that case, Windows cannot access the key containers we try to ask for since those are stored in the user profile.". For instance, one way that will cause Windows to start with a temporary user profile is to delete all the files and folders under %UserProfile% folder of a user from disk, then login on the machine with that user.
There is no easy way to fix the CLR code using an RC build,
There is a way to workaround the problem for Visual Studio startup, but this may be a temporary solution. VS calls on startup GetRandomFileName() function to generate new random names for the VS profile files. Once such file name is generated, the name of the profile and the name of the file storing the profile settings are cached in a Windows.index file. Basically, the Windows.index file is just a map from (profile_name -> profile_file). Next time VS is started or the profile is needed, the names of the files from Windows.index file are used. Therefore, if you run into this problem and you are missing the %APPDATA%\Microsoft\VisualStudio\10.0\Windows.index file, you can try copying the Windows.index file attached to this post in %APPDATA%\Microsoft\VisualStudio\10.0\ folder, and you should be able to start VS. The Windows.index file attached contains entries for a couple of most used profile names (Design, Debug, Design-FullScreen, Debug-FullScreen, NoToolWindows), but you'll encounter problems later, the next time a profile with unknown name will be needed or other Visual Studio component will call System.IO.Path.GetRandomFileName. Also, if Windows was using a temporary profile, once you logoff the machine, Windows will delete the temporary profile folder, so on next login you'll need to reapply the workaround. If your Windows user is using a temporary profile you'll probably want to make system changes in order to stop this from happening (e.g. recreate your user, delete completely the %UserProfile% folder, etc)
Alin Constantin Visual Studio Shell Team Development
Thanks Weston. This worked for me
Ping back from <a href ='http://himabinduvejella.blogspot.com/2010/01/vs2010-application-cannot-start.html'>here </a>
Thanks dude this saved my time.
I've reset the user data as suggested but VS 2010 beta 2 still won't run under Administrator on my Windows 7. :/
A good tutorial that works - thank you. However, it is concerning to think that in Beta 2 errors such as this are occurring.
Confirming that clicking the .sln is the only way I can get the C++ environment to boot.
However generic, or other specialized environments work fine when launched from the application link in the start menu
yep worked for me, though if you're already running previous versions of Visual Studio (I'm already running 2008) then you'll need to navigate to the 2010 IDE folder as suggested above (mine was here: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>
then do the:
I had problem 2 - shutting down VS 2010, while minimized, with floating windows. This fixed it first time - thanks!
I also had a similar problem. i could not fix it by using the above command. what i did was, Open an existing solution file and it will open close the solution and create new.
Worked like a charm !
I'm using VS2010 RC and Vista SP2. I've attempted both the workaround and opening the .sln file directly with no success. I was under the impression that this was fixed in the RTM. Maybe this isn't the same as the RC, but it's certainly a show-stopper for me.
GW, I'm tracking ConnectID 533801 which looks like this same issue. Is that your bug?
Thank you very much...!!!
Thanku very much it was very very help ful
thanku once agan