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, that fixed the problemo!
Great post. I'm digging the new joint blog format for VS.
I didn't know that there was a "Visual Wed Developer Express" - is this a version for wedding planners? Just kidding. :-)
The error message wasn't very informative. But thanks, this fixed the problem!
I seem to have been hit with variant #2 of this issue.
Is there any way to more surgically reset the window layouts, or at least limit the effect of devenv /resetuserdata to just my Visual Studio 2010 installation?
I'd like to avoid having to reset my Visual Studio 2005 and 2008 user settings.
"devenv /resetuserdata" will not affect other installations of Visual Studio. To make certain, open a command prompt, navigate to C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE and run the command from there.
Program Manager - VS Platform Shell
Thanks it solved my problem. Actually I got into this problem after opening 'StartPage.csproj' from 'C:\Users\Some User\Documents\Visual Studio 2010\StartPages'. When I tried to open it, VS was not able to display anything in Solution Explorer. Then I tried to close and reopen it couple of times, but no luck. That's it, after that I fell into this problem. But thank you very much for posting this, I was trying to reinstall/uninstall/intall and nothing solved it, but this article did.
That works !! Thanks a lot Weston
Thanks. My Windows crashed taking VS2010 with her. This post really helped.
Thanks a lot!
Thankyou, ive been uninstalling and reinstalling for the last 4 hours... and all it took was a quick google.. lol
Many thanks, I have tried to remove and reinstall again without any success, but your workaround did work
Thanks, This fixed the issue.
Thx alot, have a meeting in a hour, to show the new things. you saved my life! thx.
Great post thanks for this - hit this issue this morning after my computer decided to lock up, solved it in minutes!
Good news that this is fixed for RTM also.