The debugger is hanging intermittently but frequently for no obvious reason. It times out eventually and recovers.
I am using vs 2010 Microsoft Visual Studio 2010 Professional 10.0.30319.1 RTMRel, running a 4.0 client app on a Vista 64 o/s.
Has anyone else been having this issue too, and have a fix?
As a related aside, anyone know if there are any service releases yet??
Cheers,
Berryl
Well, in 2005 and 2008 this happens all the time as well. Usually it has to do with (a) loading symbols from a public symbols server (yeah network I/O on the UI thread!), or (b) intellisense, or (c) you're debugging the network stack (or some other OS component) and Visual Studio is trying to use it (and things deadlock). If (b), wait for it to finish doing its thing before you start debugging. Sucks up front, but saves you time and frustration in the long run.
There are no service packs for Visual Studio 2010 yet. I've also had problems in the debugger, and sadly the best advice I can give that has worked for me is to exit Visual Studio and re-open it.
Related
hoping someone can help me. Recently my Visual Studio 2015 started to take a very long time when it encounters unhandled exception - full 20 seconds before debugger breaks and shows me where the problem is. I tried cleaning up cache, user folders, completely reinstalling visual studio, different runtime (I was using dot.net 4.6.2) with no luck. I am using VS 2015 ultimate on windows 10, running WPF project targeting 4.6.2 (I tried a very simple project with just one button to make sure it's not my solution and got same result). When this happens, Visual Studio is not responsive. Any ideas are greatly appreciated - planning to wipe my computer clean because not sure what else I can try. Thank you
The answer in my case was definitely exception assistant. Having that option turned on slows down entering break mode in Visual Studio. I found out in my case that toggling the exception off and back on improved VS breaking from 9 seconds to 2 seconds (very odd - I blame VS for it). I got to say that if I have many exceptions, I would turn this feature off, otherwise this really is a very useful dialog.
I have a particular project that uses 100% of the CPU whenever it is open. You can see, below, the CPU is being used heavily by Visual Studio and Node. I have disabled several VS extensions but still have the problem. Also it continues even if I delete gulp.js, package.json, and bower.json files. It is a C# web project. This doesn’t happen with other VS projects on my machine.
Restarting Visual Studio doesn't help, but restarting my whole PC does make the problem go away, for a while.
I fixed this issue by upgrading from Windows 7 to 10. I chose the option to keep my existing applications; Enterprise edition; it went smoothly.
Yesterday, I encountered the problem multiple times that Microsoft Visual Studio 2013 restart unpredictably when it loads very large C++ and C# solutions.
I researched Stack Overflow and found this particular article: Visual Studio 2013 hangs when opening a solution
which suggests deleting the suo files. However, when I tried that the problem persisted.
I also tried uninstalling and reinstalling Microsoft Visual Studio 2013 and still the problem persisted.
I then tried loading a smaller solution consisting of a C# solution and a C++ project and that succeeded in loading, compiling and linking.
I was wondering why I suddenly encountered this problem. Could the cause of the problem be related to the amount of 64 bit physical memory I have installed on my 64-bit desktop system? Alternatively, could it be due to a computer virus even though my desktop system has an antivirus package installed. We are tring to avoid reimaging the disk of my 64-bit desktop system and reinstalling all the software which could take 2 days to complete. Any help is greatly appreciated.
It's probably some plug-in misbehaving. You can try disabling them (Tools => Extensions and Updates) and experimentally determine which one is causing the issue.
If you want to go all-in, you can debug it:
Download and install WinDbg 32-bit
Run Visual Studio under windbg: windbg -g "%VS120COMNTOOLS%..\ide\devenv.exe" c:\my\solution.sln
Watch the incredible amount of debug info VS spews into
WinDbg
If Windbg breaks, inspect the stack - maybe some DLLs on it will clue you into which plug-in is the culprit.
Open file explore and past this command
'%AppData%..\Local\Microsoft\VisualStudio\12.0\ComponentModelCache'
Then remove 'ComponentModelCache' folder.
Restart the visual studio.
When i tried to created a WPF application it gets stuck on "Creating Project" and an error message occasionally pops up
"
Microsoft Visual Studio Express 2013 for windows desktop is waiting for an internal operation to complete. if you regularly encounter this delay during normal usage, please report this problem to Microsoft."
I've tried to search for answers and disable my antivirus but to no avail. Would appreciate any help.
I had the same problem while working on an ASP.NET project; the only thing that worked for me was building a new project and copying and pasting the code.
(It took a really long time to build the new project for some reason.)
Restart your VS and/or your PC. VS 2013 is incredibly faster than 2010 but still has many bugs.
I am using WinForms, Visual Studio 2013, .Net 4.5
When running my application through the Visual Studio Profiler, it works exactly the way it should and when running it through either Debug or Release mode, I face horrible freezing and repainting issues.
What is the difference between running your application in the Visual Studio Profiler vs. running in through the Release Mode?
Thank you in advance
Finally found the answer here:
Why does my program run way faster when I enable profiling?
When you run your application within Visual Studio, the debugger is attached to it. When you run it using the profiler, the debugger is not attached.
If you press F5 to run your program, even with the Release build, the debugger is still attached.
Since I was running my application through Visual Studio, I was seeing some really strange behavior such as slow repainting, freezing, etc. - I spent days chasing the usual suspects, double buffering, not invoking calls from background threads, missing locks, etc. and it turns out I was chasing a bug that wasn't there on a first place. Hope this saves someone hours or headache.