Share via

Debugging Multi-threaded Applications: Some Tidbits

  • Article

I was lamenting that we haven't really done terribly much to make multi-threaded debugging easier in say the last decade and I was fortunate enough to be able to have a conversation with Brain Crawford about it.   Brian is a long-time friend an colleague, we worked on the VC++ debugger years ago, he's the lead architect for all things debugger these days.  Anyway, he gave me this succinct information about VS2010 and was kind enough to allow me to share it with you all.

In his own words Brian writes:

While I agree that there is more we could do to make multi-threaded debugging even better, VS 2010 has a number of features that help with multi-threaded debugging for both native and managed code:

  • Stepping has affinity with the thread being stepped. Whatever thread is active (has the yellow IP marker next to it in the Threads window) will be stepped and no other threads will complete the step started on that thread. However, by default, breakpoints will fire on any thread, so you can step one thread and hit a breakpoint on another.
  • Any time you started execution (step or go) on a thread and execution stops on another thread (e.g. you hit a breakpoint or exception), there will be a small blue marker overlaid on the yellow IP arrow shown in source code to indicate a thread switch occurred.
  • Per thread breakpoints can be created by setting a breakpoint and then right clicking on the breakpoint glyph and choosing Filter. In the Filter dialog, you can enter an expression like “ThreadId=5” to restrict the breakpoint to a particular thread.
  • The threads window in VS 2010 has a number of features to help manage multiple threads:
    • Threads can be flagged manually so it’s easy to find the subset of threads you’re currently working with.
    • Threads can be flagged according to just my code or by particular modules.
    • Call stacks for each thread can be viewed by hovering over the Location cell or the call stack can viewed inline by expanding the Location cell (so multiple call stacks can be viewed simultaneously).
    • Threads can be grouped according to different criteria, such as process, name, category, flag, etc.
    • Threads, including the call stacks for each thread, can be searched using the search box in the window. For example, if you’re looking for all threads with Foo on the stack, enable Search Call Stack, and type Foo in the Search box.

For multiple threads running the same/similar workload, the new Parallel Stacks view is very useful. While primarily designed for use with the parallel libraries and runtime, it can also be useful for traditional multi-threaded debugging. It consolidates threads with common stacks into a “cactus stack” view. I don’t know the kinds of scenarios you’re debugging, but it might be worth checking out. Here’s some additional info on this view: https://msdn.microsoft.com/en-us/library/dd998398.aspx

Thank you Brian, and please get a blog soon :)

Comments

  • Anonymous
    June 07, 2010
    These posts of yours are always reinvigorating. Every time I feel like doing something else, or moving to another platform, I read up on your posts and realise that it's always alright to stick with Microsoft technologies and tools. I've been a fan of Microsoft's tools (especially Visual Studio), and all of my expectations are met, time after time, every time. Kudos to the entire Visual Studio team for bringing out such great products one version after another.