WinDbg x64: не удается отладить аварийный дамп - не удалось загрузить DLL доступа к данным
Я подключил WinDbg к работающему процессу и у него произошел сбой (у меня есть отдельный вопрос по этому поводу). После сбоя программы WinDbg остановился и позволил мне отладить программу. Я взял аварийный дамп для дальнейшего исследования с помощью команды.dump /ma.
Программа была скомпилирована как "Любой процессор", и я использовал 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=????????
Затем я пытаюсь загрузить SOS с помощью ".load sos clr", и это ошибки в:
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.
4 ответа
Я регулярно сталкиваюсь с этим при отладке мини-дампов с сайта. Как это случилось в вашем случае, я не уверен. Обычно это происходит, когда версия 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 знал, что она ищет, и сказали, где вы ее поместили.
Если этот STILL не работает, попробуйте ".cordll -ve -u -l", а также "! Sym noisy", чтобы включить подробное ведение журнала как загрузки шнура, так и сервера символов, затем попробуйте!CLRStack снова. Возможно, результат этих двух команд точно скажет вам, что он пытается загрузить, и вы сможете понять, почему он этого не сделает...
Я просто потратил день на отладку множества случаев, когда мы сталкивались с этим сценарием. SOS+CLR в том же окне, что и сбой, не удалось загрузить в WinDbg, и "lm v" сообщил о двух разных версиях для одного и того же модуля:
0: 011> lm vM * clr.dll
имя начала и конца модуля
000007fe`f2f50000 000007fe`f38b0000 clr # (символы pdb) c:\symbols\clr.pdb\EDFF900AC9B94C1D9B32696A7759891A2\clr.pdb
Загружен файл изображения символа: clr.dll
Путь к изображению: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Название изображения: clr.dll
Отметка времени: вс 21 апреля 03:36:04 2013 (5173C114)
Контрольная сумма: 0095F379
Размер изображения: 00960000
Версия файла: 4.0.30319.18052
Версия продукта: 4.0.30319.18052
Флаги файлов: 8 (Маска 3F) Приват
Файл ОС: 4 Неизвестный Win32
Тип файла: 2.0 Dll
Дата файла: 00000000.00000000
Переводы: 0409.04b0
CompanyName: корпорация Майкрософт
ProductName: Microsoft® .NET Framework
InternalName: clr.dll
Исходное имя файла: clr.dll
ProductVersion: 4.0.30319.18047
FileVersion: 4.0.30319.18047, созданный: FX45RTMGDR
PrivateBuild: DDBLD320
Описание файла: общеязыковая среда выполнения Microsoft.NET - WorkStation
LegalCopyright: © Корпорация Microsoft. Все права защищены.
Комментарии: Flavor=Retail Детали поддержки
Метка времени (0x5173C114), контрольная сумма (0x0095F379) и версия (4.0.30319.18052), хранящиеся в структуре MINIDUMP_MODULE в потоке списка модулей minidump, предназначались для более новой CLR. Взломав файл минидампа сам и глядя прямо на данные потока:
MINIDUMP_MODULE: (упаковка: 8 размер: 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: (упаковка: 8 размер: 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 28 марта 23:12:30 2013 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Глядя на сырую память в аварийном дампе, куда загружается clr.dll, вы можете увидеть контрольную сумму (0x00965F80) и метку времени (0x515530CE) версии 4.0.30319.18047:
0: 011> дБ 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 является программой canno 000007fe`f2f50060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t для запуска в 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 будет 79 85 46 be-81 f2 fa будет 74 85 46 be ....yF.... tF 000007fe`f2f500a0 74 fd c5 будет 73 85 46 be-74 fd c2 be c9 85 46 be t...sFt....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 beee 41 89 be 78 85 46 be .A..kF.A..xF 000007fe`f2f500d0 ee 41 8b be 64 85 46 be-7d 85 47 be ca 87 46 be .A..dF}.G...F. 000007fe`f2f500e0 81 f2 ff быть 76 85 46 beeee 41 9e be 70 87 46 be ....vF.A..pF 000007fe`f2f500f0 ee 41 8c быть 7c 85 46 beeee 8 8f быть 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 года.
Так что теперь у нас есть мини-дамп с противоречивой информацией о том, какая версия clr.dll действительно использовалась.
Что вызвало это
Я также узнал, что наш ИТ-отдел недавно выпустил несколько обновлений Windows, поэтому:
- Во время работы приложения было установлено обновление для CLR.
- Файл в C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ был обновлен до более новой версии (4.0.30319.18052)
- Приложение разбилось
- MiniDumpWriteDump очевидно использовал информацию о файле на диске при сохранении списка модулей в файле аварийного дампа (4.0.30319.18052)
- WinDbg не смог сопоставить версию, помеченную в аварийном дампе, с тем, что было в памяти процесса, поскольку в нем была противоречивая информация.
Чтобы убедиться в этом, я вручную изменил запись MINIDUMP_MODULE для clr.dll, чтобы изменить контрольную сумму, метку времени и версию с 18052 на 18047. После перезагрузки взломанного файла.dmp в WinDbg и установки exepath на соответствующие библиотеки sos+clr, Мне удалось успешно выполнить команды SOS и получить действительный след стека.
Нижняя линия
По сути, мы получили файл мини-дампов, который содержит противоречивую информацию о том, какая версия clr.dll загружена в процесс, не позволяя SOS определить правильный механизм clr. Вероятно, это ошибка в MiniDumpWriteDump, поскольку она сохраняет файл аварийного дампа. Но должно происходить только тогда, когда базовая версия CLR была обновлена во время работы вашего приложения.
Является ли процесс, который вы пытаетесь отладить, 32-разрядным? Что говорит список процессов менеджера задач? Если это 32-битный процесс, то вам нужно использовать 32-битный windbg. В противном случае я не понимаю, почему .load sos clr должен потерпеть неудачу.
PS: (windbg noob alert), поэтому я прошу прощения, если это звучит неубедительно. Просто пытаюсь помочь.
Похоже, вы сделали пользовательскую установку windbg и не выбрали все необходимые вам расширения. Ошибка Win32 n2 обычно является признаком этой проблемы.