Windows中的线程命名杂谈

Windows允许您为进程中的线程指定名称，然后调试器可以显示这些名称。这是一个很好的解决方案，但这是一个很好的解决方案。Windows 10 Creators更新（SetThreadDescription）中添加了一个新的线程命名API。Chrome现在使用SetThreadDescription来命名它的线程（当这个函数可用时）。chromiumrepo还包含一个工具，可以使用GetThreadDescription转储进程的所有线程名称。xperf/WPA支持SetThreadDescription API——线程名称会显示在CPU使用率图和通用事件图中，这非常棒。VS 2017 15.6（更新6）和Windows应用商店版本的windbg现在支持线程名称，包括实时调试和小型转储！name列现在包含您给定的任何名称（请注意未命名的TppWorkerThread，因为Windows仍然落后）。已经被注入到线程池中，等待最早更新的线程是2019年6月。我们看看效果如何。其他需要命名的Microsoft线程，因为它们最终会出现在其他开发人员的进程中，包括：

• DbgUiRemoteBreakin
• CManagerImpl:：_DelegateThreadProc
• CRpcThreadCache:：RpcWorkerThreadEntry

目前，在windbg的进程和线程窗口中，这些线程看起来都是相同的，并且让完全不同的线程看起来无法区分是个坏主意。这也使得在Chrome浏览器进程中很难找到Chrome忘记命名的线程。

Orbit Profiler支持使用GetThreadDescription（）获取线程名称–太棒了！

下面是WPA中的线程名称示例，它使这些事件在进程和线程之间的分布更易于查看：

Visual Studio中的线程名称也非常棒，尤其是现在即使在进程启动很久之后附加线程名称也会出现：

线程名非常棒，应该会让Chrome调试变得简单一点。

看看WPA中线程名有多有用！

所有线程命名问题的状态摘要–剩下的唯一任务是Microsoft需要开始命名其线程：

示例代码中的Const正确性：Fixed

/analyze示例代码中的警告：已修复

调试器中的竞争条件：在VS2015更新2中修复

操作系统线程命名功能：在Windows10 Creators更新中添加（文档称1607/周年纪念版，但这是不正确的）

线程命名函数的工具支持：xperf/WPA、visualstudio和windbg的存储版本都显示线程名称。“经典”版本的windbg通过非常明显的命令“dx-g”显示线程名称@$curprocess.线程“–这里讨论了更多的想法

Windows需要为自己的线程命名，尤其是它注入到其他进程中的线程，比如ntdll.dll!TppWorkerThread（应命名为ThreadPoolWorker）。这也适用于创建线程的第三方库、注入线程的图形驱动程序等等。查找SetThreadDescription并使用它（如果可用）。并选择描述性但简短的线程名称
线程的imageNaming无疑是有帮助的。它在调试时提供了额外的上下文，可用的信息越多越好。右边的屏幕截图显示了调试UIforETW时visualstudio中threads窗口中的name列。
然而，线程命名存在许多缺陷，主要是因为它只是一个调试器约定，而不是一个操作系统特性。

出现主要缺陷是因为Windows上的线程命名是通过引发异常来实现的。有一个约定，调试器应该注意异常代码0x406D1388–是的，这只是一个没有内在含义的任意幻数–并在相关的异常记录中查找幻数值。调试器必须执行以下操作：
打电话给WaitForDebugEvent。如果出现异常，并且异常代码为0x406D1388，并且参数的数目是正确的值，则重新解释异常信息。查看该结构，如果dwType等于4096，dwFlags为零，则使用ReadProcessMemory从调试对象的内存中获取线程名称。
哦，从哪里开始…
这一准则的特殊性是显而易见的。debuggee设置一组参数，然后使用RaiseException向调试器发出信号。如果调试器支持线程命名，那么它将处理这个特定的异常（ExceptionCode、NumberOfParameters、dwType和dwFlags的匹配值），然后从调试对象的内存中读取线程名称。无论调试器是否支持异常，调试对象都会处理异常并继续。这是IPC的一种粗略的方法。
这种技术的好处是它存在。如果这个特性被建议作为一个操作系统的特性，那么它可能会在设计审查或规划中被捆绑几十年。使用这种黑客技术意味着visualstudio调试器团队（MS_VC_异常代码背叛了他们的手）可以实现调试器端，记录如何在客户端调用它，让它立即在所有版本的Windows上运行，然后重新开始工作。Windbg很容易实现了相同的特性，一切都很好。
但是，这种权宜之计给我们留下了一些问题。

不是缺陷

当我第一次在tweet上发布这些问题时，我得到了一个回复，声称64位构建的结构定义是错误的。这个机制确实很脆弱，但并没有被打破。Win32调试API的一个限制是调试器和调试对象的位必须匹配—32位进程不能附加到64位进程。而且，只要调试器和debuggee具有相同的结构布局，那么它是什么并不重要。由于调试器和调试对象将使用相同的编译器和相同的结构定义，因此它们将具有相同的布局，这就是所需的全部内容。
不需要使用pragma pack指令来强制执行结构的任何特定打包，但需要它们来确保两边都具有相同的布局。
visualstudio是32位的，它可以调试64位进程，但它通过使用IPC与64位调试器代理进行通信来实现这一点。它使用msvsmon.exe，所以64位进程的调试基本上是本地远程调试。

小问题

我想先解决这些问题，尽管它们不是严重的问题。

示例代码已很长时间没有更新。因为它的threadName参数被声明为char*，所以不能用constchar数组调用它，如果使用/Zc:strictStrings（非常方便）构建它，甚至不能用string常量调用它。这个小错误现在已经被粘贴到数千个代码基中。我建议在代码中修复这个问题，但是使用剪切粘贴编码意味着这个糟糕的示例将永远存在。现在修好了！

示例代码触发两个/analyze警告。其中一个抱怨筛选器表达式是常量，另一个则抱怨\uuExcept块为空。analyze团队应该将SetThreadName文档视为这些构造通常不是bug的证据，文档团队应该添加必要的警告抑制杂注。仍然相关的示例代码应该在高警告级别下编译干净。现在修好了！

大问题

所有这些大问题都源于设计的一个后果：如果在引发异常时没有调试器在监听，那么线程名称将永远丢失。
如果调试程序在线程命名完成后附加，则调试器将不知道它错过了这些异常。无法要求调试人员再次引发异常。我想调试人员可以每隔几秒钟重命名一次线程，但这充其量是一种减少危害的策略，如果在进程崩溃时附加调试器，它仍然会完全失败。当前的策略意味着大多数Windows错误报告崩溃都没有线程名。
事实证明，调试器并不是唯一可以从了解线程名称中获益的工具。探查器，如Windows Performance Toolkit（xperf）将通过使用thread name列得到极大的增强，按线程名分组将是非常棒的。但是，作为调试器附加到被分析的进程是一个糟糕的主意，所以Windows性能分析器（WPA）无法获取这些信息。
另外，两个主要的Windows调试器都有一个可以避免的争用条件，这会导致SetThreadName频繁地静默失败。如果线程创建事件在线程命名异常之前到达，则这两个调试器似乎只命名线程。如果您创建了一个线程，然后立即从creator线程中命名它，那么在线程开始运行之前引发异常是非常容易的（尤其是在多核处理器上）！修复不应该很难——只需修复调试器，这样它就可以处理以任意顺序显示这两个事件。容易的。在这些调试器修复其竞争条件之前，每个命名其线程的应用程序都必须非常小心。

解决它

想出一个解决所有这些问题的办法是一个有趣的练习。我可以很容易地创建一个导出SetThreadName函数的DLL。然后，这个DLL将与另一个进程通信，该进程将维护一个内存中的数据库，该数据库将线程id映射到名称。为了避免客户机上的速度减慢，这将是一个选择加入进程，可能是通过让程序执行LoadLibrary/GetProcAddress舞蹈来实现的，以查看是否安装了DLL/进程对。这很简单，但是这个想法有两个问题，严重到足以让我不去烦。

我天真的方法无法判断线程何时死亡，这意味着线程数据库将迅速增长到数千个条目。这些线程中的大多数都是未使用的，而且许多线程表示重用已命名但现在已死线程的id的线程。添加unsethreadname函数可以减少混乱，但无法解决问题，尤其是在线程突然退出时。在用户模式下解决这个问题而不引入竞争条件将是一个挑战。

更大的问题是线程命名API需要广泛的支持。我可以说服成千上万的开发人员采用一种新的线程命名API，但是如果没有工具支持，这将是毫无意义的。我希望这个线程名数据库由windbg、visualstudio调试器和ETW跟踪查询。我没有这些工具的源代码，也找不到在哪里创建拉请求。
事实证明，驱动程序可以使用PsSetCreateThreadNotifyRoutine可靠地跟踪线程的创建和销毁，从而创建一个线程名称数据库。但是，这仍然缺少对工具的支持，所以微软已经实施了一个官方的解决方案。
在操作系统中添加这种类型的工具是有先例的。gflags工具允许开发人员跟踪堆分配、对象创建者类型跟踪等等。现在是微软添加线程名称作为gflags选项的时候了。内核可以捕捉现有的异常，可以更新调试器和探查器来查询内核的线程名称数据库，这样世界会变得更好。
我希望微软也能修复当前设置中的const正确性，/analyze警告和竞争条件。三个都修好了。

在那之前如果您正在编写调试器，请考虑添加一个更健壮的线程命名机制。也许会流行起来。您还应该支持现有的标准，并在调试器中修复其竞争条件。如果您正在编写一个程序，其中您想命名您的线程，那么您所能做的就是稍微改善一下情况。可以用两种方法之一避免线程命名竞争条件。最简单的解决方案是让线程自己命名。这保证线程创建事件在异常事件之前到达，因为子线程在开始运行之前不能调用SetThreadName。如果您想创建线程，然后从creator thread中命名它们，那么您必须等到线程完全启动。这可以通过等待线程发出一个事件的信号来完成，或者如果这不方便，那么就等“一会儿”然后交叉手指。
您还应该将thread name参数设为constchar*，并使用“#pragma warning（disable:63206322）”来抑制伪/analyze警告