Visual Studio, debug one of multiple threads

I have an application with 4 threads working the same code. However, when I step it jumps between the different threads. How can I lock it to one thread so the other threads are ignored for debugging?

Yes.

In the Threads window (Debug -> Windows -> Threads) right-click the thread you want and select "switch to thread".

You can also choose "freeze" on the threads you don't want to debug in order to keep them from running. Don't forget to "thaw" them if you expect them to do work, however.

Further reading.

Single stepping through a single thread seems to be mostly fixed in VS 2012 (with some caveats you can see in my link below). Breakpoints are a pain.

Freezing and thawing threads is the usual workaround, as previous answers have stated, but it's tedious, and it can cause hangs when your thread waits on another thread that's frozen. These can be tough to recover from without losing your place in your thread of interest.

Another useful workflow is to apply a thread filter on your breakpoints, also stated in some of the answers:

Create a breakpoint, right click on the breakpoint, click Filter, and enter ThreadId = 7740 (your thread id from the threads window).

This can be very tedious.

My suggestion to Microsoft is to fix single stepping (and variations of it) to never switch threads unless an explicit breakpoint is hit in another thread. They should also add a shortcut (maybe Ctrl-F9) to create a breakpoint with the current thread id as its filter. This would make the second workflow much more convenient.

Vote up the suggestion if you agree this would be useful, or add your own suggestions:

https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/8543248-make-the-debugger-stick-to-the-current-thread-inst

You could also put a conditional breakpoint in your code and put the thread.Id == [someValue] or Thread.Name == "[Somename]" in the breakpoint condition...

A much quicker workaround exists for simple cases - see comments in Steve's link.

> 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

So in my case once the various threads started hitting my breakpoint I just hit Continue a few times until I identified the call I was looking for - then removed the breakpoint and stepped through the rest of the code while remaining on the same thread without interference from the rest of them.

This obviously becomes a problem if you have multiple breakpoints that you want to keep, etc. - but again for simple cases this is much easier to do.

This strongly resembles a very similar problem in Visual Studio 2008 SP1. It was fixed with a post-SP hotfix. But there's other evidence that the hotfix didn't get incorporated into the code base, this feedback item was also a problem. It isn't that unusual for hotfixes to not get integrated back.

There isn't a feedback item that exactly describes your problem, at least that I can find. I'd recommend you file one. Given the usual trouble with reproduce bugs like this, I'd strongly recommend you include a reproduction project that exhibits this problem with instructions on how to reproduce the issue.

There is a workaround of sorts for your issue, you could go into Debug + Windows + Threads, right-click the threads you don't want to debug and select Freeze. Don't forget to Thaw them later.

These bugs were fixed again in Visual Studio 2010 Service Pack 1.

> 5. Step through one single thread without jumping around > > How often are you debugging multithreaded code, when you hit your > first breakpoint, take a step, and then suddenly you are stopped with > the yellow arrow on another thread? The unexpected behavior comes from > the breakpoint still being set and consequently being hit. By default, > the debugger will stop on a breakpoint any time it is hit. This means > that when you take a step, all threads are allowed to run, and one of > your running threads hit this breakpoint before the step completes on > your current thread. Next time you get in this situation try this: > > > > 1. Disable or delete the breakpoint that has been hit by the new thread the debugger switched to. > 2. Press Continue (F5) > 3. Observe how your first initial step on that first thread completes and now is the active debugging context. > 4. Since your breakpoints are deleted or disabled, you can continue stepping on that single thread without interruption.

7 lesser known hacks for debugging in Visual Studio

I'm Using Visual Studio Professional 2017, and I use the Threads window to selectively freeze and thaw threads. Usually I have multiple threads of the same code and I only want to freeze them, not others. I actually like the MS Threads window because I can select a subset of threads to freeze. I group the threads by name and can then freeze all the ones running the same code as I am debugging while letting the remaining threads run. I tried using the Erwin Mayer extension, and it worked very well, but it freezes all threads except the one I am running, and I sometimes get into a situation when debugging does not hit the breakpoint I think it should, then because all of the other threads are stopped and the application seems halted. Hitting the pause button, and unfreezing threads in the threads window fixes that issue.