据我所知，线程池线程在其生命周期中服务于不同的“主服务器”，在繁忙的应用程序中，这样的线程实际上可能存活很长时间。
似乎这样的线程在!runaway输出中产生误报。
在这种情况下，此命令的用处大大减少。
我是正确的还是我在这里遗漏了什么？
EDIT1
那么WCF / Asp.NET请求线程呢？它们也被回收了吗？如果是这样，那就什么都没有了。当然，I / O完成线程也是可以回收的。
答案 0 :(得分：0)
据我所知，线程池线程服务于不同的＆＃34;主人＆＃34;在其一生中
是
并且在繁忙的应用程序中，这样的线程实际上可能存活很长时间。
是
似乎这样的线程在！失控输出中产生误报。
这取决于＆＃34;误报＆＃34;的定义。
在任何情况下，它都是对您知道应用程序正在做什么以及您实际观察到的内容的解释。如果匹配，一切都很好，如果不匹配：调查。例如。如果你有一个线程池，期望!runaway成为一个表示完成工作量的数字。
但它并没有错：该线程实际上消耗了那么多的CPU时间。以这种方式思考，这不是误报。
这里的问题是：为什么你首先运行!runaway？您可能想要分析性能问题。在这种情况下，崩溃转储不太适合，因为它们仅代表单个时间点。对于性能分析，您需要持续的信息。
如果您很幸运并且您拥有丰富的经验，则可以解决崩溃转储中的性能问题，例如：如果我没记错的话，着名的Mark Russinovich通过一系列（！）的故障转储解决了一些Exchange Server问题，比较了堆栈跟踪并发现某些病毒扫描程序做了太多工作。
这里的关键点是：一系列故障转储，以便您可以确认它仍然是例如在一个无限循环左右。执行此操作的工具是ProcDump，它具有-c开关以在高CPU下触发。与-n一起使用它来写入多个转储和-s以定义转储之间的时间。
仍然，ProcDump不是理想的工具。您真正需要的是一种将性能分解为单一方法的工具。像dotTrace Performance Profiler（现在是Resharper Ultimate的一部分）或XPerf或类似工具的东西。
回答你的问题：
当报告的线程来自线程池时，是否！runaway命令有用吗？
!runaway 正确。它有助于＆＃34;命名＆＃34;中的性能分析。线程（var t = new Thread();）情况。它对线程池线程的性能分析没有多大帮助。