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 StudioKlaus supported this idea ·Klaus commented
"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.