IIS挂起请求-在内存转储中看不到CLR堆栈跟踪

时间:2018-07-27 10:46:30

标签: asp.net iis windbg

.NET 4.6.2上的ASP.NET WebAPI2应用程序,托管在Windows Server 2016的IIS上。有时,有很多(数百个)请求停留了几个小时(尽管我设置了60秒的请求超时) ),没有CPU使用率。因此,我从服务器的sos.dll目录中提取了w3wp进程的内存转储以及clr.dllmscordacwks.dllbin以及我的项目的所有dll和pdbs,并使用WinDbg作为在许多博客和教程中都有介绍。但是,他们所有人都可以通过调用~*e !clrstack直接查看CLR堆栈。我可以看到一些Redis和ApplicationInsights工作者的CLR堆栈跟踪,但是对于所有其他托管线程,我只能看到:

OS Thread Id: 0x1124 (3) Child SP IP Call Site GetFrameContext failed: 1 0000000000000000 0000000000000000

!dumpstack中的任何一个都给出了这样的信息:

0:181> !dumpstack OS Thread Id: 0x1754 (181) Current frame: ntdll!NtWaitForSingleObject+0x14 Child-SP RetAddr Caller, Callee 000000b942c7f6a0 00007fff33d63acf KERNELBASE!WaitForSingleObjectEx+0x8f, calling ntdll!NtWaitForSingleObject 000000b942c7f740 00007fff253377a6 clr!CLRSemaphore::Wait+0x8a, calling kernel32!WaitForSingleObjectEx 000000b942c7f7b0 00007fff25335331 clr!GCCoop::GCCoop+0xe, calling clr!GetThread 000000b942c7f800 00007fff25337916 clr!ThreadpoolMgr::UnfairSemaphore::Wait+0xf1, calling clr!CLRSemaphore::Wait 000000b942c7f840 00007fff253378b1 clr!ThreadpoolMgr::WorkerThreadStart+0x2d1, calling clr!ThreadpoolMgr::UnfairSemaphore::Wait 000000b942c7f8e0 00007fff253d952f clr!Thread::intermediateThreadProc+0x86 000000b942c7f9e0 00007fff253d950f clr!Thread::intermediateThreadProc+0x66, calling clr!_chkstk 000000b942c7fa20 00007fff37568364 kernel32!BaseThreadInitThunk+0x14, calling ntdll!LdrpDispatchUserCallTarget 000000b942c7fa50 00007fff3773e821 ntdll!RtlUserThreadStart+0x21, calling ntdll!LdrpDispatchUserCallTarget

所以我不知道在代码中的哪里寻找错误。

(以下是完整结果:

https://gist.github.com/rouen-sk/eff11844557521de367fa9182cb94a82

这是!threads的结果:

https://gist.github.com/rouen-sk/b61cba97a4d8300c08d6a8808c4bff6e

我该怎么办? Google搜索GetFrameContext failed并没有帮助。

1 个答案:

答案 0 :(得分:0)

如上所述,这并非微不足道,但是您可以在此处找到类似问题的案例研究:https://blogs.msdn.microsoft.com/rodneyviana/2015/03/27/the-case-of-the-non-responsive-mvc-web-application/

简而言之:

  • 下载NetExt。这是zip文件: https://github.com/rodneyviana/netext/tree/master/Binaries
  • 打开转储并加载NetExt
  • 运行!windex索引堆
  • 运行!whttp -order -running查看正在运行的请求列表
  • 如果请求中包含线程号,则可以转到该线程以查看正在发生的情况
  • 如果请求中包含---而不是线程号,则它们正在等待线程,这表明正在进行一些限制
  • 如果它是WCF服务,请运行!wservice以查看服务
  • 运行!wruntime以查看运行时信息
  • 运行!wapppool查看应用程序池信息
  • 运行!wdae列出所有错误
  • ...就这样。当您一次又一次地执行此操作时,您将能够轻松发现问题