2

Our 32-bit C++ application names its threads using the standard approach on Windows. We generate minidumps when errors occur, but when the dumps are loaded into Visual Studio 2013 the thread names are missing. This makes it harder to debug the problem given the high number of threads present.

The only way I've heard of to improve this comes from this Microsoft User Voice posting, where the caller suggests embedding them in a custom stream, and writing a custom Visual Studio extension to rename the threads upon loading the dump. However, this seems cumbersome and apparently adds a lot of time to the loading process.

Is there an easier way to embed thread names in the dump so they "just work" when loading them in Visual Studio?

For reference: we use Visual Studio 2013 to build, our apps run on Win7 or higher, and we use Google Breakpad to generate dumps.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
Chris Kline
  • 2,249
  • 26
  • 32
  • Threads do not have names. There's a [hack to attach one](http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx) by intentionally throwing an exception that the debugger intercepts. – Hans Passant Aug 05 '14 at 15:50
  • Yes, I understand that it's a hack that is supported in the debugger only. What was looking for is a way to 'name' threads in a similarly easy and consistent fashion yet persist that info into minidumps, then recover it upon load. – Chris Kline Aug 06 '14 at 14:25
  • 2
    @HansPassant "Threads do not have names" is a very defeatist answer. Threads do not have names because a robust API for naming them has not been provided. Threads *could* have names, and threads *should* have names. Their lack of naming is not due to a law of nature, it is just due to the feature not being written yet. https://randomascii.wordpress.com/2015/10/26/thread-naming-in-windows-time-for-something-better/ – Bruce Dawson Oct 28 '15 at 03:37
  • Update: @KayceeAnderson at Microsoft has [left a comment](https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5792677-include-and-use-native-thread-names-in-minidumps) mentioning that there is some work in progress on a newer approach to thread naming. – Chris Kline Dec 02 '16 at 16:14
  • This is now supported in WinDbg via SetThreadDescription(). See this answer for details: https://stackoverflow.com/questions/25142954/embedding-thread-names-in-windows-minidump-files/41446477#comment77039180_41446477 – Chris Kline Jul 11 '17 at 11:10

2 Answers2

4

Microsoft has indicated that the SetThreadDescription API will be the basis for any proper support they add in the future for thread names in dumps, debuggers, and/or analysis tools.

Unfortunately it appears that this API is rather new and is not yet supported in dumps, WinDbg, Visual Studio Debugger, etc. There is a User Voice request to add this support, so please vote for it if you would like a way to properly give threads a persistent name.

Chris Kline
  • 2,249
  • 26
  • 32
  • Update: An upcoming build of WinDbg now supports showing the thread names set via SetThreadDescriptionAPI in minidumps. See this link for details: https://blogs.msdn.microsoft.com/windbg/2017/06/29/debugger-updates-in-the-16225-sdk-preview/ – Chris Kline Jul 11 '17 at 11:10
  • 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 – Chris Kline Aug 17 '17 at 13:00
  • The minidump format now supports thread names but I am having trouble finding documentation for the format used. I need this for crashpad, which writes minidump files manually. See https://bugs.chromium.org/p/crashpad/issues/detail?id=327 – Bruce Dawson Feb 05 '20 at 23:41
  • 1
    @BruceDawson I spoke with Microsoft about this. They said that in the latest version of the minidumpapiset.h header there is a stream type called ThreadNamesStream This corresponds to a structure defined in the same header called `MINIDUMP_THREAD_NAME_LIST` with a ThreadNames array member with values of type: `typedef struct _MINIDUMP_THREAD_NAME { ULONG ThreadId; RVA64 RvaOfThreadName; } MINIDUMP_THREAD_NAME, *PMINIDUMP_THREAD_NAME;` where `ThreadId` corresponds to the TID of a thread, and `RvaOfThreadName` is a virtual memory address in the dump that contains the name. – Chris Kline Feb 19 '20 at 18:03
  • Thanks for the help. I added that information to the crashpad tracking bug at https://bugs.chromium.org/p/crashpad/issues/detail?id=327 – Bruce Dawson Feb 20 '20 at 19:36
0

After some more digging, it seems like one way to do this would be to store a pointer to the name in the ArbitraryUserPointer field of the TEB of the thread.

If the TEB was then embedded in the minidump (which can be achieved with the MiniDumpWithProcessThreadData flag, according to this article) then it seems like at the very least we could view the current thread name in the Visual Studio watch window by evaluating 

(*(char **)(@TIB+0x14))

Perhaps a Visual Studio debugger add-on could be written to examine the contents of the TEB when a process is attached to, and use the exception 'hack' to set the name of the thread in the Threads window.

Chris Kline
  • 2,249
  • 26
  • 32
  • Hmm, the plot thickens. [Raymond Chen says that the ArbitraryUserPointer field is not application controlled](http://stackoverflow.com/a/9264758/434413), even though [prior Microsoft articles](http://web.archive.org/web/20011220030149/http://www.microsoft.com/msj/0100/bugslayer/bugslayer0100.asp) indicate that it is, at least for WinNT. – Chris Kline Aug 06 '14 at 15:10
  • Seems unlikely they'd break existing 32-bit apps by letting the OS overwrite it. But all bets are off for x64, I suppose, which is likely why it's no longer called out in the PEB struct definition found in winternl.h. – Chris Kline Aug 06 '14 at 15:21