分析崩溃转储文件时未在WinDbg中下载DLL

Question

在没有得到分析崩溃转储文件之后，有人建议我尝试使用WinDbg。

崩溃转储文件是在Windows 2016框上创建的，在IIS-10上运行我的ASP.Net 4.5.2Web应用程序。我的ASP.Net web应用程序包含几个第三方组件，以及它们各自的DLL。

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

问题是.，当我在WinDbg中对任何崩溃转储文件运行!analyze -v时，它实际上是在“下载文件xxx.DLL”(xxx.DLL只是第三方组件DLL之一的名称)时挂起的，并最终在一段时间后自行取消。

我运行的WinDbg在同一台机器上，我建立了网站的第一次.，那么有没有办法告诉WinDbg，它可以在本地机器上的特定位置找到DLL呢？

我显然没有任何第三方组件的.pdb文件，所以我不介意它为那些DLL加载符号.但要么我让它忽略那些特定的DLL，要么告诉它如何在本地找到它们。

谁能给我指明正确的方向？

Answer 1

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

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

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

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

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

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

!mex.clrstack2将在特定线程中显示所有异常和人工调用堆栈。

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

2.然后通过threadid~ (类似于12~ )转到这个线程

3.运行!mex.clrstack2，它将显示崩溃异常

Answer 2

基本上，不，在没有符号的情况下，不能加快加载DLL符号的过程。IMHO，加速符号进程的唯一方法是禁用HTTP服务器，以便只在本地磁盘上搜索符号。

如果您没有经常这样做，请参见：如何在WinDbg中设置符号。

为这些文件获取HTTP 404不需要很长时间。然而，它尝试各种文件结束和指针等。有时微软服务器是缓慢的。当然，拥有大量的第三方DLL也可以总结。这可真是太令人讨厌了。

Answer 3

我首先要说的是，我不能百分之百地理解我必须做的所有事情，但是下面是我在我的应用程序中发现堆栈溢出问题所在的步骤。

大部分信息来自这个博客。

• 在服务器上，我添加了以下注册表设置来创建崩溃转储文件. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows错误报告\LocalDumps "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，0070,0073,005c，0000000000

( 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安装WinDbg
• 通过Run命令运行windbgx -y c:\windbg\symbols (出于某种原因，它在我的机器上是windbgx，但可能是因为它是通过商店而不是手动下载)
• 在“文件”菜单Open dump file中，选择C:\WinDbg\CrashDumps中的一个转储文件。
• 运行以下命令..。
  • .symfix
  • .reload
  • .load c:\windbg\symbols\sos.dll (见下文注1)
  • !clrstack (见下文注2)

虽然这并没有给我提供我所期望的所有信息，但它确实表明，我的第三方组件中的一个应该对堆栈溢出异常负100%的责任。

注1-我读到的许多地方都说应该使用.loadby sos clr，但这给了我The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed和我不知道如何修复它.因此，我使用了.load c:\windbg\symbols\sos.dll。

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