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.

1. The first issue is importing a non-TrueType font from a previous version of Visual Studio.  This was already covered by Brittany in her excellent blog post.
2. The second way to get in this state is by a corrupted window profile – the file that persists your IDE window state.  If you have floating tool windows (e.g., drag off Solution Explorer to another monitor or show the Find dialog), minimize Visual Studio, and then close Visual Studio from the minimized state, on the next launch you will hit this error. 

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%DocumentsVisual Studio 2010Settings” to another location. 

If you’re using a non-Express SKU:

1. Start Menu->Run (or Windows Key + R for the keyboard savvy)
2. Type “devenv /resetuserdata”.  The issue should now be fixed.
3. If you wish to reimport your old settings, go to Tools->Import and Export Settings, select “Import selected environment settings and browse to the .vssettings file you saved.

If you’re using an Express SKU your steps will be a bit different:

1. Start Menu->Run (or Windows Key + R for the keyboard savvy)
2. Depending on the SKU installed, type the following:
   • For Visual Basic Express type, “vbexpress /resetuserdata”
   • For Visual C# Express type, “vcsexpress /resetuserdata”
   • For Visual C++ Express type, “vcexpress /resetuserdata”
   • For Visual Wed Developer Express type, “vwdexpress /resetuserdata”

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:

• Browse this MSDN article.  This article is a bit outdated but does have some other causes and workarounds for fixing this issue.
• Some users have had success using procmon to see what Visual Studio is trying to load.  This isn’t for the faint-hearted, but it might help you debug the issue.
• Analyze the Activity Log.  Sara Ford has a post on how to do this. 

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:

1. Your window layout file: the file will be named “Design_somecharacters.winprf” under “%APPDATA%MicrosoftVisualStudio10.0”
2. Your settings file: “CurrentSettings.vssettings” under “%USERPROFILE%DocumentsVisual Studio 2010Settings”
3. Your Activity log: From a Visual Studio Command Prompt, type “devenv /log”.  Attach “%APPDATA%MicrosoftVisualStudio10.0ActivityLog.xml” to the bug.

Happy coding!

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%MicrosoftVisualStudio10.0Windows.index file, you can try copying the Windows.index file attached to this post in %APPDATA%MicrosoftVisualStudio10.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

Windows.index