我将WinDbg附加到正在运行的进程并让进程崩溃（我有一个单独的问题。那个案例）。程序崩溃后，WinDbg停止并允许我调试程序。我使用命令“.dump / ma”进行了故障转储以进一步调查。
该程序被编译为“任何CPU”，我使用WinDbg x64进行转储。现在我再次在同一台计算机上打开WinDbg x64并打开故障转储。以下是它的说法：
Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1be0.b78): Access violation - code c0000005 (first/second chance not available)
*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
clr!WKS::gc_heap::find_first_object+0x92:
000007fe`ea129a1d f70100000080 test dword ptr [rcx],80000000h ds:00000000`00003d80=????????
然后我尝试通过“.load sos clr”加载SOS，并且错误在：
The call to LoadLibrary(sos clr) failed, Win32 error 0n2
"The system cannot find the file specified."
Please check your debugger configuration and/or network access.
尝试使用“.loadby sos clr”并且它有效。现在我想看看带有“！clrstack”的堆栈并坚持下去：
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
我试过“.symfix”和“.reload”：
0:027> .symfix
0:027> .reload
..................*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
..............................................
...............................................................
卡住。在WinDgb下运行进程的同时，我可以暂停执行，加载SOS 并成功执行“！clrstack”命令。
有什么想法吗？ 谢谢。
更新 - 按照第二个答案中提供的步骤操作，仍然无效。
1）我的符号路径：SRV * c：\ symbols * http：//msdl.microsoft.com/download/symbols; srv *
2）装载CLR：4.0.30319。 237 ：
0:027> lm v clr
Unknown option 'r'
start end module name
00000000`77b60000 00000000`77d09000 ntdll (pdb symbols) c:\symbols\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb
Loaded symbol image file: ntdll.dll
Image path: C:\Windows\System32\ntdll.dll
Image name: ntdll.dll
Timestamp: Sat Nov 20 13:11:21 2010 (4CE7C8F9)
CheckSum: 001B55EA
ImageSize: 001A9000
File version: 6.1.7601.17514
Product version: 6.1.7601.17514
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 6.1.7601.17514
FileVersion: 6.1.7601.17514 (win7sp1_rtm.101119-1850)
FileDescription: NT Layer DLL
LegalCopyright: © Microsoft Corporation. All rights reserved.
000007fe`e9fb0000 000007fe`ea915000 clr # (pdb symbols) c:\symbols\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
Timestamp: Tue May 17 09:35:10 2011 (4DD2333E)
CheckSum: 00967144
ImageSize: 00965000
File version: 4.0.30319.237
Product version: 4.0.30319.237
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.235
FileVersion: 4.0.30319.235 (RTMGDR.030319-2300)
PrivateBuild: DDBLD240
FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
3）“C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ mscordacwks.dll”版本为4.0.30319。 239
4）我发现当我将转储加载到WinDbg时，它会从Web加载正确的“mscordacwks.dll”，因此在“C：\ symbols \ mscordacwks_AMD64_AMD64_4.0.30319.237.dll \ 4DD2333E965000”文件夹中文件“mscordacwks_AMD64_AMD64_4.0.30319.237.dll”。
5）
0:027> .cordll -ve -u -l
CLR DLL status: No load attempts
6）
0:027> !sym noisy
noisy mode - symbol prompts on
0:027> .restart
Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available
DBGHELP: Symbol Search Path: srv*;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
DBGHELP: ntdll - public symbols
C:\Program Files\Debugging Tools for Windows (x64)\sym\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1be0.b78): Access violation - code c0000005 (first/second chance not available)
*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
DBGHELP: clr - public symbols
C:\Program Files\Debugging Tools for Windows (x64)\sym\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
clr!WKS::gc_heap::find_first_object+0x92:
000007fe`ea129a1d f70100000080 test dword ptr [rcx],80000000h ds:00000000`00003d80=????????
7）
0:027> !clrstack
SYMSRV: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll not found
SYMSRV: mscordacwks_AMD64_AMD64_4.0.30319.237.dll from http://msdl.microsoft.com/download/symbols: 502892 bytes - copied
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll cached to C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD233F317b000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD233F317b000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll - OK
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
答案 0 :(得分：17)
我在使用网站的minidump进行调试时经常点击这个。在你的情况下发生了怎么回事我不确定。通常，当在调试计算机上找不到转储时加载的CLR版本时，就会发生这种情况。在你的情况下，它们是同一台机器，所以它应该都可能正常工作。我相信会有其他人可以解释为什么不是。
与此同时，这是我对网站转储的处理方式。 Windbg正在寻找mscordacwks.dll的“正确版本”。所以我们给它那个版本，并告诉它在哪里寻找它。
首先 - 如果我欺骗所有这些，通过删除mscordacwks.dll，windbg会关闭并从微软符号服务器加载它，所以请确保您的符号设置正确以从微软符号服务器下载符号并给出另一个去。
现在 - 假设不起作用，请确切检查哪个版本是“正确的版本”。使用“lm v clr”列出模块信息，并检查实际加载的CLR版本。我的是4.0.30319.239。好的 - 现在找到mscordacwks.dll的那个版本。让我们假设它可以在你的机器上的普通.NET框架安装中找到（C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319）。请检查版本是否完全匹配（右键单击，属性等）！拿它把它放在一个安全的地方（我使用D：\ Symbols \ _Images）。按照windbg给您重命名文件的说明进行操作。 mscordacwks_ .dll将是mscordacwks_AMD64_AMD64_4.0.30319.239.dll。
现在设置你的可执行图像路径（“.exepath D：\ Symbols \ _Images”），以便windbg知道你把它放在哪里。
你现在已经拥有了“正确版本的mscordacwks”，并将其重命名，以便Windbg知道它正在寻找什么，并告诉它你把它放在哪里。
如果STILL无效，请尝试“.cordll -ve -u -l”以及“！sym noisy”打开cordll加载和符号服务器的详细日志记录，然后再次尝试！CLRStack 。也许这两个命令的输出会告诉你它正在尝试加载什么，你可以弄清楚为什么它不会这样做...
答案 1 :(得分：12)
我花了一天时间调试了一堆我们遇到这种情况的案例。与崩溃相同的盒子上的SOS + CLR无法在WinDbg中加载，“lm v”报告了同一模块的两个不同版本：
0:011> lm vM *clr.dll
start end module name
000007fe`f2f50000 000007fe`f38b0000 clr # (pdb symbols) c:\symbols\clr.pdb\EDFF900AC9B94C1D9B32696A7759891A2\clr.pdb
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
Timestamp: Sun Apr 21 03:36:04 2013 (5173C114)
CheckSum: 0095F379
ImageSize: 00960000
File version: 4.0.30319.18052
Product version: 4.0.30319.18052
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.18047
FileVersion: 4.0.30319.18047 built by: FX45RTMGDR
PrivateBuild: DDBLD320
FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
存储在minidump的module-list-stream中的MINIDUMP_MODULE结构中的文件Timestamp（0x5173C114），Checksum（0x0095F379）和Version（4.0.30319.18052）适用于较新的CLR。我自己打开minidump文件并直接查看流数据：
MINIDUMP_MODULE : (pack:8 size:112)
+0x000 .BaseOfImage UInt64 : 8791579230208 (0x7FEF2F50000)
+0x008 .SizeOfImage UInt32 : 9830400 (0x960000)
+0x00C .CheckSum UInt32 : 9827193 (0x95F379)
+0x010 .TimeDateStamp UInt32 : 1366540564 (0x5173C114)
+0x014 .ModuleNameRva UInt32 : 107828 (0x1A534)
+0x018 .VersionInfo tagVS_FIXEDFILEINFO : (pack:8 size:52)
+0x000 .dwSignature UInt32 : 4277077181 (0xFEEF04BD)
+0x004 .dwStrucVersion UInt32 : 65536 (0x10000)
+0x008 .dwFileVersionMS UInt32 : 262144 (0x40000)
+0x00C .dwFileVersionLS UInt32 : 1987004036 (0x766F4684)
从dwFileVersionMS中分出高低字，我们得到4和0 将dwFileVersionLS中的高位和低位分开，我们得到30319和18052.
使用dumpchk.exe，查看PEB中的模块详细信息，我们可以看到一个不同的时间戳（0x515530CE），一个实际上对应于旧版（18047）的版本：
7fef2f50000 515530ce Mar 28 23:12:30 2013 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
查看加载了clr.dll的崩溃转储中的原始内存，您可以看到版本4.0.30319.18047的校验和（0x00965F80）和时间戳（0x515530CE）：
0:011> db 000007fe`f2f50000 000007fe`f2f50000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ.............. 000007fe`f2f50010 b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00 ........@....... 000007fe`f2f50020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000007fe`f2f50030 00 00 00 00 00 00 00 00-00 00 00 00 18 01 00 00 ................ 000007fe`f2f50040 0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68 ........!..L.!Th 000007fe`f2f50050 69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f is program canno 000007fe`f2f50060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t be run in DOS 000007fe`f2f50070 6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00 mode....$....... 0:011> db 000007fe`f2f50080 39 e4 28 ed 7d 85 46 be-7d 85 46 be 7d 85 46 be 9.(.}.F.}.F.}.F. 000007fe`f2f50090 81 f2 f8 be 79 85 46 be-81 f2 fa be 74 85 46 be ....y.F.....t.F. 000007fe`f2f500a0 74 fd c5 be 73 85 46 be-74 fd c2 be c9 85 46 be t...s.F.t.....F. 000007fe`f2f500b0 ee 41 8d be 7f 85 46 be-e3 25 81 be 7c 85 46 be .A....F..%..|.F. 000007fe`f2f500c0 ee 41 88 be 6b 85 46 be-ee 41 89 be 78 85 46 be .A..k.F..A..x.F. 000007fe`f2f500d0 ee 41 8b be 64 85 46 be-7d 85 47 be ca 87 46 be .A..d.F.}.G...F. 000007fe`f2f500e0 81 f2 ff be 76 85 46 be-ee 41 9e be 70 87 46 be ....v.F..A..p.F. 000007fe`f2f500f0 ee 41 8c be 7c 85 46 be-ee 41 8f be 7c 85 46 be .A..|.F..A..|.F. 0:011> 000007fe`f2f50100 ee 41 8a be 7c 85 46 be-52 69 63 68 7d 85 46 be .A..|.F.Rich}.F. 000007fe`f2f50110 00 00 00 00 00 00 00 00-50 45 00 00 64 86 06 00 ........PE..d... 000007fe`f2f50120 ce 30 55 51 00 00 00 00-00 00 00 00 f0 00 22 20 .0UQ.........." 000007fe`f2f50130 0b 02 0b 00 00 90 69 00-00 c2 2b 00 00 00 00 00 ......i...+..... 000007fe`f2f50140 40 51 13 00 00 10 00 00-00 00 f5 f2 fe 07 00 00 @Q.............. 000007fe`f2f50150 00 10 00 00 00 02 00 00-06 00 00 00 0a 00 00 00 ................ 000007fe`f2f50160 06 00 00 00 00 00 00 00-00 e0 95 00 00 04 00 00 ................ 000007fe`f2f50170 80 5f 96 00 02 00 60 01-00 00 10 00 00 00 00 00 ._....`.........
我也在内存中跳了起来，看了内存中的Version资源，看到了18047版本的字符串。
所以现在我们有一个minidump，其中包含有关clr.dll实际使用版本的相互矛盾的信息。
我还发现我们的IT部门最近推出了一些Windows更新，所以：
为验证这一点，我手动修改了clr.dll的MINIDUMP_MODULE条目，将Checksum，Timestamp和Version从18052更改为18047.在WinDbg中重新加载被破解的.dmp文件并将exepath设置为正确的sos + clr dlls，我能够成功执行sos命令并获得有效的堆栈跟踪。
我们基本上最终得到了一个minidump文件，该文件包含有关哪个版本的clr.dll加载到进程中的冲突信息，从而阻止SOS识别正确的clr引擎。 这可能是MiniDumpWriteDump中的一个错误，因为它会保存崩溃转储文件。但是，只有在应用程序运行时更新了CLR的后备版本时才会发生。
答案 2 :(得分：0)
听起来像是自定义安装windbg并没有选择所需的所有扩展名。 Win32错误n2通常是此问题的一个标志。
答案 3 :(得分：0)
您正在尝试调试32位的进程吗？任务管理器 - 进程列表说什么？如果它的32位进程那么你需要使用32位windbg。
否则，我不明白为什么.load sos clr会失败。
ps :( windbg noob alert），所以如果这听起来很蹩脚，我道歉。只是想帮忙。