WinDbg 一个 Azure 应用服务 @ 100%答案

【问题标题】：WinDbg an Azure App Service @ 100%WinDbg 一个 Azure 应用服务 @ 100%
【发布时间】：2016-12-09 20:19:23
【问题描述】：

我有一个来自 Azure 应用服务的完整小型转储。它带有 .dmp 文件、sos.dll 和 mscordacwks.dll。

我有 WinDbg - x86 是可以打开这个转储文件的版本。然后我使用 .load c:\path\to\sos.dll。这不会产生错误，但也不会产生其他输出。

下一个建议的命令 !sos.threads 给出：

找不到运行时DLL（clr.dll），0x80004005 扩展命令需要 clr.dll 才能有事可做。

我已尝试直接在 mscordacwks.dll 上加载 .load，将其重命名为 clr.dll。我已将该文件复制到我的符号路径中，并将其重命名为 mscordaccore_X86_X86_4.6.24628.01.dll，这是在我在这里的任务中出现的。

我也尝试过运行 DebugDiag 2 分析工具，但它说它无法加载 mscordacwks，尽管它位于同一个文件夹中，当它位于符号路径中时，也当它重命名为上面的特定版本时这里也列出了。

我只想知道为什么我的应用服务在随机时间后卡在 100% CPU 上！我可以尝试哪些后续步骤？

【问题讨论】：

您是否尝试!analyze -v 或!runaway 来获取卡住的线程（假设它只有一个） 和~<threadnumber>s;kbnf 来获取该线程的本机堆栈跟踪线？也就是说，转储只是一个时间点，因此您可能会以这种方式错过真正的原因。更好的是使用 procmon （更容易分析） 或 ETW （更难分析，但信息量很大） 来获得一段时间内的流程概览.
@LievenKeersmaekers 谢谢，我会试试的。这是一项 Azure 应用服务 - 不要认为我可以在服务器上安装 procmon 或设置 ETW。有很多线程（约 40 个），一些等待工作（App Insights 上传线程），一些等待访问查询缓存（EF Core）
最好使用 ETW:stackoverflow.com/a/39856838/1466046 而不是分析转储中的快照。 WPT 可以复制到其他系统（仅确保 CPU 架构匹配）

【解决方案1】：

看来你对 WinDbg 不是很熟悉，所以我会稍微冗长一点。

WinDbg - x86 是可以打开这个转储文件的版本

WinDbg 的任何版本和位数都可以打开转储。即使是 32 位 WinDbg 也可以打开 64 位 .dmp 文件。这并不意味着您使用正确的版本来完成您想要实现的目标。

这不会给出错误，但也没有其他输出。

没关系。这意味着扩展已成功加载。很高兴知道，因为这意味着您使用的是正确的 WinDbg 位数。如果它真的是你使用的 x86 WinDbg，这表明你有一个 32 位的 SOS DLL。

如果位数不正确，您会收到一条错误消息，就像您尝试将 32 位 DLL 加载到 64 位进程中一样，反之亦然（在 .NET 中也称为BadImageFormatException）

扩展命令需要 clr.dll 才能有事可做。

SOS 扩展适用于 .NET，因此 SOS 正在寻找加载到进程中的 .NET 框架。这可能是

从消息中，我们可以得出您有一个适用于 .NET 4 的 SOS.dll，这就是它寻找 clr.dll 而不是其他东西的原因。对于 Azure Web 服务来说听起来很合理，因为 Azure 比 .NET 2 更新。

要查看 .NET 是否实际加载到进程中，请使用以下命令：

lm m clr
lm m mscorwks
lm m coreclr

如果这些命令中的任何一个产生了一些输出，您就会知道加载了哪个版本。请注意，.NET 4 和 .NET 2 可能同时出现（过程中使用了两个版本）。

我曾尝试直接在 mscordacwks.dll 上加载 .load，将其重命名为 clr.dll。

这是一个巨大的误解：

.load 将某些内容加载到 WinDbg 进程中。即使您设法在那里加载它，SOS 仍会在转储文件中搜索它。
mscordacwks 不是 .NET 框架。不要将其与mscorwks 混淆。 dac 部分用于数据访问控制。它是一个 DLL，用于管理对内存中 .NET 结构的访问，因为 .NET 有自己的内存管理。

但是，可能需要重命名它。这是一个艰难的故事。看来您已经找到了它的 Google 搜索结果...

将其重命名为 mscordaccore_X86_X86_4.6.24628.01.dll

它朝着正确的方向发展，但我认为这不是正确的名称。您介意链接原始建议吗，这样我就可以在抱怨我可能有旧知识的事情之前做一些研究？

恕我直言，名称应该是

mscordacwks_x86_x86_4.6.24628.01.dll

（如果版本号正确）。

正如 @Lieven Keersmaekers 在 cmets 中已经提到的那样，拥有一个 correct symbol path pointing to Microsoft 然后做一个

!analyze -v

应该从 Microsoft 下载必要的 mscordacwks 文件。这样，它将自动具有正确的名称并位于正确的文件夹中。

我也尝试过运行 DebugDiag 2 分析工具

要使 DebugDiag 正常工作，它还需要 mscordacwks。最简单的方法是也使用 Microsoft 符号服务器，以便它可以下载文件本身。

我只是想知道为什么我的应用服务会卡在 100% CPU

从单个故障转储文件进行分析是错误的。当您捕获故障转储文件时，该进程可能只是在做一些“正常”的事情。

如果您有许多具有相同调用堆栈的故障转储，则可能表明此方法处于无限循环或长时间运行循环中。要在高 CPU 下自动获取许多故障转储，请尝试 ProcDump，请参阅 how to take a good crash dump for .NET

还有什么问题？

你说你得到了这些文件。从文件的命名来看，我假设它们是从发生崩溃的机器上获取的。这基本上是个好主意。请注意，PC 上有许多此类文件。

如果你运行我的工具mscordacwks Collector，你就会明白我的意思。顺便说一句，该工具将检测版本并相应地重命名文件。或许你可以试试，机器还在。

【讨论】：

谢谢，正是我需要的那种建议。稍后我将深入研究并贯穿所有内容。 FWIW，当从服务器上的 Kudu 提供转储 zip 时，minidump 附带 sos.dll 和 mscordacwks.dll。因此，我似乎应该使用这些版本，但是在从 Azure 调试这种转储时遵循任何一小撮 tuts，它一直是错误的。请注意，它不是我也可以 RDC 的 VM，而是我拥有的远程转储。无论如何，稍后会更新 - 再次感谢
@KierenJohnstone：感谢您提供的信息。如果该 ZIP 文件是自动生成的，我们假设它是以正确的方式完成的。在这种情况下，我确实会说你应该使用它。不幸的是，他们没有让它更方便。我对 Azure 不太熟悉，Kudu 对我来说也没什么意义。