.loadby sos clr - 找不到指定的模块答案

【问题标题】：.loadby sos clr - specified module could not be found.loadby sos clr - 找不到指定的模块
【发布时间】：2016-08-10 13:23:42
【问题描述】：

我试图深入了解转储文件中的 CLR 异常，但在尝试执行时遇到问题：

0:000> .loadby sos clr
The call to LoadLibrary(C:\ProgramData\dbg\sym\clr.dll\5348A1EF9a0000\sos) failed, Win32 error 0n126
    "The specified module could not be found."

我试图查看加载的内容，我看到了：

0:000> lm
start             end                 module name
00000000`00190000 00000000`001a4000   MyTest   (deferred)             
00000000`77a00000 00000000`77afa000   user32     (deferred)             
00000000`77b00000 00000000`77c1f000   kernel32   (pdb symbols)          C:\ProgramData\dbg\sym\kernel32.pdb\CEE1211DAF10494CAFDDBE2C4232EAE82\kernel32.pdb
00000000`77c20000 00000000`77dca000   ntdll      (pdb symbols)          C:\ProgramData\dbg\sym\ntdll.pdb\8AAAEEE259C340FCADC53FAF9FEF22E92\ntdll.pdb
000007fe`f8950000 000007fe`f9ef1000   mscorlib_ni   (deferred)             
000007fe`f9f00000 000007fe`f9fd6000   MSVCR120_CLR0400   (deferred)             
000007fe`f9fe0000 000007fe`fa980000   clr        (pdb symbols)          C:\ProgramData\dbg\sym\clr.pdb\E3E0C76A7909454FB3C56B0C2CE5FFEB2\clr.pdb
000007fe`fa980000 000007fe`faa1d000   mscoreei T (pdb symbols)          C:\ProgramData\dbg\sym\mscoreei.pdb\6D65F80ABA3D403D8F6F7214972B9BBF2\mscoreei.pdb
000007fe`faa20000 000007fe`faa8f000   mscoree    (deferred)             
000007fe`fd800000 000007fe`fd80f000   CRYPTBASE   (deferred)             
000007fe`fdbb0000 000007fe`fdc1a000   KERNELBASE   (pdb symbols)          C:\ProgramData\dbg\sym\kernelbase.pdb\D396875654E9416CBA16E51F8B0A8B1E2\kernelbase.pdb
000007fe`fdd60000 000007fe`fde69000   msctf      (deferred)             
000007fe`fde70000 000007fe`fe073000   ole32      (deferred)             
000007fe`fe0b0000 000007fe`fe121000   shlwapi    (deferred)             
000007fe`fe310000 000007fe`fe3da000   usp10      (deferred)             
000007fe`fe3e0000 000007fe`fe47f000   msvcrt     (deferred)             
000007fe`fe480000 000007fe`fe48e000   lpk        (deferred)             
000007fe`fe590000 000007fe`fe5af000   sechost    (deferred)             
000007fe`fe600000 000007fe`fe62e000   imm32      (deferred)             
000007fe`fe630000 000007fe`fe697000   gdi32      (deferred)             
000007fe`fe910000 000007fe`fe9eb000   advapi32   (deferred)             
000007fe`ff800000 000007fe`ff92d000   rpcrt4     (deferred)

看更多的 clr：

0:000> lmvm clr
Browse full module list
start             end                 module name
000007fe`f9fe0000 000007fe`fa980000   clr        (pdb symbols)          C:\ProgramData\dbg\sym\clr.pdb\E3E0C76A7909454FB3C56B0C2CE5FFEB2\clr.pdb
    Loaded symbol image file: clr.dll
    Mapped memory image file: C:\ProgramData\dbg\sym\clr.dll\5348A1EF9a0000\clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
    Image name: clr.dll
    Browse all global symbols  functions  data
    Timestamp:        Fri Apr 11 22:16:15 2014 (5348A1EF)
    CheckSum:         009A762B
    ImageSize:        009A0000
    File version:     4.0.30319.34209
    Product version:  4.0.30319.34209
    File flags:       8 (Mask 3F) Private
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® .NET Framework
    InternalName:     clr.dll
    OriginalFilename: clr.dll
    ProductVersion:   4.0.30319.34209
    FileVersion:      4.0.30319.34209 built by: FX452RTMGDR
    PrivateBuild:     DDBLD104
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

然后根据@Thomas Weller 的建议：

0:000> lmf m clr
Browse full module list
start             end                 module name
000007fe`f9fe0000 000007fe`fa980000   clr      C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

路径 (C:\Windows\Microsoft.NET\Framework64\v4.0.30319) 存在于我的 PC 上，并且里面有一个 SOS.dll。

附加信息：

ld clr; .reload /f 没有帮助
我没有使用.cordll修改CLR加载路径
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll 有效，但输入时间较长

为什么.loadby sos clr 不适合我？（我刚刚从https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit 安装了WinDbg，通过选择从安装程序中安装“Windows 调试工具”）

【问题讨论】：

我不想将.load 作为答案，因为这只是一种解决方法，并没有解释它为什么会发生以及如何防止它发生。
“映射的内存映像文件”似乎是问题所在。我猜想创建小型转储的机器上的 CLR 版本与您的机器上的版本不同。所以你从某个地方得到了正确的版本，我猜不出它是如何在 c:\programdata 中结束的。 sos.dll 版本需要与 clr.dll 版本匹配，因此不能完全保证使用 .load 是一种解决方法。

标签： .net windbg sos

【解决方案1】：

正如@Thomas Weller 所提到的，这种解决方法目前有效：

.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

【讨论】：

【解决方案2】：

使用我从@Thomas Weller 的问题中学到的知识找出答案。所以显然File -> Symbol File Path 中的“符号文件路径”在每次关闭 WinDbg 时都会被清除，而没有它 .loadby sos clr 会产生我得到的错误。 File -> Symbol File Path 中的“符号文件路径”必须有一个条目，如：srv*C:\windbg\websymbols（当然该目录必须存在）。

当您打开故障转储时，它应该具有以下输出（注意这一行：Symbol search path is: srv*C:\windbg\websymbols）：

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*C:\windbg\websymbols
Symbol search path is: srv*C:\windbg\websymbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000

另一方面，这是我之前所做的，这意味着您忘记设置“符号文件路径”（注意行 Symbol search path is: srv*）

Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: srv*
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000

【讨论】：

没有办法保存“符号文件路径”设置吗？我知道当我不得不再次使用 WinDbg 时，我会在几个月后再次遇到这个问题......
也许你可以设置 _NT_SYMBOL_PATH 环境。变量为explained here。但是IIRC，WinDbg应该ask you if you want to save settings to the default workspace?
您确定是符号路径导致的吗？我想知道为什么.loadby 会使用符号路径，因为它应该使用模块（DLL）的路径而不是符号（PDB 文件）
@Groo：使用 _NT_SYMBOL_PATH 可能会有副作用，例如在 Process Explorer 和 Visual Studio 上，可能需要避免。使用工作区当然是一种好方法，或者使用带有 -y 选项的调用 WinDbg 的链接。
@ThomasWeller，我不确定它为什么有效，但它确实解决了问题。同样，如果您在 WinDbg 中创建一个工作区并将其命名为“默认”，它会在您打开 WinDbg 时自动加载，这样就可以了。

【解决方案3】：

在我的例子中，WER 生成了 2 个文件：triagedump.dmp (2 MiB) 和 memory.hdmp (400 MiB)。

triagedump.dmp 仅包含异常信息，SOS 无法使用它。

memory.hdmp是minidump，SOS加载CLR成功。

【讨论】：