I suggest you ...

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.

167 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Raphaël Saint-PierreRaphaël Saint-Pierre shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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.
    Kaycee Anderson
    Visual Studio Team


    Comments are closed
    • Christopher KlineChristopher Kline commented  ·   ·  Flag as inappropriate


      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.

    • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

      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.

    • Ofek ShilonOfek Shilon commented  ·   ·  Flag as inappropriate

      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.

    • Anonymous commented  ·   ·  Flag as inappropriate


      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,

      Marc Therrien

    Feedback and Knowledge Base