Debugging WinDbg psscor4命令!ASPXPages/!DumpHttpContext缺少大多数线程ID并显示XXX

Debugging WinDbg psscor4命令!ASPXPages/!DumpHttpContext缺少大多数线程ID并显示XXX,debugging,c#-4.0,windbg,Debugging,C# 4.0,Windbg,我正在分析运行.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

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

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

由于线程池的工作方式,我希望在任何时候都能看到一些XXX线程。这意味着操作系统线程被终止,但关联的托管线程对象仍然可用。你说得对!aspxpages列出了许多线程。这与产品的输出有什么关系!线程?!线程显示了几十个线程ID,因此psscor4上几乎所有线程的XXX都感觉不对劲。psscor4中的某种错误或异常情况?有没有办法手动交叉检查psscor4在中执行的操作!要进一步调试吗?