1. Requirements

Windows 7 Enterprise Edition (32-Bit OS)
.Net Framework 3.5 SP1
Compiler Version 3.5.30729.4918
Visual Studio 2008 Version 9.0.30729.1

2. Purpose

Sometimes it can be cumbersome to debug multi-thread applications, trying to use very simple features such as “Step Into” (F11), “Step Over” (F10) and “Step Out” (Shift + F11) can easily mess your mind up. Most developers that use Visual Studio as their primary IDE, are not aware of its multi-thread debugging features. So, I decided to post several tips and tricks that can be very handy while debugging this kind of applications.

3. Demo

Before we begin, a sample multi-thread application will be necessary to apply the techniques throughout this post. It is a simple Console Application that creates two threads, Thread A and Thread B, which will count from 0 to 100, printing “Thread A - 0”, “Thread A - 1”, and so forth. Take a look at the following illustrations:

using System;
using System.Threading;

namespace MultiThreadDebugging
{
    class Program
    {
        static void Main(string[] args)
        {
            Thread threadA = new Thread(Execute);
            threadA.Name = "Thread A";
            threadA.Start(threadA.Name);

            Thread threadB = new Thread(Execute);
            threadB.Name = "Thread B2";
            threadB.Start(threadB.Name);

            Console.ReadLine();
        }

        static void Execute(object threadName)
        {
            for (int i = 0; i < 100; i++)
            {
                Console.WriteLine(threadName + " - " + i);
            }
        }
    }
}

The following illustration shows the expected output from the application:






Set up a break point on line 25 and hit F5 to run the console application.






After the execution stop on the breakpoint, click on menu Debug > Windows > Threads or press CRTL + D + T to exhibit the Threads window. Below, you will find an illustration of this window:






As you can see in the above picture, the Main Thread is differentiated with a green square and the current thread is marked with a yellow arrow. Also, other threads appear on the list, which are loaded by Visual Studio and CLR. Thread B does not appear in the thread list because it is waiting to execute. However, there is an easy way to show where are all the threads hanging around. I order to do that, click on menu

Click on the Show Threads in Source button located on Debug toolbar:






Next, you will see that an icon composed of two waves appear on the left side of the row numbers indicating where the Main Thread execution is hanging. Also, the line is highlited, in this case, with a gray background color. That is why Thread B does not appear on the list, it did not started yet.






Now, that the basics are covered, let’s see how can tell the Debbugger to stop only when the executing thread is Thread B, which is very handy while executing very common features such as Step Into, Step Over and Step Out.

Stop running the console application and right click the breakpoint and choose Filter option:






Using the ThreadName instead of ThreadId is most of the time better, because the thread id is provided by the operational system kernel and changes among. Hit F5 run the console application again and notice that while debugging the breakpoint will stop only for Thread B.






Another feature that I would like to point here is breakingponts acting like trace. Let’s suppose that you would like to trace your application, a very powerful and common way is to instrument your with the trace mechanisms of the .NET platform. However, sometimes, you only need a simple information, so it’s possible to achieve the desired result without having to change your code.

Rick click the breakpoint, choose When Hit option and set the “Print a message” with $TNAME = {i}, where $TNAME will print the thread name (Thread A or Thread B) and {i} will print the i variable value. Take a look at following illustration:









Last tip, if want to save the Output Windows content on a text file just press CTRL + S.

4. Resources

There is more content regarding breakpoint and tracepoints on MSDN http://msdn.microsoft.com/en-us/library/ktf38f66.aspx.