I suggest you ...

Improve Visual Studio Call Stack walking performance

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Walking the call stack can sometimes be a slower operation when debugging. Do not slow down debug operations such as stepping when walking the call stack takes a long time

103 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
AdminVisual Studio Team (Product Team, Microsoft Visual Studio) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for the feedback, we are currently investigating what performance improvements we could make to give you a faster experience when debugging, particularly when the call stack walking is causing the slowness.

Kaycee Anderson
Visual Studio

See the following blog posts that offers more details on what settings and windows relate to this, and other tips and tricks for speeding up debugging in general. http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx

Andrew Hall,
Program Manager, Visual Studio Debugger


Sign in
Password icon
Signed in as (Sign out)
  • Mark Douglas commented  ·   ·  Flag as inappropriate

    Debugging a 32-bit java application that loads native C++ code. Native code loads managed classes that call into C# code.

    I debug the application by attaching to the running javaw.exe process.

    When I attach and debug 'native' only, everything is responsive - single stepping, entering breakpoints etc. are all fine.

    If I attach to the process and also enable Managed debugging, things go really badly. Entering a breakpoint and single stepping take over a minute each! Yes, pressing F10 to step over a simple statement takes over a minute to perform.

    The solution is to close the 'Threads' window, but I wish I didn't have to do this.

  • Floele commented  ·   ·  Flag as inappropriate

    Type of application: Mixed (C++/WPF/WinForms) x86 application written in C++ and C#, running under a native only debugger. I often have significant wait times for simple tasks like stepping (F10, F11) as long as the call stack window is visible. Often I don't need the call stack though. So it would be indeed very helpful if the window loaded asynchronously at least, but making it somewhat faster in general wouldn't hurt either.
    The managed debugger is much faster btw, I don't have any issues with the call stack there.

  • reader commented  ·   ·  Flag as inappropriate

    the following windows:

    Populating call stack information, Parallel Stacks Threads, Tasks, and GPU threads, the current stack frame
    Evaluating expressions in any visible watch windows
    Refreshing the contents of any other windows that could have changed while the application was running
    code editor
    Autos and Locals windows
    Windows that refresh
    Breakpoints and Disassembly windows

    and any window that will slow the debug experience, its better that it uses the MVVM way, of notifying them, or they are watching lists from the debug data, and not to hold the debugger till they finish their displaying of the items.
    while i don't mean to interfer in your work, it might be an easy change, plus when these windows run on their own thread, they will be faster.


Feedback and Knowledge Base