When I start VisualStudio it frezzes on the start screen. But when I start it a second time while the first instance is open the second instance works fine.
It's not that important but what could cause that problem?
Not sure. Sometimes some Visual Studio extensions are locking up Visual Studio.
I think by default Visual Studio tries to update these extensions
that have been installed automatically.
Recently I was trying to run Visual Studio (at Home) and it would freeze if I tried to open a specific project. But I was busy, so I didn't pursue it further and did other things. Then a week or a few days later I tried to run Visual Studio (at home), and it locked up when I ran it. I tried really hard to fix it.
There is a way I don't like where you can delete all or most of the
extensions from the place Visual Studio installs them, but this is
messy, and it is easy to get rid of something you need, and may hard
to get it back where it works correctly again. So I now recommend against this since there is a better solution now, below!
I searched to find a solution, and someone on a Microsoft board I think said to run from a command prompt as Administrator: DEVENV /RESETSETTINGS, I tried that and it didn't work for me. Then I thought, run DEVENV /? to see what I can see, and I saw :
DEVENV /SAFEMODE
So I tried that and it worked! Note: it was still being run from the Visual Studio Developer Prompt as an Administrator.
Visual Studio loaded up correctly, and I was able to look at the
installed extensions.
Eventually I noticed that they all or a lot of them were disabled (probably because of this SAFEMODE parameter), and I noticed that it the most recently updated were at the top of the list. I noticed that a lot of them had been automatically updated by Visual Studio and started Uninstalling a bunch of the more recent ones, and reverted at least one of them, then later uninstalled it. Eventually, after about 6 to 10 uninstalls, I got it to where Visual Studio would load normally, without the /SAFEMODE parameter! Cool!
So I turned off the automatic updates, so this will never happen automatically again. If I load a new extension or update and existing one manually, I should always exit Visual Studio and reload it after not doing too many updates or installing too many extensions to see if these extensions allow Visual Studio to load.
Sometimes an extension will not freeze Visual Studio, but will have errors. The ones that are the big problem are the ones which prevent Visual Studio from loading all the way and freezing it up. But with the above solution, you can eventually, cleanly, uninstall all the latest updates or new installed extensions until you finally get Visual Studio to load normally!
This workaround should be more widely known, so I am putting my solution to it here. Hopefully what I found should help someone else who is in a hurry, without having a lot of time to burn trying to get Visual Studio running again without freezing!
I use Visual Studio Community 2017, and I got this same issue on startup until I stumbled on this solution that deals with some corruption in the .suo file. Before I open Visual Studio for the day, I first delete the .suo file in my project folder, and it starts up just fine.
It's in a folder called .vs next to the .sln file. You may have to go to folder options View and check "Hidden Items" in order to find this folder. Dig down in that folder and you'll find the .suo file. Delete it. When you startup the project in Visual Studio, it will automatically create a new .suo file. So you'll have to do this every time you reopen.
Related
First of all, I am trying to open a support request with Microsoft about this issue, but their support reporting portal isn't working. I have resorted to Stackoverflow because I have no way of getting to Microsoft.
Yesterday, I started updating Visual Studio 2022 from Visual Studio Installer by mistake and paused it shortly after. Today, I tried to open a project but Visual Studio seemed unavailable. At that point I remembered about the paused update and re-opened the Visual Studio installer. I tried to Resume, and I got the below error. The Modify and Remove options give out the same error too. There is no Repair option.
Sorry something went wrong
The dependent package of
'Microsoft.VisualStudio.Debugger.Concord,version=17.1.33203.90,productarch=x64'
cannot be found: Microsoft.VisualStudio.DebuggerClient.Concord,
version=[17.0,18.0].
I also tried Restarting and deleting temporary files using the Disk Cleanup tool - no difference.
I have tried to force an uninstall from the Add or Remove programs but this still redirects me to the Visual Studio installer.
I have tried to research this error online but found nothing.
I did not fix the issue but at least I managed to uninstall the Visual Studio instance to be able to start from scratch again. If you do not want to go down the route of uninstalling, feel free to try the steps as suggested by #garbagecollector.
I deleted the installation folder for 2022 from ProgramFiles.
I deleted the Visual Studio installer from Add or Remove programs. (Note: This actually uninstalled a working version of Visual Studio 2019 that I had, and left the messed up version of 2022 with the same issues, so beware if you do not want to uninstall another working version of Visual Studio)
Then I ran InstallCleanup.exe via CMD (in admin mode). Refer to the "Remove All with InstallCleanup.exe" section within this article. This seems to have cleared all Visual Studio related files including the Visual Studio
installer, and I could re-download the installer for Visual Studio
2022 Community edition and start afresh.
I faced the same issue today and could solve it by removing corresponding dependencies from _package.json files from C:\ProgramData\Microsoft\VisualStudio\Packages\[PACKAGE_NAME] folders.
I am not sure whether you can repair your installation this way, I tried only with uninstall.
So in your case edit this file:
C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.VisualStudio.Debugger.Concord,version=17.1.33203.90,productarch=x64 and remove the line marked with "-->" under "dependencies":
{
"id": "Microsoft.VisualStudio.Debugger.Concord",
...
"dependencies": {
...
--> "Microsoft.VisualStudio.DebuggerClient.Concord": "[17.0,18.0]"
}
}
In my case I had to repeat this procedure for three or four _package.json files.
In Windows Explorer, whenever I try to open a folder that contains TypeScript files, explorer freezes and crashes. When I try to edit TypeScript files in Visual Studio, it allows me to do so until I save the file. When I save the file, Visual Studio crashes without any dialogs.
I tried completely removing anything Visual Studio related (uninstall, registry clean, etc.) and reinstalling. I also tried running Windows in safe mode, and/or running Visual Studio in safe mode, none of which work. Running Visual Studio as an administrator also does not work.
I know it is not an issue with the actual repo since these files work fine on several other developer machines. This functionality was working just fine a month ago, with no changes in updates or installed extensions.
I am running Visual Studio 2015 Update 3 (14.0.25431.01) on a Windows 10 64-bit machine. TypeScript Tools for Visual Studio is at version 2.2.1.0.
Please let me know if there are any logs I can provide, I'm not sure where to get them.
The following update fixes this issue:
Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4015438).
This is as of March 20, 2017.
UPDATE:
Many people have reported this issue as being the result of Windows Update KB4013429. This affects all Visual Studio installations. To resolve the issue, simply uninstall this update and restart your PC.
Old "Solution":
I solved the problem by reinstalling/cleaning Windows.
I know that's not a very good answer, but I wasn't able to solve the issue otherwise. Disabling antivirus shields did not work, and neither did running in safe mode. I think something in the registry may have gotten corrupted during a Visual Studio reinstall. Would love to hear any actual solutions if anyone else comes across this problem in the future.
I deleted a lot of stuff in the Registry under HKEY_CLASSES_ROOT\.ts, and now I can at least view folders in Explorer that contains .ts files, but I still cannot right-click them.
The biggest problem for me and my colleague was that Git and Visual Studio was unable to overwrite .ts files sometimes ("permission denied"), and we couldn't delete them manually either.
I'm not quite sure this has solved the problem permanently for me, but it seems so at the moment:
I used Handle to determine that SearchProtocolHost.exe had locked my .ts file, and wouldn't release until a few minutes later.
A few Google searches later, and I have now disabled indexing .ts files in Windows Search. So far, no more locks!
I have VS 2008, 2010, and 2012 installed.
Initially, VS2013 Team Explorer was installed (Shell only). I uninstalled that.
Now, the Visual Studio Version Selector shows an empty list when executing a .sln file. Nothing shows.
How can I repopulate this list? Where is it stored? Registry? I tried to find entries, but since it doesn't actually have any items in the list, I couldn't search for a specific string.
I just encountered the same issue after installing Visual Studio 2015 parallel to an existing 2013 installation. In my case it turned out that that the problem was related to the solution file itself: It seems that the version selector does not like BOMs etc. (don't know how the solution got crippled, though). Make sure that the solution starts with
Microsoft Visual Studio Solution File, Format Version 12.00
and has no space, non-printable character etc. before that. After saving the file, the effect should be immediately visible with the correct icon returning.
I just ran into a similar problem where this dialog started popping up after a recent Windows Update (Win10) on 1/6/2018. That update caused all sorts of havoc in terms of broken file associations.
I tried searching for solutions and trying a few things but everything was overly complicated and messy.
My solution was to run the Visual Studio (2013) repair.
After the repair, I did receive a warning (from vs installer) about update 3 failing to update but I restarted the computer and sln files can now open without needing that version dialog. Everything seems to be compiling and running fine as well.
Just ran into this situation for VS2017 then I realized I have unfinished updates for Visual Studio when checking Visual Studio Installer.
The installer displayed a hint that I should restart my computer to complete the update and after doing so, the version selector works again.
We have a really big solution with more than 200 projects and thousands of files. Despite of that the solution used to load pretty quickly in Visual Studio 2010 as well as 2012. However, after copying the whole SVN repository to another location, loading and closing the solution suddenly took extreeeemly long. (I am talking about 30-60 minutes here!)
I found a solution myself and I wanted to share it here, hoping that it might save someone quite a few hours of research and staring at the "Preparing solution..." dialog.
When inspecting the devenv.exe process with Process Monitor, I found out that it is pretty busy with accessing the .svn directory. Here is what I did (and this somehow solved the problem):
Kill Visual Studio
Open Visual Studio without loading a solution
Disable AnkhSvn as Source Control plugin (Tools->Options->Source Control->Plug-in Selection->None)
Disable "Document Well 2010 Plus" (VS2010) or "Custom Document Well" (VS2012) in Productivity Power Tools (Tools->Options->Productivity Power Tools) - I read that somewhere and it might have helped as well...
Close Visual Studio
Delete the solution's *.suo file. This is located in the same folder as the solution itself. NOTE: You will lose several settings for your solution, like currently opened files, breakpoints, bookmarks, current solution configuration & platform (e.g. Debug x86) etc.
Restart Visual Studio
Load the solution - it was much faster now!
Close Visual Studio
Open Visual Studio without loading a solution
Re-enable AnkhSvn and the "Document Well"
Restart Visual Studio
Open the solution - it was still loaded in seconds!
I do not know which of these steps actually solved the problem. Probably, not all these steps are required, but I did not want to reproduce the problem to find out which steps may be omitted. :)
None of those helped me, what I did... I watch with ProcMon of sysinternals, filtering for devenv, and I saw a lot of entries of fussionlog. I had enabled fussionlog for debugging purposes some weeks before and didn't think in disabling it. I just had to disable fussionlog and the solution opened faster.
You can open the Visual Studio in the Safe Mode, and then check your plugin and source control settings after opening the project.
Safe Mode means "Starts Visual Studio, loading only the default environment and services."
How :
devenv /SafeMode
Or according to your path
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /SafeMode
source : https://msdn.microsoft.com/en-us/library/ms241278.aspx
In my case, the following worked without any of the intervening steps suggested:
Kill Visual Studio.
Start Visual Studio directly (i.e., not from the .sln file).
Then, from within Visual Studio, open the solution.
In my case this was all it took to make the problem solution load quite quickly, without the need for me to change any settings or delete any files.
fwiw, I realize this is a late entry, but I found that simply removing (deleting) my large number of breakpoints resolved the excessive load time and compile time.
This action reduced the size of the .suo file from 214MB to 977KB. Let VS handle the .suo file itself.
Compiling and loading now takes < 1 minute instead of 5-10 minutes for a solution with 35 projects. Visual Studio 2012 Pro, update 4.
None of the other answers worked for me. CI compile times were fine, but loading my solution in Visual Studio was taking almost two minutes. VS would then operate just fine until I closed and opened the solution the next time. Different versions of VS all showed the same problem and both safe mode and deleting the suo didn't help.
I ended up following the advice in http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx to use Windows Performance Recorder to instrument VS and find the problem. By looking in Windows Performance Analyzer under the "CPU Usage (Sampled)" section and adding the "Stack (Frame Tags)" column, I was able to dig into the usage of devenv.exe.
Turns out the hot path by count had Microsoft.VisualStudio.Platform.WindowManagement.ni.dll 23 calls down, and below that eventually Microsoft.VisualStudio.ServerExplorer.dll and Microsoft.VisualStudio.Data.Package.dll. That pointed me to look in Server Explorer in the UI and open the Data Connections tab. There I found hundreds of mistakenly added connections that came from the debug web.config's ConnectionString section. Removing those from web.config reduced the load of that individual project from 90+ seconds to almost instant.
I have a different cause for the slow loading of the projects.
My situation is utilizing Git and found that even switching branches was slower than it should be with project load.
Solution: Run Visual Studio as Administrator
Reason: Something with the Corporate laptop is not providing the needed Git tool access (it doesn't recognize that a git repository is in use).
I have not seen any issues with Git or my personal access to any of the project files or Git objects.
I tried the above, but it didn't solve my problem.
Here's how I got around this problem, hopefully it will work for some of you as well:
Open Visual Studio 2013 with no solution.
Create a new C# Console application and save it.
Close Visual Studio.
Reopen the Console solution created in step 2.
Close Visual Studio.
Reopen the solution that was previously hanging on the Preparing Solution dialogue. Mine opened right away, no more hanging.
Using Visual Studio 2015, I ended up creating a new solution, adding the existing projects.
Deleting the *.suo from gehho's answer helped in the past, but didn't help me in this case. There's also another .suo file in a hidden .vs folder at the root of the solution.
There are other answers here for Visual Studio 2015 Visual Studio 2015 is extremely slow
For my case it was due to TFS issue. It thinks that there are more than 5000 pending changes.
The fix is to force TFS to recheck. Go to Team Explorer -> Source Control Explorer and do "Get Latest" on the projects that have pending changes. For things that are already matching TFS, Visual Studio will actually not download anything to your PC. For things that are different with TFS, Visual Studio will let you know and ask you to reconcile the difference.
This is VS 2019 Professional.
In my case there were <import ...> entries in the project files that pointed to
paths no longer available making the loading of the solution hang indefinitely without any form of information give (Shame on Microsoft!).
I encountered this problem only recently (Mar 2021), using VS 2019. It literarily takes 30+ seconds to load the file (each).
It only effects the Layout files. I believe it could be to do with the links within the files. I have not had time to investigate them.
However, I am writing this to suggest that regardless of the cause of the problem, a simple solution is to right click on the file and open it with Notepad to get your work done.
My Visual Studio began crashing at start-up. In my search for finding a remedy, I found these two suggestions, but neither worked for me:
Launching Visual Studio while running in safe mode, and
Running repair on Visual Studio.
However, I found that if I logged into a different Windows account, Visual Studio was able to run from that account without crashing.
Here is an error code that that I observed in the crash report:
LCID: 1033
Can anyone provide a solution for returning my Visual Studio to working order?
For me it turned out to be the plugin that GitExtensions installed into Visual Studio 2013.
-- UPDATE: try this before uninstalling GitExtensions
#Enceradeira proposed in the comments to uncheck the Show current branch in Visual Studio option. In GitExtensions, you get there via Tools -> Settings -> Appearance:
-- END OF UPDATE
After uninstalling GitExtensions and reinstalling it with all VS plugin unselected my VS runs smoothly again.
I even put together a blog post about this issue because it bugged me so much.
Since you're able to run with another user login, something may be wrong with your local settings, you can try to reset them: devenv /resetsettings in Start menu -> Run.
Warning: this will restore visual studio to default settings.
In my case VS used to crash on a single solution. I resolved the problem by deleting the respective solutions's user file: SolutionName.suo
My colleague recently experienced a problem with Visual Studio 2013 crashing on start-up. Unfortunately, we found that the approach recommended in the answer by #Arun M did not solve the problem:
devenv.exe /ResetSettings
...however, using a different command line argument did:
devenv.exe /ResetUserData
An easy way to run devenv.exe is via the Visual Studio command prompt; on Windows 10, it can be found here:
Start Button => All Apps => Visual Studio 2013 => Visual Studio Tools =>
VS2013 x86 Native Tools Command Prompt
For more about these command line arguments for devenv.exe, see this answer to this related question: How do I truly reset every setting in Visual Studio 2012?. ⚠ In particular, please note the cautionary statement in that answer about the /ResetUserData command line argument!
Try to run VS as administrator. That's necessary in my case.
If coincident to these Visual Studio crashes you are getting "Heap corruption" (Exception code: 0xc0000005) errors in your Windows Application log (Faulting module name: WindowsCodecs.dll), here is something worth checking into: A faulty WIC component within Expression Blend can cause ALL versions of Visual Studio to crash upon launch, as well as cause Internet Explorer to crash upon visiting many, if not most sites. Even though Microsoft distributes this component, they call it a "non-Microsoft component". As such, a Visual Studio reinstall won't fix this,, an OS reinstall over existing Windows installation won't fix this, and a system file integrity check won't detect it.
If my case, the misbehaving codec was "C:\Program Files (x86)\Microsoft Expression\Common\Imaging\4.0.360.0\PSDCodec.dll", and simply unregistering this component got my Visual Studio working again from consistent startup launch crashes.
I post this in hopes this solution to one source of Visual Studio crashing might save others from the $500 Microsoft support incident fee and week of downtime this caused me.
I just changed the windows language in the bottom right to "EN", then started as admin. And it worked, interesting..
I had the very strange phenomenon that both Visual Studio 2010 and 2013 on a Windows 7 machine crashed when run in a remote desktop session, started from a Windows 10 pc. Debugging the crash showed a CultureNotFound exception. It was caused by regional settings on the Windows 10 pc, which could not be translated in something understood by Windows 7. I had language English(Belgium) with an Azerty keyboard. I added and selected English(UK) with an Azerty keyboard and the crashes disappeared. No other programs suffered from this.
For me it was being caused by Web Essentials and I was able to resolve by disabling it, restarting VS, enabling it back , restart again. Works now.
I had a crash on startup (or soon after startup, before opening any solution) occurring in git2-msvstfs.dll, caused by placing a 3GB temp file into a directory within my solution. Deleting the file fixed it.
Once I accidentally pressed a random key combination (maybe something like ctrl+', but I didn’t realize I was holding ctrl down so I forgot what keys I hit by the time I realized something bad had happened) that resulted in VS Professional 2017 15.3.5 crashing within half a minute. After relaunching, I found that VS would be interactive for a few seconds before it would crash within half a minute. It was really too fast for me to try to figure out what I had accidentally activated or for me to disable it before VS would crash. Also, it would even crash if I didn’t open any solution, so I figured it was not something that deleting a .vs (per project/solution Solution Explorer/open files state) folder would fix.
To fix, I followed Arun M’s comment and renamed my %LOCALAPPDATA%\Microsoft\VisualStudio\15.0_3f4d04be folder. You will need to adjust the path for the edition/version of VS that is crashing. On my machine, I think 15.0_3f4d04be is Professional and 15.0_0fed6c59 is VS Community Edition. You’ll probably have to guess based on the folder’s modification timestamp which is probably going to reflect the date you last used that edition of VS.
After renaming the versioned dotfolder, VS launched without crashing. It started with default settings but automatically restored some of my settings through the cloud sync stuff after a minute of running and it even remembered my account information so I didn’t need to sign in.
I did not need to rename my %LOCALAPPDATA%\Microsoft\VSCommon folder (which Arun M had also suggested).
I had a similar problem, both VS2015 and VS2013 would crash at startup. Tracked it down to an application I installed which put .net 4.7.2 on the system. Once i removed that app, removed .net, and reinstalled .net 4.6, Visual Studio started working again.