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.
Program Manager, Visual StudioSteve Marton commented
Any feedback at all on this issue?Steve Marton commented
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!Steve Marton shared this idea ·
105 votesSteve Marton supported this idea ·