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."
From the following conversation I had with Kaycee Anderson and Andy Luhrs on Twitter:
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.
This feature was shipped in the 15.6 release of Visual Studio 2017. Please try out the feature and provide any feedback on the developer community.
Guy Cresci commented
I want to make a visual video about friends of all things and how that works , but I do not know the how or why.Invention starts with frustration .
Update: according to the latest Visual Studio Roadmap, additional support for this request is being worked on for Q2 2018: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2018-roadmap
Update: Visual Studio 2017 v15.3 now displays thread names set via the SetThreadDescription API for processes started within the debugger (but does not yet support showing them when debugging dump files). https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes
Update: an upcoming build of WinDbg will support showing (in dumps) the thread names set via the SetThreadDescription API. Great progress!
Update: an April 2017 update to the ""Thread Naming in Windows: Time for Something Better" article mentioned above indicates that the xperf/WPA tools now display thread names that were set via the SetThreadDescription() API. Great work, Microsoft Diagnostics Team!
Hopefully support for VS / WinDbg (including when analyzing user-mode crash dumps) is not far behind.