Add a thread name property for native threads to support attach and minidump debugging
As of today, setting native thread names involves raising an SEH exception with data that includes the name one wishes to give to the current thread.
This only has an effect if Visual Studio is connected as debugger. If not, the thread name seems to be lost forever.
One of our common debugging use cases is using minidumps. The thing is, our executables may run tens of threads with similar callstacks. Sorting out which threads are of interest without names is hard.
Suggestion: setting a thread name should be a system feature that is connected to minidump capture; minidumps should include thread names, and the Visual Studio debugger should be able to retrieve and display the thread names.
Thanks for taking the time to share this suggestion. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to archive it. We think this is a great idea and have started working with our partner teams to support thread naming in a different way than the Exception based protocol we use today. We will look to leverage that in the future for any investments we make to debugging multithreaded code.
Visual Studio Team
7 commentsComments are closed
I've filed a followup request for Microsoft to add support for the new API to minidumps as well as their debuggers and analysis tools. Please vote for that issue if you agree. https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/17608120-properly-support-native-thread-naming-via-the-sett
Following up to my last question, Kaycee was kind enough to provide more details on Twitter: https://twitter.com/korkyplunger/status/804721931698184192
Looks like SetThreadDescription is the recommended API going forward, but there's not yet any support for embedding this in dumps, and no debuggers or other tools yet take advantage of it (though it's on the roadmap).
Glad to hear there's some work in progress on this issue. Is it possible to give us a summary of the planned approach, so we can consider it and provide feedback? For example, it's critical for us to be able to extract the thread names from both dumps as well as Windows Performance Analyzer sessions and Visual Studio profiler output.
Agreed. At best, currently thread naming involves taking the MSDN sample and fixing it's issues, and then putting a wrapper round it to either additionally: log thread names and ids at creation time to persistent storage AND/OR writing to ::OutputDebugString for it to appear in SysInternals dbgview (for example), as I have done.
Bruce Dawson commented
See also this post discussing the same idea:
Ofek Shilon commented
Native threads have no slot to store a name string in the TEB - modifying the TEB is not a debugger feature, and plainly cannot ever happen. The closest you can do is save thread name pointers in TLS storage, and customize your dump taking process as suggested by @Marc Therrien.
To bypass this limitation we add threads names in the _USER_STREAM_INFORMATION section of the minidump. When the minidump is opened with Visual Studio, we launch an AddIn to retrieve stored threads and change their names in the thread window. However, the function used (EnvDTE90.Thread2.DisplayName) to change names is very very slow (immediate in code but terrible refresh time in Visual Studio), and the time is proportional to the number of names (1 minute for 40 names).
It would be very useful to have at least a faster way to change names in DTE API. Or fix the Visual Studio slowdown when changing a bunch of thread names.
Thanks and regards,