Export (0) Print
Expand All

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 @TIB in the Watch window or QuickWatch dialog box.

  • When debugging native code, you can view the last error code for the current thread by entering @Err in 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.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft