windbg无法debugging.net转储

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

“无法find运行时DLL(clr.dll),0x80004005扩展命令需要clr.dll才能有所作为。

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

当我使用“LM”命令列出所有加载的模块,我没有在模块列表中find“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未加载。 所以让我们回过头来从不同的角度来看它。

先决条件检查

在开始调试之前进行一些先决条件检查总是很好的。 让我们来验证一下你对转储的所有假设是否正确。 要做到这一点,你应该有一个关于你正在接受转储的粗略想法。

在做任何分析之前,我经常检查的东西:

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

这真的是我的应用程序吗?

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

 | lm fm MyAppName 

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

这是一个官方(支持)的版本?

 lm vm MyAppName 

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

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

 vertarget 

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

这是正确的转储类型吗?

对于.NET,你需要一个完整的内存转储。

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

第一个命令应该输出“全内存用户迷你转储”,第二个应该包括“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 SysInternals ProcDump进行转储,并在初始断点处停止 (这对于许多开发人员来说是意想不到的)。