我收到一份 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
最佳答案
转储似乎有问题。您假设它是 .NET 4 转储，但未加载 CLR。因此，让我们退后几步，从不同的角度来看待它。
前提条件检查
在开始调试之前进行一些前提条件检查总是好的。让我们验证一下您关于转储的所有假设是否正确。为此，您应该对收到的转储有一个粗略的了解。
在进行任何分析之前我总是检查的事情:
- 这真的是我的应用程序吗？
- 它是官方(支持)版本还是夜间版本？
- 它是否在受支持的操作系统上运行？
- 转储类型正确吗？
- 转储的位数是否正确？
- 是否发生.NET异常？ (当然，仅针对 .NET 应用程序的问题)
- 加载了哪个版本的.NET？ (仅限.NET)
- 这是最近的转储吗？
这真的是我的应用程序吗？
有时，客户只是发送了错误的转储。他们在磁盘上任何地方都能找到的东西。 如果出现 WER(通过在线门户)，则会发生冲突，您可能会从 Microsoft 下载错误的转储。
|
lm fm MyAppName
检查应用程序的名称和安装目录。模块找到了吗？安装目录至少是合理的还是完全关闭的？
它是官方(支持)版本吗？
lm vm MyAppName
根据已发布产品列表检查文件版本和产品版本。
它是否在受支持的操作系统上运行？
vertarget
第一行应该给出操作系统。请注意，即使在 x64 上运行，对于 32 位转储，它也会显示 x86。
转储类型正确吗？
对于 .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 才会使用其他内容(例如，对于 NullReferenceException 使用 c0000005(访问冲突))。
加载了哪个版本的.NET？
特别是如果您想重现该问题。
lm vm clr
lm vm mscorwks
始终检查两者。可能会发生两个版本都已加载的情况(在这种情况下，您可能无法分析转储)。
这是最近的转储吗？
客户是否发送了新的转储或上周相同的蹩脚转储？在浪费数小时的调试时间之前检查一下。
.time
最终选项
至少不满足一个先决条件:未加载 CLR，因此可能发生 native 异常。开始于
.exr -1
看看它可能是什么。
您的应用程序有可能在加载任何 .NET 之前崩溃。这可能是由于一些 Hook DLL 被注入(inject)到进程中造成的。
也许它找不到引用的DLL，因为它没有安装、删除或者程序是从不同的工作目录运行的。
.shell -ci "!peb" find "CurrentDirectory"
转储是使用 SysInternals ProcDump 获取的使用选项 -e1 并在初始断点处停止(这对许多开发人员来说是意料之外的)。
关于.net - 无法在 Windbg 中调试 .net 转储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27035145/