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.
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,