windbg 故障转储分析，高 cpu 使用率 -

Question

我的应用程序 (web api) 遇到高 cpu，在分析转储时，我看到我的大多数线程都有这个 !dumpstack -:

  Child-SP         RetAddr          Caller, Callee
00000030497bec00 00007ffbb19e1118 KERNELBASE!WaitForSingleObjectEx+0x94, 

    calling ntdll!NtWaitForSingleObject
    00000030497beca0 00007ffba8375dda clr!CLRSemaphore::Wait+0xee, calling kernel32!WaitForSingleObjectEx
    00000030497becd0 00007ffba837345d clr!GCCoop::GCCoop+0xe, calling clr!GetThread
    00000030497bed60 00007ffba8375842 clr!ThreadpoolMgr::WorkerThreadStart+0x482, calling clr!CLRSemaphore::Wait
    00000030497bee00 00007ffba8393e1e clr!Thread::intermediateThreadProc+0x7d
    00000030497bee30 00007ffbb19e1f86 KERNELBASE!ConsoleCallServerGeneric+0xf2, calling KERNELBASE!_security_check_cookie
    00000030497bee50 00007ffbb45011a5 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset
    00000030497beed0 00007ffbb450d0c6 ntdll!LdrpGetProcedureAddress+0x66, calling ntdll!RtlImageNtHeaderEx
    00000030497bef50 00007ffbb450c6f5 ntdll!LdrpResolveNonStaticDependency+0x1cd, calling ntdll!LdrpDereferenceNode
    00000030497befd0 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
    00000030497bf000 00007ffbb45011a5 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset
    00000030497bf020 00007ffbb450f5f3 ntdll!LdrGetProcedureAddressForCaller+0x153, calling ntdll!_security_check_cookie
    00000030497bf030 00007ffb93fc8c84 mfc120u!DllMain+0x210, calling mfc120u!__security_check_cookie
    00000030497bf080 00007ffba8ce2cbb mscoreei!operator delete+0x34, calling kernel32!HeapFreeStub
    00000030497bf0d0 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
    00000030497bf140 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
    00000030497bf180 00007ffbac0c51bd gzip!DllMainCRTStartup+0x139, calling gzip!DllMain
    00000030497bf1e0 00007ffb979dbc9d clrcompression!calloc_impl+0x5d, calling ntdll!RtlAllocateHeap
    00000030497bf210 00007ffb979d8eff clrcompression!initptd+0xb7, calling clrcompression!unlock
    00000030497bf230 00007ffbb44ebf57 ntdll!RtlDeactivateActivationContextUnsafeFast+0xc7, calling ntdll!_security_check_cookie
    00000030497bf240 00007ffb979d7919 clrcompression!CRT_INIT+0x135, calling kernel32!GetCurrentThreadId
    00000030497bf270 00007ffb979d7a0e clrcompression!__DllMainCRTStartup+0x8a, calling clrcompression!DllMain
    00000030497bf280 0000000056b32052 msvcr100!_initptd+0xaa, calling msvcr100!_unlock
    00000030497bf2a0 00007ffbac051779 IitTlsCleanupHelper!UnregisterTLSCleanupCallback+0x679, calling IitTlsCleanupHelper!UnregisterTLSCleanupCallback+0xf0
    00000030497bf2b0 0000000056b31308 msvcr100!__CRTDLL_INIT+0x16c, calling msvcr100!_CrtEndBoot
    00000030497bf2d0 00007ffbb450bee8 ntdll!LdrpReleaseModuleEnumLock+0x1c, calling ntdll!RtlReleaseSRWLockShared
    00000030497bf2e0 00007ffbb44ec0f4 ntdll!LdrpCallInitRoutine+0x4c
    00000030497bf300 00007ffbb450be9b ntdll!LdrpReleaseLoaderLock+0x27, calling ntdll!LdrpReleaseModuleEnumLock
    00000030497bf340 00007ffbb44ebe53 ntdll!LdrpInitializeThread+0x1f3, calling ntdll!LdrpReleaseLoaderLock
    00000030497bf3b0 00007ffbb44ebd93 ntdll!LdrpInitializeThread+0x133, calling ntdll!RtlActivateActivationContextUnsafeFast
    00000030497bf3b8 00007ffbb44ebdc6 ntdll!LdrpInitializeThread+0x166, calling ntdll!RtlDeactivateActivationContextUnsafeFast
    00000030497bf420 00007ffbb44e8d73 ntdll!_LdrpInitialize+0x93, calling ntdll!NtTestAlert
    00000030497bf490 00007ffbb44e8c98 ntdll!LdrInitializeThunk+0x18, calling ntdll!NtContinue
    00000030497bf900 00007ffba8393e07 clr!Thread::intermediateThreadProc+0x66, calling clr!_chkstk
    00000030497bf940 00007ffbb43613d2 kernel32!BaseThreadInitThunk+0x22
    00000030497bf970 00007ffbb44e54e4 ntdll!RtlUserThreadStart+0x34

我的疑惑就在这3行-:

ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
00000030497bf140 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
00000030497bf180 00007ffbac0c51bd gzip!DllMainCRTStartup+0x139, calling gzip!DllMain

这个线程是否是 cpu 使用率高的原因？

Answer 1

您想要运行的第一个 WinDBG 命令是：!runaway。
此命令将显示哪个线程使用 CPU 的时间最长.
收到此命令的输入后，我们可以向前思考发生了什么...

Answer 2

Windbg 不是这项工作的正确工具。转储只是快照，因此您不知道之前发生了什么。使用 ETW 和此处的 CPU 采样，它汇总所有调用并向您详细显示 CPU 用法。

安装 Windows Performance Toolkit，它是 Windows 10 SDK 的一部分（V1607 works on Win8/8.1(Server2012/R2) and Win10 or the V1511 SDK 如果您使用 Windows 7/Server2008R2）），运行 WPRUi.exe 和 select CPU Usage

然后按 Start。捕获 1 分钟的高 CPU 使用情况，然后单击 Save。使用WPA.exe（Perf分析器）打开生成的ETL，将CPU Usage (Sampled)图拖放到analysys面板

和load the Debug Symbols。现在 select 您在图表中的进程，放大并展开堆栈，在这里您可以看到所有调用 CPU 使用的权重

在此示例中，Internet Explorer 的大多数 CPU 使用来自 HTML 内容。

对于 .NET 应用程序，WPA 会向您显示与 .net 相关的分组，例如 GC 或 JIT：

Answer 3

在任何分析后设置正确的符号路径。
在文件->符号文件路径菜单中设置： YOUR_SYMBOLS_PATH;OTHERS_PATH;SRVC:\symcachehttp://msdl.microsoft.com/download/symbols

尝试使用此命令查看托管堆栈：

.cordll -ve -u -l
ld*
!EEStack

Answer 4

根据文章 - http://msdn.microsoft.com/en-us/library/bb742546.aspx 我不应该关注这个线程.. 因为它正在等待并且可能处于睡眠模式 -WaitForSingleObjectEx 并且睡眠不会导致 cpu 使用..

如果有人处于相同情况，请提供更多资源 -: https://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment

https://msdn.microsoft.com/en-IN/library/ms182372.aspx

windbg 故障转储分析，高 cpu 使用率 -

windbg crash dump analysis, high cpu usage -

memory

gzip

windbg