Question

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

“无法找到运行时DLL（clr.dll），0x80004005 扩展命令需要clr.dll才能完成任务。“

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

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

（ locationswitch 是我的应用程序，它在.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

Answer 1

转储似乎有问题。您假设它是一个.NET 4转储，但没有加载CLR。所以，让我们退一步，从不同的角度看待它。

前提条件检查

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

在进行任何分析之前我经常检查的事情：

这真的是我的申请吗？
是官方（支持）版本还是夜间版本？
它是否在受支持的操作系统上运行？
这是正确的转储类型吗？
转储是否正确？
是否发生了.NET异常？（当然只有.NET应用程序的问题）
加载了哪个版本的.NET？（仅限.NET）
这是最近的转储吗？

这是我的申请吗？

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

|
lm fm MyAppName

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

是官方（支持）版本吗？

lm vm MyAppName

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

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

vertarget

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

这是正确的转储类型吗？

对于.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 exception)。只有在某些情况下.NET才会使用其他内容（例如c0000005 (Access violation)用于NullReferenceException）。

加载了哪个版本的.NET？

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

lm vm clr
lm vm mscorwks

始终检查两者。可能会发生两个版本的加载（在这种情况下，您可能无法分析转储）。

这是最近的转储吗？

客户是否从上周发送了新转储或同样糟糕的转储？在你失去调试时间之前检查它。

.time

最终选项

至少满足一个前提条件：未加载CLR，因此可能发生本机异常。从

.exr -1

看看它可能是什么。

在加载任何.NET之前，您的应用程序可能会崩溃。这可能是由于一些挂钩DLL 被注入到进程中。

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

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

转储是使用带有选项-e1的{{3}}进行的，并且停留在初始断点处（这对于许多开发人员而言是意外的）。

无法在windbg中调试.net转储

1 个答案:

前提条件检查

最终选项