我将 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时，它会从网络加载正确的“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.
最佳答案
在使用站点的小型转储进行调试时，我经常遇到此问题。我不确定你的情况是如何发生的。通常，当进行转储时加载的 CLR 版本在调试计算机上不可用时，就会发生这种情况。就您而言，它们是同一台机器，因此它们应该都可以正常工作。我确信会有其他人能够准确解释为什么不是这样。
与此同时，以下是我对网站转储所做的操作。 Windbg 正在寻找 mscordacwks.dll 的“正确版本”。所以我们给它那个版本并告诉它去哪里寻找它。
首先 - 如果我通过删除 mscordacwks.dll 来欺骗所有这些，windbg 就会关闭并从 Microsoft 符号服务器加载它，因此请确保您的符号设置正确以从 Microsoft 符号服务器下载符号并提供又来了。
现在 - 假设这不起作用，请准确检查哪个版本是“正确的版本”。使用“lm v clr”列出模块信息，并检查实际加载的 CLR 版本。我的是4.0.30319.239。好的 - 现在找到该版本的 mscordacwks.dll。假设它可以在计算机上正常安装的 .NET Framework 中找到(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 知道它在寻找什么，并告诉它您将其放在哪里。
如果仍然不起作用，请尝试“.cordll -ve -u -l”和“!sym嘈杂”以打开cordll负载和符号服务器的详细日志记录，然后再次尝试!CLRStack 。也许这两个命令的输出会准确地告诉您它正在尝试加载什么，并且您可以弄清楚为什么它不会这样做...
关于debugging - WinDbg x64 : Cannot debug a crash dump - failed to load data access DLL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7093494/