I suggest you ...

Make the debugger stick to the current thread instead of jumping around between threads!

Please, please fix this! Debugging multithreaded applications is hard enough as it is, without having to manhandle the debugger just so it does the obvious thing you want.

I'm sure everyone knows what I'm talking about. You're stepping through your function, and suddenly your instruction pointer jumps somewhere unexpected and none of the variable values make sense and you realize you're not in the thread you thought you were in. It's really tough or impossible to get back to where you were in the thread you cared about. Or you set a breakpoint two instructions down, and it may be hit by a completely different thread. Or you Ctrl-F10 to step to a point in your code a few lines down, and again you're in some other thread without warning.

There are only two tedious solutions currently:

a) Freeze all threads in the thread window except the one you care about. This leads to locking up many times, and it's a pain to unlock and continue where you started. Essentially you can thaw all threads, put a breakpoint after the line in your thread that's locked, and F5 over and over until that breakpoint is hit in the thread you care about.

b) Breakpoint filters: create a breakpoint, right click on the breakpoint, click Filter, and enter ThreadId = 7740 (your thread id from the threads window). This is hugely tedious, especially when your workflow involves setting and unsetting many breakpoints.

Suggestions:

1) Make sure F10, F11, Ctrl-F10, etc., which are intended to be stepping in the current region of code NEVER switch threads, unless an explicit breakpoint is hit on another thread! This involves setting the thread filter to the current thread on whatever internal breakpoint Visual Studio is setting to achieve the desired stepping functionality.

2) Ctrl-F9 (or similar shortcut) to create a breakpoint with the current thread as its filter.

These two changes would make debugging multithreaded applications sooo much better!

Thanks a lot for your attention.

340 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Steve Marton shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    Thank you for using Visual Studio and for your commitment to improving it. We are currently evaluating whether we will be able to address this suggestion in a future release. Thanks for capturing the pain points you feel when stepping through multithreaded applications while debugging. We will be providing an update soon.

    Additionally, I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread. If you have other breakpoints in your application and another thread hits one, then you will be debugging in the mixed thread state as described in this item.

    Kaycee Anderson
    Program Manager, Visual Studio

    18 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Ed Nafziger commented  ·   ·  Flag as inappropriate

        I voted 3 times for this. Absolutely must have. However, I do have a concern as to what I would want to happen if the code I am stepping into starts a new Task. If that task spawns the method or lambda in a new thread, I think I would want to "follow" the execution, so in that specific example I would want to jump into the new thread. But otherwise I think 99% of the time I want to stay in the current thread.

      • Richard Vondráček commented  ·   ·  Flag as inappropriate

        I have a feeling that with the async await model the whole thing gets even more complex. I also have a feeling that statement:

        " I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated."

        it not true in many cases. My bet is that the "current" thread is maybe running some continuation after some await in totally other awaitable context (possibly the same thread) but my brain is lost ;-)

        I absolutely understand that this is no trivial development at all. And for modern ASP Net applications it is quite critical.

        And I wanted to state that maybe we need more than current thread locked debugging. Maybe we need current "awaitable context" locked debugging.

      • Jim Balter commented  ·   ·  Flag as inappropriate

        " I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated."

        You have no idea how your own software works. When I press F10 or F11, my application starts running. That should not be possible in a debugger that functions correctly.

      • DARK Guy commented  ·   ·  Flag as inappropriate

        I can't believe we're in 2017 and this functionality hasn't been worked on yet. To me, it seems that MS just fakes listening to its users, because it doesn't as it can clearly be evidenced here.

      • Bob Bryan commented  ·   ·  Flag as inappropriate

        I too agree that the proposed functionality is absolutely critical to debugging multi-threaded code. Have you ever tried to debug multi-threaded code and watch the instruction pointer stay on the same line (which causes one to think, gee - did I press the F10 key hard enough?), jump forwards, as well as jump backwards every time the step key is pressed? This is all due to multiple threads running thru the code. The debugger needs to provide a little bit of extra functionality that allows developers to control how multiple threads are run to make debugging the code easier, and without having to freeze each and every thread and then unfreeze those same threads later on - which can be quite time consuming.

        This is what I would suggest:

        Provide a default multiple-threaded debug mode that single steps thru the code without switching to a different thread. That makes the code easier to debug by single-stepping through the code. As others have pointed out, that is how IBM and others do it. There are two sub-modes of this mode. The first sub-mode, the default, stops all other threads from executing through the code, which in effect forces the code to be single-threaded at that point. It should do this by freezing the other threads. The developer would have the option of unfreezing specific threads later on if he should want to debug 2 or more threads running thru the code. The 2nd sub-mode allows other threads to run through the code, but only threads from the thread of interest are allowed to hit breakpoints.

        The non-default multiple-thread debug mode allows multiple threads to run through the code, as is the case now. Both the mode and sub-mode should be able to be changed via a context menu or some hot-key combination at any time while debugging.

      • stu commented  ·   ·  Flag as inappropriate

        This has been broken since the dawn of time. IBM's OS/2 debugger worked correctly, kdbg works correctly, xdbg or whatever AIX's full screen debugger was called worked correctly, eclipse with gdb works correctly, msvc is the only debugger I've ever used that has this crazy random thread context switching problem, and it has had it at least since this product was called visual c++. If they haven't been able to fix it by now, likely they're never going to. Makes you wonder how MS developers debug their software, obviously they don't use their own tools or they'd have fixed this problem by now.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I find current behavior not user friendly. There should be a flag "stick to current thread" which will automatically check $TID to match current thread ID. It is annoying to be throwned into other thread while you stepping across the code (in particular, it is hard to debug web servers that can serve parallel requests).

      • Klaus commented  ·   ·  Flag as inappropriate

        James wrote:
        "This is broken then. At least it was in VS2012 (the version I'm currently stuck using). If you're single stepping through code that is being executed in parallel across multiple threads, there's no guarantee which thread you'll end up in next."

        I can verify this behavior for the latest VS 2015 Community Edition and it annoys me to death. When I remote debug websites, I get 5-10 second VS hang ups when I suddenly step into my handler code.

        Funny enough: I almost forgot about this problem, but then I got a new PC and recognized the massive delay while debugging. I checked my old client and found out, that it stays in the first thread I step into. I assume this change comes from a patch I installed years ago for my VS 2008 SP1 which had severe debug problems. I'm not sure, but I think it was this one: https://support.microsoft.com/en-us/help/957912/updates-for-visual-studio-2008-sp1-debugging-and-breakpoints.

        Please fix this, it's such a senseless time killer! A "Stay in first/current thread" button/option would be nice and can't be that difficult to implement.

      • James commented  ·   ·  Flag as inappropriate

        "I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread."

        This is broken then. At least it was in VS2012 (the version I'm currently stuck using). If you're single stepping through code that is being executed in parallel across multiple threads, there's no guarantee which thread you'll end up in next.

      • Michael Zhang commented  ·   ·  Flag as inappropriate

        Any Updates. This feature is going to be increasingly useful as multi-threading applications are exploding these days..

      • Anonymous commented  ·   ·  Flag as inappropriate

        I vote for this request! do you have any update will this be implemented by Visual Studio team ?

      • Radim Brixí commented  ·   ·  Flag as inappropriate

        I would recommend to implement another step into and step over debugging feature that would step only in one thread ignoring all steps in all other currently running steps that one would have to debug through as now. I wouldn't change the feature at all, I would just add a new one.

      • Marián Špánik commented  ·   ·  Flag as inappropriate

        If I recall correctly it had been a pain to debug a C++ code in #pragma omp parallel for as it kept switching between OpenMP threads. I am not sure whether the issue was fixed or is still present.

      • Steve Marton commented  ·   ·  Flag as inappropriate

        I've noticed one particular case where the debugger fails to step normally.

        In VS 2012 I placed a breakpoint in a function that is called by many threads.
        Broke on one thread, disabled the breakpoint, and started stepping through.
        Occasionally the instruction pointer would jump back to the location of the old breakpoint in another thread when that thread hit that instruction. This kept happening over and over as new threads hit that instruction, making it really hard to step through my thread of interest. I have a lot of these threads. This is a common scenario when you're running the same code wide across multiple cores.

        It seems that the breakpoint was not correctly disabled on all the threads when I intended to disable it.

        This might be the source of most of the headache I mentioned in suggestion 1). The rest of the time stepping seems to work reasonably, mostly.

        Suggestion 2) is still super important, even if 1) is fixed!

      Feedback and Knowledge Base