我收到一份 WER 报告，说我们的 .net 应用程序在某台机器上崩溃了，我得到了崩溃的转储文件，但我尝试了很多方法，阅读了很多关于调试 .net 崩溃的文章，但仍然没有运气，我什至无法运行sos.dll提供的扩展命令，我总是收到以下消息

“找不到运行时 DLL (clr.dll)，0x80004005 扩展命令需要 clr.dll 才能执行某些操作。”

我想知道如何知道那台机器上的 .net 框架版本？因为非扩展命令可以工作!!请帮忙!!

当我使用“lm”命令列出所有加载的模块时，我没有在模块列表中找到“clr”或“clrjit”模块，这是否意味着我的应用程序在崩溃之前实际上没有运行，可以我说机器上的 .net 框架坏了？

(locationsswitch 是我的应用程序，它被编译为 .net Framework 4.0 上的 x86 应用程序目标)

0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll
0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
0:000> .chain
Extension DLL search Path:
    C:\Program Files (x86)\Debugging Tools for Windows (x86)\WINXP;C:\Program Files (x86)\Debugging Tools for Windows (x86)\winext;C:\Program Files (x86)\Debugging Tools for Windows (x86)\winext\arcade;C:\Program Files (x86)\Debugging Tools for Windows (x86)\pri;C:\Program Files (x86)\Debugging Tools for Windows (x86);C:\Program Files (x86)\Debugging Tools for Windows (x86)\winext\arcade;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Common Files\Lenovo;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\
Extension DLL chain:
    C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll: image 4.0.30319.18444, built Thu Oct 31 05:47:48 2013
        [path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll]
    C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll: image 4.0.30319.18444, API 1.0.0, built Thu Oct 31 05:40:34 2013
        [path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll]
    dbghelp: image 6.12.0002.633, API 6.1.6, built Tue Feb 02 04:08:26 2010
        [path: C:\Program Files (x86)\Debugging Tools for Windows (x86)\dbghelp.dll]
    ext: image 6.12.0002.633, API 1.0.0, built Tue Feb 02 04:08:31 2010
        [path: C:\Program Files (x86)\Debugging Tools for Windows (x86)\winext\ext.dll]
    exts: image 6.12.0002.633, API 1.0.0, built Tue Feb 02 04:08:24 2010
        [path: C:\Program Files (x86)\Debugging Tools for Windows (x86)\WINXP\exts.dll]
    uext: image 6.12.0002.633, API 1.0.0, built Tue Feb 02 04:08:23 2010
        [path: C:\Program Files (x86)\Debugging Tools for Windows (x86)\winext\uext.dll]
    ntsdexts: image 6.1.7650.0, API 1.0.0, built Tue Feb 02 04:08:08 2010
        [path: C:\Program Files (x86)\Debugging Tools for Windows (x86)\WINXP\ntsdexts.dll]
0:000> !pe
Failed to find runtime DLL (clr.dll), 0x80004005
Extension commands need clr.dll in order to have something to do.
0:000> lm
start    end        module name
00400000 0040a000   locationswitch   (deferred)
6f720000 6f992000   AcLayers   (deferred)             
705c0000 70616000   mscoree    (deferred)             
70620000 706b9000   apphelp    (deferred)             
70960000 7096d000   sfc_os     (deferred)             
70970000 70973000   sfc        (deferred)             
70eb0000 70ec4000   mpr        (deferred)             
749e0000 74a3e000   winspool   (deferred)             
75560000 755cd000   sysfer     (deferred)             
755d0000 75623000   bcryptPrimitives   (deferred)             
75630000 75639000   CRYPTBASE   (deferred)             
75640000 7565d000   sspicli    (deferred)             
756d0000 7581f000   user32     (deferred)             
75830000 758ff000   KERNELBASE   (pdb symbols)          d:\debug_pdb\wkernelbase.pdb\AD71B4B6970B457EAAC4B4033A1DC8892\wkernelbase.pdb
75980000 759a5000   imm32      (deferred)             
75d30000 75edd000   setupapi   (deferred)             
75ee0000 75f90000   rpcrt4     (deferred)             
76030000 760b7000   oleaut32   (deferred)             
76260000 7629e000   sechost    (deferred)             
762a0000 762e1000   shlwapi    (deferred)             
762f0000 763f7000   gdi32      (deferred)             
76460000 765a0000   kernel32   (deferred)             
765a0000 766ee000   combase    (deferred)             
766f0000 767e7000   msctf      (deferred)             
767f0000 779b0000   shell32    (deferred)             
77a30000 77a6a000   cfgmgr32   (deferred)             
77a80000 77b3e000   msvcrt     (deferred)             
77c10000 77d78000   ntdll      (private pdb symbols)  d:\debug_pdb\wntdll.pdb\080480471A674FFFA11D05343C7475392\wntdll.pdb

最佳答案

转储似乎有问题。您假设它是 .NET 4 转储，但未加载 CLR。因此，让我们后退几步，从不同的角度来看待它。

先决条件检查

在开始调试之前做一些先决条件检查总是好的。让我们验证您对转储的所有假设是否正确。为此，您应该对收到的转储有一个大概的了解。

在进行任何分析之前我总是检查的事情:

1. 这真的是我的申请吗？
2. 它是官方(支持的)版本还是夜间构建？
3. 它是否在受支持的操作系统上运行？
4. 转储类型是否正确？
5. 转储的位数是否正确？
6. 是否发生了 .NET 异常？ (当然，仅针对 .NET 应用程序的问题)
7. 加载了哪个版本的 .NET？ (仅限 .NET)
8. 这是最近的转储吗？

这真的是我的申请吗？

有时，客户只是发送了错误的转储。他们在任何地方的磁盘上找到的东西。 如果是 WER(通过在线门户)，则会发生冲突，您可能会从 Microsoft 下载错误的转储。

|
lm fm MyAppName

检查应用程序的名称和安装目录。找到模块了吗？安装目录是至少合理还是完全关闭？

它是官方(支持的)版本吗？

lm vm MyAppName

根据您发布的产品列表检查文件版本和产品版本。

它是否在受支持的操作系统上运行？

vertarget

第一行应该给出操作系统。请注意，对于 32 位转储，它会说 x86，即使在 x64 上运行也是如此。

转储类型是否正确？

对于 .NET，您需要完整的内存转储。

||
.shell -ci ".dumpdebug" find "MiniDump"

第一个命令应该输出“Full memory user mini dump”，第二个命令应该包含“0002 MiniDumpWithFullMemory”。

*转储的位数是否正确？**

特别是对于 64 位 Windows 上的 32 位应用程序，这是必不可少的。

lm m wow64

如果找到 WOW64 模块，请求新的转储。

是否发生了 .NET 异常？

至少我们应该知道我们在追求什么。如果不是 .NET，最好提前知道。

.exr -1

输出应为 e0434f4d(CLR 异常)。只有在某些情况下，.NET 才会使用其他东西(例如 c0000005(访问冲突) 用于 NullReferenceException)。

加载了哪个版本的 .NET？

特别是如果你想重现这个问题。

lm vm clr
lm vm mscorwks

始终检查两者。可能会同时加载两个版本(在这种情况下，您可能无法分析转储)。

这是最近的转储吗？

客户发送的是新转储还是上周发送的垃圾转储？检查它，以免浪费数小时的调试时间。

.time

最终选择

至少不满足一个先决条件:未加载 CLR，因此很可能发生 native 异常。开始于

.exr -1

看看它可能是什么。

您的应用程序可能在加载任何 .NET 之前崩溃。这可能是由于注入(inject)到进程中的一些 Hook DLL。

也许它找不到引用的 DLL，因为它没有安装、删除或程序是从不同的工作目录运行的。

.shell -ci "!peb" find "CurrentDirectory"

转储是使用 SysInternals ProcDump 获取的使用选项 -e1 并在初始断点处停止(这对许多开发人员来说是意想不到的)。

关于.net - 无法在 windbg 中调试 .net 转储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27035145/