7

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 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?

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258
  • I've had no performance problems with debugging, locally or remotely, web or normal process. VS is running on x32 for me with the remote machines running x64. – Jonathan Allen Jul 14 '10 at 19:07

5 Answers5

19

Menu.Debug.DeleteAllBreakpoints

Worked for me.

SliverNinja - MSFT
  • 31,051
  • 11
  • 110
  • 173
Jay Borseth
  • 1,894
  • 20
  • 29
  • I don't know why but this worked for me also. From debugging to finished web page went from 20 sec to 3 sec. But I want to know why! I only had a handful of breakpoints inside the same project (that never got hit). – Sire Jan 26 '11 at 12:29
  • There is most definitely a bug in VS2010 about this and break points that it loses or something. – Chris Marisic May 13 '11 at 17:34
  • 2
    If you add breakpoints by name (break to function) the debugger needs to scan all the symbols for every dll loaded to check whether anything matches given name. that takes all the time, not a bug. – Cosmin Onea May 24 '11 at 14:06
  • 1
    Conditional breakpoints have to be evaluated every time the instruction pointer encounters the location, which I'm guessing means context switches galore. They tend to be horrendous for performance even when simple. – Joshua A. Schaeffer Jul 09 '14 at 17:36
4

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
3

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.

tstone2077
  • 514
  • 4
  • 13
  • 1
    Very valid point, this isn't the exact scenario I describe where I see it loading MY assemblies at the speed of 1 per second or so, but if you see it loading assemblies you don't own that will dramatically reduce debug entry. The ability to debug into .NET code with symbol source is awesome but the awesomeness only should be turned on for specific needs then immediately turned back off. – Chris Marisic Jan 28 '13 at 16:25
3

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.

Will Dean
  • 39,055
  • 11
  • 90
  • 118
0

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.

f.cipriani
  • 3,357
  • 2
  • 26
  • 22