1

我正在分析在运行 .NET 4 的 Windows Server 2008 R2 SP1 机器上使用 procdump -ma w3wp 获取的转储文件。

0:000> !ASPXPages
Going to dump the HttpContexts found in the heap.
Loading the heap objects into our cache.
HttpContext    Timeout  Completed     Running  ThreadId ReturnCode   Verb RequestPath+QueryString
0x0353f65c      110 Sec        no      1429 Sec     XXX        200   GET /Nav/ResTry.aspx qs1
0x03545a18      110 Sec       yes                   XXX        302   GET /Nav/
0x0354f26c      110 Sec        no      1366 Sec     XXX        200   GET /Nav/ResTry.aspx te
0x0355a45c      110 Sec       yes                   XXX        200   POST /Service/ResInhId_68022569!
0x035d8454      110 Sec       yes                   XXX        302   POST /Service/ResIntf.ashx act
0x035e1268      110 Sec        no      1213 Sec     XXX        200   GET /Nav/ResTry.aspx te
0x12e77088      110 Sec        no         6 Sec     XXX        200   GET /Nav/Activities.mvc/Index/2/7 
0x12e85b10      110 Sec        no         5 Sec     215        200   GET /service/Ressaveresult.aspx even
0x12e89cb8      110 Sec        no         5 Sec     XXX        200   GET /Nav/Activities.mvc/Index/2/5 topicid=1
0x12ed5038      110 Sec        no         4 Sec     XXX        200   GET /Nav/Ressave.aspx e
0x12ed9dc0      110 Sec       yes                   XXX        302   GET /Nav/DoItem.aspx ItemId=71937319

这里有 70 多个线程，但我修剪了输出。

为什么大多数 ThreadId 没有出现并显示为 XXX？如果我使用

 !threads

我几乎可以看到每个 ID，但鉴于缺少页面名称，因此很难找出他们在做什么。这些线程没有标记为已完成，我不相信它们真的死了，即使这就是所谓的 XXX 的意思。当我查看 IIS 中当前正在执行的请求时，出现了许多这样的页面。

如果我跑

 !threadpool

我确实看到几十个线程在运行，即使我只看到少数没有 XXX 的 ThreadId，这表明它们没有死，但不知何故 WinDbg 或 psscor4 没有正确加载 ThreadId。

另一个问题是为什么这些没有被 IIS 发送 Thread.Abort 并且超过了它们指定的超时时间。充当死神的线程是否也可能因机器上的高 CPU 问题而延迟？我们可以在 windbg 中验证这一点并以某种方式识别这个特殊线程吗？

4

1 回答 1

0

对于已完成的请求，ThreadId 通常为 XXXX。它们仍在内存中，因为它们还没有被垃圾收集。然而奇怪的是，对于 Completed=no 的请求，您也有 XXXX。尝试运行 ~*e !clrstack 以获取所有托管线程的堆栈。以这种方式。您将确切地看到转储时发生了什么。

于 2013-02-26T22:05:08.417 回答