When I start debugging my web application either from Start with Debugging (F5) or attaching to the ASP.NET worker process it will load the assemblies from the application very slowly that I can individually read the names of them as they scroll through the status bar of VS2010.
When I start debugging I 开发者_JS百科see that MSVSMON.exe uses 50% CPU and locks at 50% clearly filling up a full core. Also seeing that this is described as Visual Studio Remote Debugging Monitor, I'm confused if this should even be used since I'm debugging everything local to my machine.
I am running my environment virtually connected by RDP if that could be related to this.
Host Machine: Server 2008 Enterprise R2 Dualcore Xeon 2.53ghz
Virtual Instance: Win7 Enterprise 6gb ram full processor allocation
Does this seem normal? Should MSVSMON even be running if I'm debugging locally?
Menu.Debug.DeleteAllBreakpoints
Worked for me.
Yes, msvsmon.exe will be used when you debug a 64-bit program. Since Visual Studio is completely 32-bit, the remote debugger is needed to bridge the divide.
There isn't any reason to assume that the slowdown is caused by it being a remote debugger. Working mightily to find and load the .pdb files would be likely. Or accidentally having the mixed-mode debugging option turned on so the debugger is also seeing all unmanaged DLL loads and finding symbols for them. These are just guesses of course.
Searching for symbols is often very slow at the start of debug, particularly if you have one of the remote symbol options configured, and have not set 'ignores' on the various DLLs which will not have symbols on MS servers.
These can be not only things like 3rd party components of your code, but also hooks DLLs injected by, for example, graphics drivers, so it's worth keeping an eye on what's trying to load.
Running Fiddler ( http://www.fiddler2.com/fiddler2/ ) while starting debugging will show you if symbols are being fetched remotely.
Even if VS is not explicitly set (In tools->options-debug) for remote symbol fetch, it will still follow the _NT_SYMBOL_PATH environment variable - check if that's set, and what it points to.
I had this same problem, though this solution didn't do it for me. In the end, I had to go into Tools->Options->Debugging->Symbols and uncheck the Symbol file (.pdb) locations as well as click the Empty Symbol Cache button. After that, debugging was much nicer.
For me the problem was I a had PUP (potentially unwanted program) installed which was slowing down the other processes. After a couple of times that MSVSMON was showing this behaviour, I got aware that the Cltmng.exe process (from Search Protect by conduit) was taking an unusual amount of CPU as well, removing it solved the problem.
精彩评论