代码之家 › 专栏 › 技术社区 › freefaller

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

iis-10 crash-dumps windbg iis

freefaller · 技术社区 · 6 年前

在未能获得 DebugDiag to analyse crash-dump files 有人建议我尝试使用 WinDbg 相反。

问题是。。。 当我跑的时候 !analyze -v

那么有没有办法告诉WinDbg它可以在本地机器上的特定位置找到DLL呢?

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

有人能给我指出正确的方向吗?

0 回复 | 直到 6 年前

Jokies Ding 6 年前

你不必分析转储文件!分析-v。如果您需要加载dll,那么.load D:。。。。够了。

分析转储文件。

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

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

!mex.aspxpages

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

!mex.clrstack2

1.您可以使用 ~* k 检查状态。然后你会发现 KERNELBASE!RaiseException 在特定线程中

2.然后通过 threadid~ 喜欢 12~

!mex.clrstack2文件 它将显示崩溃异常

Thomas Weller 6 年前

基本上,不,你不能在没有符号的地方加速加载DLL符号的过程。IMHO,加快符号进程的唯一方法是禁用HTTP服务器,这样符号就只能在本地磁盘上搜索了。

另请参见: How to set up symbols in WinDbg 如果你没有经常这样做。

freefaller 6 年前

首先我要说的是,我并不是100%理解我必须做的每一件事,但是下面是我发现stackoverflow问题在我的应用程序中的位置所采取的步骤。。。

大部分信息来自 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

(The) 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文件
安装 WinDbg 通过Windows 10开发机器上的Windows应用商店
跑 windbgx -y c:\windbg\symbols windbgx 在我的机器上,但可能是因为它是通过商店而不是手动下载的)
在“文件”菜单中 Open dump file C:\WinDbg\CrashDumps
运行了以下命令。。。
- .symfix
- .reload
- .load c:\windbg\symbols\sos.dll (见下文注1)
- !clrstack (见下文注2)

虽然这并没有给我所有我期望的信息,但它确实表明,我的一个第三方组件对stackoverflow异常负有100%的责任。

.loadby sos clr 应该用的,但那只是给了我 The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed 我不知道该怎么修。。。所以我用了 .

注2:合同 !CLR堆栈 命令起作用是因为WinDbg似乎预先选择了出现异常的线程。另一种选择是使用 ~*e !clrstack