I suggest you ...

Properly support native thread naming via the SetThreadDescription API in minidumps, debuggers, and analysis tools

This is a request to embed support for the SetThreadDescription API to critical Microsoft debugging and analysis tools: the Visual Studio Debugger, WinDbg, WPA, and mini-dumps.

A different User Voice request, titled "Add a thread name property for native threads to support attach and minidump debugging" was recently closed, with the rationale that Microsoft was working on a new approach to thread naming. This approach would be different from the current exception-based approach, and "[Microsoft] will look to leverage that in the future for any investments we make to debugging multithreaded code."

https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5792677-include-and-use-native-thread-names-in-minidumps

From the following conversation I had with Kaycee Anderson and Andy Luhrs on Twitter:

https://twitter.com/korkyplunger/status/804721931698184192

I learned that the SetThreadDescription API is is this foundation. However, this is currently not for production code because:

1) Neither Visual Studio nor WinDbg currently support displaying the names set via this API

2) They are not yet embedded into mindumps (https://twitter.com/aluhrs13/status/805999786868359168), and therefore it's not currently a viable solution to the problem of post-mortem debugging a heavily multithreaded application from a minidump.

3) There's no support for displaying these thread names in critical analysis tools such as Windows Performance Analyzer

As Bruce Dawson stated in his article "Thread Naming in Windows: Time for Something Better" (https://randomascii.wordpress.com/2015/10/26/thread-naming-in-windows-time-for-something-better/) there is precedent for adding various types of instrumentation to the the OS:

"Microsoft could implement my naive solution and add support to the tools that I care about – they own them all. More importantly, Microsoft could also do it at the kernel level, which would could make it handle thread termination.

There is precedent for adding this sort of instrumentation to the OS. The gflags tool allows developers to enable tracking of heap allocations, object creator type tracking, and much more. It is time for Microsoft to add thread names as a gflags option. The kernel could catch the existing exceptions, the debuggers and profilers could be updated to query the kernel’s thread-name database, and the world would be a better place."

If SetThreadDescription() is indeed the annointed API going forward, please support it properly and deeply within minidumps, debuggers, and analysis tools. Supporting this API across the tool suite would greatly enhance the debugging experience for anyone who debugs applications with significant numbers of threads.

206 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Christopher Kline shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...

      Feedback and Knowledge Base