“Step over” when debugging multithreaded programs

问题:

One thing that annoys me when debugging programs in Visual Studio (2005 in my case) is that when I use "step over" (by pressing F10) to execute to the next line of code, I often end up reaching that particular line of code in a totally different thread than the one I was looking at. This means that all the context of what I was doing was lost.

How do I work around this?

If this is possible to do in later versions of Visual Studio, I'd like to hear about it as well.

Setting a breakpoint on the next line of code which has a conditional to only break for this thread is not the answer I'm looking for since it is way too much work to be useful for me :)

回答1:

I think there is only one answer to your question, which you have discounted as being 'way too much work.' However, I believe that is because you are going about it the wrong way. Let me present steps for adding a conditional breakpoint on Thread ID, which are extremely easy, but not obvious until you know them.

1. Stop the debugger at a point where you are in the correct thread you want to continue debugging in (which I would guess is usually the first thread that gets there).

2. Enter $TID into the watch window.

3. Add a break point with the condition $TID == <value of $TID from Watch Window>,
   Example: $TID == 0x000016a0

4. Continue Execution.

$TID is a magic variable for Microsoft compilers (since at least Visual Studio 2003) that has the value of the current Thread ID. It makes it much easier than looking at (FS+0x18)[0x24]. =D

That being said, you can get the same behavior as the debugger's One-Shot breakpoints with some simple macros. When you step over, the debugger, behind the scenes, sets a breakpoint, runs to that breakpoint and then removes it. The key to a consistent user interface is removing those breakpoints if ANY breakpoint is hit.

The following two macros provide Step Over and Run To Cursor for the current thread. This is accomplished in the same manner as the debugger, with the breakpoints being removed after execution, regardless of which breakpoint is hit.

You will want to assign a key combination to run them.

NOTE: One caveat -- The Step Over macro only works correctly if the cursor is on the line you want to step over. This is because it determines the current location by the cursor location, and simply adds one to the line number. You may be able to replace the location calculation with information on the current execution point, though I was unable to locate that information from the Macro IDE.

Here they are and good luck bug hunting!!

To use these macros in Visual Studio:
1. Open the Macro IDE ( from the Menu, select: Tools->Macros->Macro IDE... )
2. Add a new Code File ( from the Menu: select: Project->Add New Item..., choose Code File, and click Add )
3. Paste in this code.
4. Save the file.

To add key combinations for running these macros in Visual Studio:
1. Open Options (from the Menu, select: Tools->Options )
2. Expand to Environment->Keyboard
3. In Show commands containing:, type Macros. to see all your macros.
4. Select a macro, then click in Press shortcut keys:
5. Type the combo you want to use (backspace deletes typed combos)
6. click Assign to set your shortcut to run the selected macro.

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics

Public Module DebugHelperFunctions

    Sub RunToCursorInMyThread()
        Dim textSelection As EnvDTE.TextSelection
        Dim myThread As EnvDTE.Thread
        Dim bp As EnvDTE.Breakpoint
        Dim bps As EnvDTE.Breakpoints

        ' For Breakpoints.Add()
        Dim FileName As String
        Dim LineNumber As Integer
        Dim ThreadID As String

        ' Get local references for ease of use 
        myThread = DTE.Debugger.CurrentThread
        textSelection = DTE.ActiveDocument.Selection

        LineNumber = textSelection.ActivePoint.Line
        FileName = textSelection.DTE.ActiveDocument.FullName
        ThreadID = myThread.ID

        ' Add a "One-Shot" Breakpoint in current file on current line for current thread
        bps = DTE.Debugger.Breakpoints.Add("", FileName, LineNumber, 1, "$TID == " & ThreadID)

        ' Run to the next stop
        DTE.Debugger.Go(True)

        ' Remove our "One-Shot" Breakpoint
        For Each bp In bps
            bp.Delete()
        Next
    End Sub

    Sub StepOverInMyThread()
        Dim textSelection As EnvDTE.TextSelection
        Dim myThread As EnvDTE.Thread
        Dim bp As EnvDTE.Breakpoint
        Dim bps As EnvDTE.Breakpoints

        ' For Breakpoints.Add()
        Dim FileName As String
        Dim LineNumber As Integer
        Dim ThreadID As String

        ' Get local references for ease of use 
        myThread = DTE.Debugger.CurrentThread
        textSelection = DTE.ActiveDocument.Selection

        LineNumber = textSelection.ActivePoint.Line
        FileName = textSelection.DTE.ActiveDocument.FullName
        ThreadID = myThread.ID
        LineNumber = LineNumber + 1

        ' Add a "One-Shot" Breakpoint in current file on current line for current thread
        bps = DTE.Debugger.Breakpoints.Add("", FileName, LineNumber, 1, "$TID == " & ThreadID)

        ' Run to the next stop
        DTE.Debugger.Go(True)

        ' Remove our "One-Shot" Breakpoint
        For Each bp In bps
            bp.Delete()
        Next
    End Sub


End Module

Disclaimer: I wrote these macros in Visual Studio 2005. You can probably use them fine in Visual Studio 2008. They may require modification for Visual Studio 2003 and before.

回答2:

You can freeze a different thread or switch to another thread using the Threads debug window (Ctrl + Alt + H).

回答3:

The simple way to debug one particular thread is to freeze all other threads from the Threads window.

回答4:

[Ctrl+D, T] or [Ctrl+Alt+H] - Opens the Thread Window (used to monitor, freeze and name threads)

The thread window allows you to select if you want to show the location of the other threads in visual studio. That is a good reminder to me that the current thread I am debugging is not the only one in play. Hovering over the thread marker gets you the threads name and id.

More tips found at: http://devpinoy.org/blogs/jakelite/archive/2009/01/10/5-tips-on-debugging-multi-threaded-code-in-visual-studio-net.aspx

回答5:

Apparently, Visual Studio 2010 only switches to other threads if you press F10 when the debugger had to break in that thread before or if a breakpoint is set which will be hit in this thread.

I used the following code to test the behavior:

class Program
{
    static void Main(string[] args)
    {
        var t = new Thread(new ThreadStart(Work));
        t.Start();

        for (int i = 0; i < 20; i++)
        {
            Thread.Sleep(1000);
            Console.WriteLine("............");
        }

        t.Join();
    }

    static void Work()
    {
        for (int i = 0; i < 20; i++)
        {
            Thread.Sleep(1000);
            Console.WriteLine("ZZzzzzzzzzzzzzzz");
        }
    }
}

If you just stept to the program or add a breakpoint in the Main() method, hitting F10 only steps through the code from the main thread.

If you add a breakpoint in the Work() method, the debugger steps through both threads.

This behavior of Visual Studio makes sense but it all seems like an undocumented feature to me...

回答6:

I recently had the same problem of debugging only a certain thread. While I won't discount the above answer as very comprehensive and valuable (and wish I had found it 2 days ago) - I implemented the following to help "everyday" troubleshooting.

This idea is only a simple workaround when running multiple instances of the same class in multiple threads - which our application is doing at all times.

We initialize all class instances with a unique ID or Name, so we know how or why the instance was created. Then, when we need to debug a specific instance (i.e. thread) - and not freeze other threads, we add the following:

if (instance.ID == myID)
{
    // Assert BreakPoint
}

In our case, we establish fixed ID's, so we know the ID we want to troubleshoot when we have an issue.