WinDbg x64：无法调试崩溃转储 - 无法加载数据访问DLL [英] WinDbg x64: Cannot debug a crash dump - failed to load data access DLL
问题描述
该程序被编译为任何CPU，我使用WinDbg x64倾倒。现在我再次在同一台电脑上打开WinDbg x64并打开崩溃转储。这是它所说的：
加载转储文件[C：\crashdump.dmp]
用户迷你转储文件具有完整内存：只有应用程序数据可用
符号搜索路径是：SRV * c：\symbols * http：//msdl.microsoft.com/download/symbols
可执行搜索路径是：
Windows 7版本7601（Service Pack 1）MP（8 procs）免费x64
产品：WinNt，suite：SingleUserTS
机器名称：
调试会话时间： 15 10：24：57.000 2011（UTC + 1:00）
系统正常运行时间：17天0：54：39.021
处理正常运行时间：12天14：01：31.000
.... .................................................. ..........
.................................... ...........................
此转储文件存储在其中的兴趣异常。
可以通过.ecxr访问存储的异常信息。
（1be0.b78）：访问冲突 - 代码c0000005（第一次/第二次机会不可用）
***警告：符号时间戳错误0x4dd2333e 0x4da4281c为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，并在
对LoadLibrary（sos clr）的调用失败，Win32错误0n2
系统找不到指定的文件。
请检查您的调试器配置和/或网络访问。
尝试使用.loadby sos clr，它的工作原理。现在我想看到堆栈与！clrstack，并坚持在这里：
无法加载数据访问DLL，0x80004005
验证1）您最近有一个调试器的构建（6.2.14或更高版本）
2）与您的版本的clr.dll匹配的文件mscordacwks.dll在$目录$ $ $ $ $ $
3），或者如果您正在调试转储文件，请验证文件
mscordacwks_< arch> _< arch> _< version> .dll在您的符号路径上。
4）您正在调试与转储文件相同的架构。
例如，必须在IA64
机器上调试IA64转储文件。
您还可以运行调试器命令.cordll来控制调试器的
装载的mscordacwks.dll。 .cordll -ve -u -l会做一个详细的重新加载。
如果成功，SOS命令应该重试。
如果您正在调试minidump，您需要确保您的可执行文件
路径也指向clr.dll。
我尝试过.symfix和.reload：
0：027> .symfix
0：027> .reload
.................. ***警告：符号时间戳错误0x4dd2333e 0x4da4281c为clr.dll
....... .......................................
....... .................................................. ......
卡住。在WinDgb下运行进程的同时，我可以暂停执行，加载SOS
并成功执行！clrstack命令。
任何想法？
谢谢。
更新 - 按照第二个答案提供的步骤仍然无效。
1）我的符号路径：SRV * c：\symbols * http：//msdl.microsoft.com/download/symbols; srv *
2）CLR loading：4.0.30319。 237 ：
0： 027 lm v clr
未知选项'r'
开始结束模块名称
00000000`77b60000 00000000`77d09000 ntdll（pdb符号）c：\symbols\\\
tdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ ntdll.pdb
加载的符号图像文件：ntdll.dll
图像路径：C：\Windows\System32\\\
tdll.dll
图像名称：ntdll.dll
时间戳：星期六11月20日13:11:21 2010（4CE7C8F9）
校验码：001B55EA
ImageSize：001A9000
文件版本：6.1.7601.17514
产品版本：6.1.7601.17514
文件标志：0（掩码3F）
文件操作系统：40004 NT Win32
文件类型：2.0 Dll
文件日期：00000000.00000000
翻译：0409.04b0
公司名称： Microsoft Corporation
ProductName：Microsoft®Windows®操作系统
InternalName：ntdll.dll
OriginalFilename：ntdll.dl l
ProductVersion：6.1.7601.17514
FileVersion：6.1.7601.17514（win7sp1_rtm.101119-1850）
文件描述：NT层DLL
LegalCopyright：©Microsoft Corporation。版权所有。
000007fe`e9fb0000 000007fe`ea915000 clr＃（pdb symbols）c：\symbols\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
加载的符号图像文件：clr.dll
图像路径：C：\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
图像名称：clr.dll
时间戳记：星期二5月17日09:35:10 2011（4DD2333E）
CheckSum：00967144
ImageSize：00965000
文件版本：4.0.30319.237
产品版本：4.0.30319.237
文件标志：8（Mask 3F）私人
文件操作系统：4未知Win32
文件类型：2.0 Dll
文件日期：00000000.00000000
翻译：0409.04b0
公司名称：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
文件描述：Microsoft .NET运行时通用语言运行时 - WorkStation
LegalCopyright：©Microsoft Corporation。版权所有。
评论：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
5）
0：027> ; .cordll -ve -u -l
CLR DLL状态：无负载尝试
6）
0：027> ！sym嘈杂
嘈杂模式 -
上的符号提示0：027> .restart
加载转储文件[C：\crashdump.dmp]
具有完整内存的用户迷你转储文件：只有应用程序数据可用
DBGHELP：符号搜索路径：srv *; srv * c：\symbols * http：//msdl.microsoft.com/download/symbols
DBGHELP：符号搜索路径：缓存*; SRV * http：//msdl.microsoft。 com / download / symbols; srv * c：\symbols * http：//msdl.microsoft.com/download/symbols
DBGHELP：符号搜索路径：缓存*; SRV * http：//msdl.microsoft。 com / download / symbols; srv * c：\symbols * http：//msdl.microsoft.com/download/symbols
符号搜索路径是：srv *; SRV * c：\symbols * http：/ /msdl.microsoft.com/download/symbols
可执行搜索路径是：
Windows 7版本7601（Service Pack 1）MP（8 procs）免费x64
产品：WinNt，suite：SingleUserTS
机器名称：
调试会话时间：Mon Aug 15 10：24：57.000 2011（UTC + 1:00）
系统正常运行时间：17天0：54：39.021
进程正常运行时间：12天14：01：31.000
..................................... ... ........................
..................... .........................................
DBGHELP：ntdll - public符号
C：\Program Files\Debugging Tools for Windows（x64）\sym\\\
tdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\\\
tdll.pdb
DBGHELP：符号搜索路径：cache *; SRV * http：//msdl.microsoft.com/download/symbols; srv * c：\symbols * http：//msdl.microsoft.com/download/symbols
DBGHELP：符号搜索路径：缓存*; SRV * http：//msdl.microsoft.com/download/symbols; srv * c：\symbols * http：//msdl.microsoft.com/download/symbols
此转储文件存储的兴趣例外它。
可以通过.ecxr访问存储的异常信息。
（1be0.b78）：访问冲突 - 代码c0000005（第一次/第二次机会不可用）
***警告：符号时间戳错误0x4dd2333e 0x4da4281c为clr.dll
DBGHELP：clr - 公共符号
C：\Program Files\Debugging 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）
code> 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从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缓存到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
无法加载数据访问DLL，0x80004005
验证1）您最近有一个调试器的构建（6.2.14或更高版本）
2）与版本目录中的
匹配的文件mscordacwks.dll是
3），或者如果您正在调试转储文件，请验证文件
mscordacwks_< arch> _< arch> _< version> .dll在您的符号路径上。
4）您正在调试与转储文件相同的架构。
例如，必须在IA64
机器上调试IA64转储文件。
您还可以运行调试器命令.cordll来控制调试器的
装载的mscordacwks.dll。 .cordll -ve -u -l会做一个详细的重新加载。
如果成功，SOS命令应该重试。
如果您正在调试minidump，您需要确保您的可执行文件
路径也指向clr.dll。
当从站点调试minidumps时，我经常打这个。不知如何发生在你的情况下，我不确定。通常情况下，当您的调试机器无法使用转储时加载的CLR版本。在你的情况下，他们是同一台机器，所以应该可能只是工作。我确定会有其他人能够明确地解释为什么不这样做。
同时，这里是我用我的网站转储。 Windbg正在寻找mscordacwks.dll的正确版本。所以我们给它该版本，并告诉它在哪里寻找。
首先 - 如果我欺骗所有这一切，通过删除mscordacwks.dll，windbg关闭，从微软符号服务器加载它，所以确保您的符号设置正确，从微软符号服务器下载符号，并再次执行。
现在 - 假设这没有工作，检查哪个版本是正确的版本。使用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：\符号\_Images），所以windbg知道你放在哪里。
你现在已经获得了正确版本的mscordacwks，并将其重命名为Windbg知道它正在寻找什么，并告诉你你把它放在哪里。
如果这个STILL不起作用，那么尝试.cordll -ve -u -l 以及！sym嘈杂打开cordll加载和符号服务器的详细日志记录，然后再次尝试！CLRStack。也许这两个命令的输出会告诉你它正在尝试加载什么，你可以弄清楚为什么它不会这样做...
I attached WinDbg to a running process and had the process crashed (I have a separate question re. that case). Once the program crashed, WinDbg stopped and allowed me to debug the program. I took a crash dump for further investigation with a command ".dump /ma".
The program was compiled as "Any CPU" and I used WinDbg x64 to take the dump. Now I open WinDbg x64 on the same computer again and open the crash dump. Here is what it says:
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=????????
Then I try to load SOS by ".load sos clr" and it errors in:
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.
Trying with ".loadby sos clr" and it works. Now I want to see the stack with "!clrstack" and stick here:
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.
I tried ".symfix" and ".reload":
0:027> .symfix
0:027> .reload
..................*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
..............................................
...............................................................
Stuck. At the same time when the process is running under WinDgb I can pause the execution, load SOS and execute "!clrstack" command successfully.
Any ideas? Thank you.
UPDATE - Followed the steps provided in the second answer, still doesn't work.
1) My Symbol Path: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;srv*
2) CLR loaded: 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" has version 4.0.30319.239
4) I found that when I load the dump into WinDbg it loads the correct "mscordacwks.dll" from the web, thus in the folder "C:\symbols\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000" I have the file "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.
I hit this regularly when debugging with minidumps from site. Quite how it's happened in your case I'm not sure. Usually it happens when the version of CLR that was loaded when the dump was taken is not available on your debugging machine. In your case, they're the same machine, so it should all probably just work. I'm sure there will be others who can explain exactly why it isn't.
In the mean time, here's what I do with my site dumps. Windbg is looking for "the right version" of mscordacwks.dll. So we give it that version, and tell it where to look for it.
First - if I spoof all of this, by deleting mscordacwks.dll, windbg goes off and loads it from the microsoft symbol server, so do make sure your symbols are set up correctly to download symbols from the microsoft symbol server and give it another go.
Now - assuming that didn't work, check exactly which version is the "right version". List the module info with "lm v clr" and check your CLR version that is ACTUALLY loaded. Mine is 4.0.30319.239. Ok - now find that version of mscordacwks.dll. Lets assume it can be found in the normal .NET framework installation on your machine (C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Do check the version matches exactly (right click, properties etc)! Take it and put it in a safe place (I use D:\Symbols\_Images). Follow the instructions that windbg gave you on renaming the file. mscordacwks_.dll would be mscordacwks_AMD64_AMD64_4.0.30319.239.dll.
Now set up your executable image path (".exepath D:\Symbols\_Images") so windbg knows where you've put it.
You've now got "the right version of mscordacwks", and renamed it so that Windbg knows what it's looking for, and told it where you've put it.
If that STILL isn't working, then try ".cordll -ve -u -l" and also "!sym noisy" to turn on verbose logging of both the cordll load and the symbol server, then try !CLRStack again. Maybe the output of those two commands will tell you exactly what it's trying to load and you can figure out why it won't do it...
这篇关于WinDbg x64：无法调试崩溃转储 - 无法加载数据访问DLL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
