At least two or three times a day Visual Studio gets stuck (in a deadlock I suspect) and displays the spinning-toilet-bowl-of-death cursor and pops up the dreaded "Microsoft Visual Studio is Busy" notification in the notification area:
It used to be that when this happened Visual Studio would stay like that for hours (and possibly until the end of time itself or a power cut) unless I kicked it to the kerb with an "End Process" in task manager.
More recently I noticed another process always seemed to be lurking about whenever this problem arises - Microsoft.PythonTools.Attacher.exe - which is part of the Python Tools for Visual Studio project:
If I kill that process then Visual Studio manages to free itself from whatever deadly embrace it's got itself into and can continue on its way, and this is what I look out for every time VS does this.
Whilst I do have Python Tools for Visual Studio 1.0 installed, the projects I am working on are plain old ASP.NET MVC3 apps written in C#. I'm not using any Python code or libraries and often I only have one instance of Visual Studio running.
What I also observe is that this process doesn't always start/appear for whole development sessions, and when it does, it seems to start up an random times (i.e. it's not there for the first hour or two and then it magically appears in the process list in task manager), but when it does I know I'm going be in trouble at some point.
Does anyone know why this process seems to randomly start and why it's interfering with Visual Studio in such a dramatic fashion?
I'm running Visual Studio 2010 Premium SP1 on Windows 7 Ultimate x64 SP1.
When you do Debug->Attach to Process you'll see that VS displays a list of processes and along with them it displays the types of code that you can debug which are running in those processes. To get this information VS queries the various installed debug engines. So when we get queried we go and inspect a bunch of processes to see what's going on. If it's a 32 bit process life is easy - we can use various APIs to enumerate the modules and try and figure out if there's a Python interpreter in the process. If it's a 64-bit process life is a little tougher because we're running inside of VS and it's a 32-bit process. We can't use the APIs from a 32-bit to a 64-bit process so instead we spawn a helper process to do the work.
It sounds like this helper process is somehow becoming a zombie on your system. It'd be great if you could attach VS to it and send any stack traces back in a bug. But we should also provide some defense in depth and timeout if the helper process isn't responding.
Finally killing it should generally be safe, it's not doing anything stateful, and we'll start a new one when we need it.
If you never use Debug->Attach to Process for Python debugging there's probably a trivial file update to our .pkgdef file which I could track down and post which would make this problem go away entirely.
Related
I'm running a Python 2.7 server in Visual Studio 2013 (update 5) with PT4VS, Twisted, and P4V integration (I mention these details because they may be related to the lockup). Periodically Visual Studio freezes (but never goes white like most processes do) and becomes unusable for a minute or so. This is happening several times a day not just for myself but for our entire development team and, of course, it's really annoying.
I tried Googling for a solution but came up dry. What I'd like to know is, is there a way I can see what Visual Studio is doing during this locked time so I can maybe pin down what the issue exactly is.
The problem
When using Visual Studio 2013, Ultimate update 5, the IDE becomes very laggy (not running anything), and CPU spikes eating consistently around 30% up to 100% CPU.
Particulars (what I am doing when this happens)
This happens quite often and doesn't seem to be dependant upon any specific project. I have tried re-installing (fresh), as well as from scratch (format, reinstall windows, install ONLY visual studio + a very moderate suite of developer controls [2 well known companies (DevExpress, and Telerik)])
What is also very odd, is this happens even when developing a console application, although it takes much longer for this to occur.
The system I am running is more than adequate (according to their specs required), and Visual Studio is really the only application experiencing this lag + cpu spike issue.
(notice the cpu spike to 58%. this was also visual studio doing that in the background)
This is not a code issue, but an issue somehow with the IDE itself. What I am hoping for is a solution involving something that I may need to tweak / adjust / disable / etc which is contributing to this. As an aside, I really have no idea why there are so many handles open when Visual Studio is running. 91k seems quite excessive.
Another issue (pointing it out as it may be related), when publishing a project, after publishing, Visual Studio keeps automatically checking 'Click Once' when I have explicitly disabled it. This needs to be unchecked after every time I publish or else the next publish/compile/test run, results in an 'mscorelib' message complaining that the pdb doesn't exist, even though it does, and I have used it in other projects. What is frustrating about this problem is that I am telling it I don't want the project to be clickonce, and after it builds a non-click once project for publish, Visual Studio enables it effectively making this checkbox useless and wasting valuble time having to do this after each publish. Time, that adds up -- especially with the persistent lag.
I am confident I am not the only one who has experienced this due to reproducing this issue on a fresh and bare setup of both the operating system, and visual studio with nothing else aside from two popular component suites. As such, this is my attempt to reach anyone else who has experienced this, and if you did find a solution (or cause), to lend a hand to me.
I have problem with Visual Studio 2010 on Windows 7 64-bit. After some time of work VS starts consuming ~50% CPU and UI responding slows down. When I close VS then UI disappear but process stay.
When I forgot to kill those hung processes at the end of day, I will end up with numerous devenv.exe processes.
I have reinstall Visual Studio and reinstall Windows and ended up with the same problem... doesn't change anything. Please help. :/
Remove and/or uninstall all third-party Visual Studio add-ins and extensions. Disabling is not good enough.
Visual Studio 2010 relies heavily on graphics. Therefore:
Update your video driver.
Turn off "Enable rich client visual
experience"
Turn off "Use Hardware graphics acceleration if
available"
There are also temporary files that Visual Studio uses that may need to be cleared out.
Clear out your %temp% folder.
Clear out %AppData%\Local\Microsoft\WebsiteCache
Clear out %AppData%\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
Your project and solution user settings may be corrupt due to so many "crashes".
Delete .user and .suo files (you will lose the startup project, bookmarks, breakpoints, and other user settings specific to projects and solutions.)
Begin where you began before - it may seem overkill but this is the only way to be sure we are addressing everything short of hardware issues.
Reinstall Windows - make sure you are using a validly licensed copy, and patch the hell out of it before installing Visual Studio.
Note: I doubt it is a GPU driver issue, but it never hurts to use the most up to date driver and this is the place to do it right after a fresh OS install.
Install Visual Studio .Net 2010 but do not start it up. Let it get the frameworks installed fresh.
Use Windows Update to install the VS 2010 SP1 patch, and any/all patches for .Net frameworks.
Make an images for yourself right here so you have something to build from if you need to try this again. It will save you lots of time.
Fire up Visual Studio, and test your closing before installing anything else.
If it does not work here, there's likely some conflict between PC hardware and window OS, and you should try to find this symptom in other applications to get more info.
Here's what i would be looking for:
Does it happen EVERY TIME?
Does it happen after you debug your project ? does it happen for ALL projects?
Does it also happen when you don't load any projects? (simply start the IDE and wait).
Does it happen after a debug session of your application? maybe the application is not closed properly?
Do you have any other apps running at the same time that may cause this? try reproducing with a minimal set of apps/services running.
What are you doing exactly when it starts freezing ? anything in particular?
I would try to get 2-3 memory dumps at the time of hanging, post it here as well as to MSFT people. That would be a good start.
I'm experiencing some performance problems. When I edit a file, Visual Studio 2008 performs a background (on-the-fly) compilation and then, it updates the error list. During this time, the cursor in the file editor disappears, and the keys I press to move or type more character are buffered.
Once the background compilation is finished, the changes are reflected in the editor (1 - 2 seconds). Every time I edit a file, which happens often, this happens.
How can I fix this problem? If this is not possible, can I disable this automatic build?
I had an odd performance-related issue today. My Microsoft Visual Studio seemed to be taking far too long to perform even the simplest of operations. I Googled around and tried a few ideas that people had such as disabling add-ins or clearing Visual Studio’s recent projects list but those suggestions didn’t seem to solve the problem. I remembered that the Windows SysInternals website had a tool called Process Monitor that would sniff registry and file accesses by any running program.
It seemed to me that Visual Studio was up to something and Process Monitor should help me figure out what it was. I downloaded the most recent version, and after fiddling around a bit with its display filters, ran it and to my horror, I saw that Visual Studio was so slow because it was accessing the more than 10,000 folders in C:\Users\krintoul\AppData\Local\Microsoft\WebSiteCache on most IDE operations. I’m not sure why there were that many folders and moreover, wasn’t sure what Visual Studio was doing with them, but after I zipped those folders up and moved them somewhere else, Visual Studio’s performance improved tremendously.
The Windows SysInternals website has a number of other useful utilities for network management, security, system information and more. Check it out. I’m sure you’ll find something of value.
I have a very annoying issue with visual studio 2008 sp1 on windows 7 64 bit.
The software we are working on uses a client that connects to a windows service. so, when i do a debug, i debug on 2 processes, the client and the service.
When hitting a breakpoint on the service, and using F10, F11 for 20-30 times aprox, I get an "Visual Studio is busy doing an internal operation ..." message, after which the debugger throws me to another place. If I look at the call stack, there is a message "Evaluation of:". above it, the call stack where I currently am, and below it, there is the call stack where I was before the error occurred.
here is something similar: http://social.msdn.microsoft.com/Forums/en-MY/vsdebug/thread/4c30e3f4-587e-4f14-8cec-8663d268c55c
I tried installing latest updates, cleaning solution, deleting dll files, *ncb, *suo. nothing worked :|
It's not related to the wpf editor bug.
Thanks.
This is barely an answer, but I had the same problem with VS 2008 (updated to KB972221) running on 32-bit Windows XP.
The key seems to be running two instances of VS2008 at the same time.
I had a client/server setup and was running each of these executables via its own VS2008 instance. The server was multi-threaded, the client I think single-threaded.
Like you, I had set a breakpoint and was then F10 stepping through the code when I had the same experience of VS hanging for a while then dumping me elsewhere in the code following an Evaluation of: message in the call stack.
However, I changed to simply running the client executable on its own, with just the server running in debug mode with VS2008, and the problem never recurred (to date!).
So maybe the workaround is simply to stick to a single VS2008 session.