Tips for Debugging Threads
The Threads window applies to:
Visual Studio Edition |
Visual Basic |
C# |
C++ |
J# |
Web Dev |
Express Edition |
No |
No |
Yes |
No |
No |
Standard Edition |
Yes |
Yes |
Yes |
Yes |
Yes |
Pro/Team Edition |
Yes |
Yes |
Yes |
Yes |
Yes |
The following are some tips for debugging threads, as well as some known issues:
Tracing is a useful approach to debugging many bugs in multithreaded code. You can use tracepoints for this purpose. For more information on tracepoints, see How to: Specify a Tracepoint/Breakpoint Action.
You can use breakpoint filters to place breakpoints on individual threads. For more information, see How to: Specify a Breakpoint Filter.
Debugging a multithreaded application with a user interface can be difficult. Consider running the application on another machine and using remote debugging.
You can set the thread name in native code using the SetThreadName API, or in managed code using the Name property. For more information, see How to: Set a Thread Name (Managed) or How to: Set a Thread Name (Unmanaged). Thread names are especially useful for managed code, since you cannot identify threads by Thread ID in managed code.
Deadlocks in multithreaded applications are a particularly nasty type of bug.
When debugging native code, you can view the contents of the Thread Information Block by entering
@TIBin the Watch window or QuickWatch dialog box.When debugging native code, you can view the last error code for the current thread by entering
@Errin the Watch window or QuickWatch dialog box.When debugging mixed code with calls from native to managed code, the managed code runs in the same physical thread as the native code that called it. Suspending or freezing the native thread will also freeze the managed code.
You can use C Run-Time Libraries (CRT) functions for debugging a multithreaded application. For more information, see _malloc_dbg.