I suggest you ...

Make Debugging faster

It takes too long to begin debugging an application. It also takes too much time stepping through code in debug mode.

1,892 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Doug Turnure - msft shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

There are a wide variety of reasons that debugging can be slow which makes this particular item not directly actionable as it is too broad. Please read the following blog post which outlines various reasons debugging can be slow and provides links to more specific UserVoice items that are actionable (http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx).  If you encounter something that doesn’t have an existing UserVoice item please create a new one that is focused on a specific feature area for the debugger
Best Regards,
Andrew Hall
Visual Studio Debugger


Sign in
Password icon
Signed in as (Sign out)
  • Marián Špánik commented  ·   ·  Flag as inappropriate

    Also in Visual Studio 2010 the debugger was terrible slow when Show threads in source was turned on and many threads are created, spending about 25% of the time in one Win API function (I think it was GetFileAttributes), but I am not sure, whether or not was this fixed in later versions of Visual Studio.

  • Eugene commented  ·   ·  Flag as inappropriate

    Especially in mixed mode: its looks like it sends command to sun for each cpu instruction.

  • Iulian Radu commented  ·   ·  Flag as inappropriate

    It may be the case here since I'm using a library that's throwing a std::invalid_argument exception when trying to make an invalid cast. I am probably catching a couple of tens of millions of these.

    Thank you for the suggestion. I'll test is more thoroughly and try to get rid of the exception.

  • Steve Carroll [msft] commented  ·   ·  Flag as inappropriate

    Iulian, in many cases, when the application runs much slower under the debugger it is because the application is throwing many many exceptions. This turns out to be the cause in about half of all reported cases. Is it possible that is the case here? If you aren't throwing a bunch of exceptions, we'll need to get a trace. mail scarroll at Microsoft.

  • Iulian Radu commented  ·   ·  Flag as inappropriate

    I am trying to debug a 64 bit application. When ran outside the debugger it finishes in 22 seconds using all 4 CPU cores. When ran with the debugger attached it's running about 100 times slower. Instead of the usual 100% CPU consumption it has less than 1% CPU consumption and the msvsmon.exe application is eating a full CPU.

    Note that this is without any recompilation. The same program runs 100 times (not percent) faster when ran with the debugger detached.

    If I debug the 32 bit version of the same program it works reasonably fast. I can't make an apples to apples comparison though since the app uses about 16 GB of RAM and the 32 bit version is a simplified one, so it fits in RAM.

  • Dave Novak commented  ·   ·  Flag as inappropriate

    @mjohn -- you're probably right as I've only worked with native C++ in VS-2012. But I do give them credit for making improvements with 'native', as this was much slower prior to Update 1 of VS-2012.

  • ssjx commented  ·   ·  Flag as inappropriate

    After microsoft use .net framework, every software is very slow in my computer. sqlserver manage studio is slow, microsoft dynamic crm is very slow to startup, visual studio is very very slow. my copmuter often shoutdown by itself because the cpu's temperature is too height.

    @Dave Novak, you use native C++, not manage code, native is more faster.

  • Anonymous commented  ·   ·  Flag as inappropriate

    It's April 2013 and it seems like debugging a native Windows Phone 8 app on a HTC 8S is really slow. Takes like 3 seconds to step in one line. The emulator is lightning fast compared to this but I also have some issues with deployment on an ARM device compared to X86 so I can't use that for proper debugging anymore :|.

  • Dave Novak commented  ·   ·  Flag as inappropriate

    For me, debugging native C++, recent product updates to VS-2012 have significantly improved performance. Removing my votes for this now.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I am using VS2010 (V10.0.40219.1 Sp1 Rel).

    I am having issue:
    debugging is too slow (30+ seconds to step through onne line ) when "enable property evaluation and other implicit function calls"..

    please help me

  • Karbon commented  ·   ·  Flag as inappropriate

    I have the same problem, but switched to Forefox debugging everything works fast!
    I wonder what they use in MS ...

  • VS Debugger commented  ·   ·  Flag as inappropriate

    Hi Philippe, sorry to hear you're experiencing such a slowdown (and we appreciate the other feedback as well). Can you send me a mail so I can get more detail on your project? mariabl at microsoft. Looking forward to hearing from you.

  • Philippe commented  ·   ·  Flag as inappropriate

    I just noticed that under Visual Studio 2012 Release Candidate, debugging native code in a mixed-mode DLL is really slow. I have a class without ref modifier and as soon as I step into that function, debugging is order of magnitude slower and as soon as I am again in managed code, the debugger is fast again.

    There is a factor of more that 10x slowdown. It happen weitheir on the main executable properties (C# application) I enable the native debugger or not.

    Normally a few updates are done per seconds. When debugging that particular code, it take almost 5 seconds for each step. I have tried to close Intellitrace Windows and it does not help much. I have no breakpoint and only common debugging Windows opened (thread, stack, auto, local, watches).

    There are no valid reason that the debugger would be much slower when debugging native code in a mixed-mode application that it is with managed code.

  • Philippe commented  ·   ·  Flag as inappropriate

    Avoid slowing down C++ code too much while debugging (when using STL containers). Also improving Edit and continue to works in more cases (C++/CLI, C# lamba...) and permit edition even if Edit and continue cannot compile them would make debugging experience faster.

    And effectively, improving start time or stepping speed won't hurt even though in my case, it is generally not much a problem.

  • Dave Novak commented  ·   ·  Flag as inappropriate

    Steve, I sent you an email to (scarroll, not scarrolll). If you didn't get it, please contact me at dave.novak at xaviant dot com. Thanks.

  • Dave Novak commented  ·   ·  Flag as inappropriate

    I'm seeing this somewhat in both, though I think it's worse under VS-11, which is where I've been doing all of my debugging as of late. First breakpoint generally takes close to 30 seconds to respond after it hits and, from there, about 5-10 seconds to F10 between lines. Sometimes though it's much worse. It's very reproducible.

    I never had these problems using Visual Studio 2008.

  • Steve Carroll [msft] commented  ·   ·  Flag as inappropriate

    Dave, can you let us know if you are seeing this in Vs2010 or Dev11? we'd love to get a repro as that behavior is not typical or expected.

← Previous 1

Feedback and Knowledge Base