Sometimes I experience Visual Studio 2010 being very sluggish. I have some plugins, like ReSharper for example, that I think could be the culprit.
It would be nice if I could see the processes under visual studio to see what is using up all the CPU. Basically what I am looking for is a Task Manager just like the one in Google Chrome but for Visual Studio. I searched the internet and came up with nothing.
Unlike Chrome, Visual Studio does not use multiple processes. (Except when debugging applications)
Using Process Explorer you can double click on your devenv.exe process, then under the Threads tab you can inspect, suspend or terminate (I wouldn't recommend the latter) threads belonging to addons, for example, VAssistX threads generally have a start address somewhere in the va_x.dll region.
Related
I installed Visual Studio 14. Now I have a new app VsHub in the system tray / notification area. What is it? I tried clicking and right-clicking on it, it doesn't do anything.
According to Visual Studio Blog site (http://blogs.msdn.com/b/visualstudio/archive/2014/08/18/visual-studio-14-ctp-3-released.aspx?PageIndex=2&wa=wsignin1.0):
"The Visual Studio Hub is an executable that supports multi-tool
communication across the VS family of apps, service
composition/isolation, and data/compute outside of the Visual Studio
process."
I solved stopping the folliwing Windows service:
Visual Studio Standard Collector Service
After stop, my pc is returned to work correclty, without strange load.
I hope this help you.
I have a slightly more direct solution to this. It's relatively trivial to locate where VSHub.exe and its cohorts are on your hard disk. Just go into that directory, take ownership of all the .exe files contained in it, and for each of them use "Right Click" / "Properties" / Security, and add an ACL that denies execute permissions to everyone.
Problem solved. You will need to re-do this every time you update VS 2015, but on my low power laptop, I simply can't afford the resources to keep all these unnecessary tools running. VS 2015 runs just fine without them: I can edit, build and debug programs without any problems at all.
Sure, I may be missing some of the more esoteric features of VS 2015, but for my use case YAGNI
I feel pretty ridiculous having to ask this, but is there an easy way to close Visual Studio while it's debugging?
I'm debugging my application, and when switching to full screen it crashes. I am unable to alt-tab to visual studio to stop the debugger, and I'm unable to pull any other windows on top of the full screen application.
I can, however, see the start bar. I can right click on visual studio and click close, but it does nothing (same goes for the debugging application).
I'm unable to get the task manager to show in front of the full screen application.. However, I'm on Windows 8 and I've noticed the Metro interface still works (and all metro apps). If I could find a little command prompt metro app I'm sure I could get around this, but I'm unable to.
Is there an easier way to resolve the issue without having to restart my pc each time I crash?
Almost forgot to mention, I'm on Visual Studio 2013
Edit: Forgot to mention, I'm programming on-the-go on a laptop; I only have the one monitor for this situation
I found a solution:
I can toggle focus to Visual Studio via Windows' Alt-Tab hotkey. This won't bring up Visual Studio, though.
Usually the problem is an unhandled exception, which requires me to hit "break." Since I gave Visual Studio focus, I can hit enter to select break.
I then use the Shift+F5 hotkey to stop the debugger
You might be able to use Developer Command Prompt - see MDbg.exe (.NET Framework Command-Line Debugger) to debug and kill your process
Is it somehow possible to measure the CPU and/or IO requirements for all installed Visual Studio Addins / Extensions (VS 2012 / 2013)?
Concrete Problem: I have quite a lot of Extensions and Addins for Visual Studio 2013 installed and in general it runs smooth, just sometimes i experience ~5-10 sec spikes where VS just freezes. (Without any Addins or Extensions it doesn't happen).
Any idea how to find the problem?
If it reproduces often enough, you can just attach a debugger to Visual Studio and break in when something is going bad. Conveniently, Visual Studio is a debugger, so if you launch two instances in and in one go Debug > Attach to process, you can just attach to the other. When you hit the issue, break in (quickly) in the other and look at the main thread (it's labled in the threads window.) Look at the stack to see if there are any obvious offenders...
When VS freezes you can run ProcDump and then analyze the stack for an offending extension. Alternatively Process Explorer has a nice real time threads and stack monitor.
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.
A few days ago, the attach button in "Attach to process" dialogue became disabled in VS 2010 and VS 2008 likewise. At first I thought that it is just an extension I've installed in VS 2010 but then I noticed it is the same in VS 2008. The both VS's a re running in administrative mode and on Windows 7.
I looked around but I can't seem to find a solution to this.
If anybody has encountered an similar problem, a little help would do great.
Thanks upfront.
EDIT: Attached a picture of the dialogue!
Where it says
you should press 'Select' and ensure at least managed is ticked. (or choose automatic)
otherwise, the 'Attach' button will be disabled.
It could also be because there is already another debugger attached to the process - probably the currently running instance of Visual Studio but it may be another instance of Visual Studio, or another debugger entirely (such as WinDbg or a remote debugging session).
Check the "Processes" window (usually found under Debug -> Windows -> Processes) to see what processes Visual Studio is debugging.
Try stopping Visual Studio but don't close the process.
I have come across a weird situation under which Attach button was disabled. This was because of DebugDiag. Please refer the following thread for info.
I was trying to debug a windows service as described here and had the same issue. The solution was to run Visual Studio as Administrator and select to see processes from all users.