Question

我正在分析在运行.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中验证这个并以某种方式识别这个特殊的线程吗？

Answer 1

对于已完成的请求，ThreadId通常为XXXX。它们仍然在记忆中，因为它们尚未被垃圾收集。然而，奇怪的是，对于Completed = no的请求，您还有XXXX。尝试运行〜* e！clrstack来获取所有托管线程的堆栈。以这样的方式。你会准确地看到转储时发生了什么。

WinDbg psscor4命令！ASPXPages /！DumpHttpContext缺少大多数ThreadId并显示XXX

1 个答案: