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
A reinstall (+3 hour) helped. The problem is that we don't know what happend. I tried the SQL Express Management package to install previously - this one failed. And I think it's suspicious - because it killed my existing SQL 2008 Management Tools (not express) also - I had to reinstall the Client Tools (editor window cannot open HRESULT error, etc)
However it's a shame that there are no exact error messages. Why don't you run a enviroment validation before the start - than you know which parts have problems..
Kuch nia laba g fita mu thoda
On my machine it failed when i was running as administrator.
solved with running cmd as administrator and:
C:\Program Files\Common Files\microsoft shared\MSEnv>regsvr32 DTE100.OLB
C:\Program Files\Common Files\microsoft shared\MSEnv>regsvr32 DTE80.OLB
C:\Program Files\Common Files\microsoft shared\MSEnv>regsvr32 DTE80a.OLB
C:\Program Files\Common Files\microsoft shared\MSEnv>regsvr32 DTE90a.OLB
C:\Program Files\Common Files\microsoft shared\MSEnv>regsvr32 DTE90.OLB
Thanks Øyvind Gellein.
It worked for me
Thanks, Øyvind... Worked for me as well...
it works for me... thanks...
the "devenv /resetuserdata" don't go.
the solution of Øyvind Gellein is the good one
The devenv/resetuserdata did not work for me too, but the solution of Øyvind Gellein worked
For the people who found (or will find) Øyvind's solution working for them: do you remember installing/uninstalling recently any application that is likely to have caused VS to stop working? Was that installation successfull or failed?
If you remember, please share your cofiguration. It seems to me there is a pattern here, some application is trashing Visual Studio's registration, and if we can identify the culprit it will worth at least creating a Knowledge Base article...
[Visual Studio Platform development]
Just had the same problem with the full released commercial product.
Perhaps, rather than posting arcane technical workarounds, you could write the code so that it fails gracefully with defaults when user settings are corrupt?
I agree with the poster above who said that it's bad coding. It's that, it's bad quality control, and it's a flawed design and exception philosophy.
Alin, I have a suspicion that it may be the Tab Well UI from the Productivity Power Tools. The last thing I did before restarting VS2010 and encountering the problem was shut down all my windows, including a set of code windows docked in a floating tab well.
Thanks. This worked for me in my VS 2010 installation in WinXP 32bit.
devenv /resetuserdata totally fixed the issue. thanks a ton