分析故障转储文件时，DLL 未在 WinDbg 中下载答案

【问题标题】：DLL not downloading in WinDbg when analysing crash-dump file分析故障转储文件时，DLL 未在 WinDbg 中下载
【发布时间】：2020-10-08 12:20:07
【问题描述】：

在获取DebugDiag to analyse crash-dump files 失败后，建议我尝试改用WinDbg。

故障转储文件已在 Windows Server 2016 机器上创建，在 IIS-10 上运行我的 ASP.Net 4.5.2 Web 应用程序。我的 ASP.Net Web 应用程序包含多个 3rd 方组件，以及它们各自的 DLL。

我已将故障转储文件复制到我的 Windows 10 开发机器上，并在本地而不是在服务器上运行 WinDbg。

问题是...当我在 WinDbg 中对任何故障转储文件运行 !analyze -v 时，它实际上挂起，而“下载文件 xxx.DLL”（xxx.DLL 是只是其中一个 3rd 方组件 DLL 的名称），并最终在一段时间后自行取消。

我在最初构建网站的同一台机器上运行 WinDbg...有没有办法告诉 WinDbg 它可以在本地机器上的特定位置找到 DLL ?

我显然没有任何第 3 方组件的 .pdb 文件，因此我不担心它为这些 DLL 加载符号……但我以某种方式告诉它忽略那些特定的 DLL ，或者我告诉它如何在本地找到它们。

谁能指出我正确的方向？

【问题讨论】：

对于 .NET Framework 应用程序，您实际上并不需要 !analyze -v，因为它主要用于本机崩溃和其他问题。浏览托管线程并检查它们的调用堆栈，罪魁祸首应该很清楚。提示可以在 dougrathbone.com/blog/2014/03/20/… 之类的帖子中找到
再次感谢您的帮助@Lex（变成我的私人助理）...感谢您的博文。我会继续调查
@Lex - 花了一段时间，但我最终将问题追溯到特定的第 3 方组件。再次感谢博文，真的很有帮助
您可以将所学内容总结为答案并接受。 .NET 转储分析对于某些场景（例如您的场景）实际上很容易，因此一旦您掌握了基本步骤，您就可以在未来征服更大的步骤。
@Lex - 终于有时间写一个答案。我敢肯定我的方法有很多漏洞，但我如何做到这一点是准确的

标签： iis windbg crash-dumps iis-10

【解决方案1】：

您不必使用 !analyze -v 分析转储文件。如果需要加载dll，那么.load D:....就足够了。

手动分析转储文件。请运行 .loadb sos clr 加载调试模块。如果崩溃服务器和您的机器运行不同版本的 .net 框架。然后你需要手动加载sos.dll。

当您需要在 IIS 中调试 .net 应用程序时，推荐使用 !mex 扩展名。 https://www.microsoft.com/en-us/download/details.aspx?id=53304

您可以通过 .load c:\.....\mex.dll 加载 mex.dll

!mex.aspxpages可以显示进程内部的所有请求及其进程

!mex.mthreads显示所有线程的状态

!mex.clrstack2 将显示特定线程中的所有异常和托管调用堆栈。

1.您可以使用~* k在所有线程中加载完整的调用堆栈，并使用!mex.mthreads检查状态。然后你可能会在特定线程中找到类似KERNELBASE!RaiseException 的内容

2.然后通过threadid~像12~一样去这个帖子

3.运行!mex.clrstack2会显示崩溃异常

【讨论】：

If you need to load dll, then .load D:.... is enough. - 不会加载 DLL，它会加载 WinDbg 扩展
您的大部分回答与我的问题无关...我不是直接在本地或远程调试 IIS。我正在将崩溃文件下载到我的本地机器上

【解决方案2】：

基本上，不，您无法加快为没有符号的 DLL 加载符号的过程。恕我直言，加快符号处理的唯一方法是禁用 HTTP 服务器，以便仅在本地磁盘上搜索符号。

如果您不经常这样做，另请参阅：How to set up symbols in WinDbg。

为这些文件获取 HTTP 404 不会花费很长时间。但是，它会尝试各种文件结尾和指针等。有时 Microsoft 服务器很慢。此外，当然可以总结出大量的第 3 方 DLL。这可能很烦人。

【讨论】：

禁用 HTTP 服务器是有道理的，但我相信我通过使用 WinDbg -y C:\WinDbg\Symbols 的命令行运行应用程序有效地做到了这一点。幸运的是，我设法弄清楚堆栈溢出是由特定的第 3 方组件引起的，而没有使用 !analyze -v
@freefaller: 是的，使用-y 进行设置应该禁用 HTTP 符号服务器

【解决方案3】：

我首先要说我不是 100% 了解我必须做的所有事情，但这里是我发现堆栈溢出问题在我的应用程序中的位置的步骤...

大部分信息来自this blog。

在服务器上，我添加了以下注册表设置来创建故障转储文件...

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpCount"=dword:00000005
"DumpFolder"=hex(2):43,00,3a,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,\
00,6d,00,70,00,73,00,5c,00,00,00

（DumpCount 是在开始覆盖旧文件之前要存储的文件数 - DumpFolder 是要保存文件的位置，是 REG_EXPAND_SZ，在我的例子中代表 C:\CrashDumps\）

等待崩溃发生
将崩溃文件复制到我本地计算机上名为C:\WinDbg\CrashDumps\ 的目录中
创建另一个名为C:\WinDbg\Symbols 的目录，我将...
- clr.dll（来自服务器，取自C:\Windows\Microsoft.NET\Framework64\v4.0.30319\）
- sos.dll（来自服务器，取自C:\Windows\Microsoft.NET\Framework64\v4.0.30319\）
- 我本地开发环境中的所有 .dll 和 .pdb 文件，包括第三方组件 .dll 文件
在我的 Windows 10 开发机器上通过 Windows Store 安装 WinDbg
通过运行命令运行windbgx -y c:\windbg\symbols（由于某种原因，我的机器上是windbgx，但可能是因为它是通过商店而不是手动下载）
在文件菜单Open dump file 中选择C:\WinDbg\CrashDumps 中的转储文件之一
运行以下命令...
- .symfix
- .reload
- .load c:\windbg\symbols\sos.dll（见下文注 1）
- !clrstack（见下文注 2）

虽然这并没有给我预期的所有信息，但它确实表明我的第 3 方组件之一是 stackoverflow 异常的 100%。

注 1 - 我读到的很多地方都说应该使用 .loadby sos clr，但这只是给了我 The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed 而我不知道如何解决它......所以我使用了 @987654347 @。

注意 2 - !clrstack 命令有效，因为 WinDbg 似乎预先选择了出现异常的线程。另一种选择是使用~*e !clrstack，它将显示所有线程的调用堆栈。

【讨论】：