WinDbg x64: не удается отладить аварийный дамп - не удалось загрузить DLL доступа к данным - PullRequest
20 голосов
/ 17 августа 2011

Я подключил 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 ]

17 голосов
/ 24 октября 2011

Я регулярно сталкиваюсь с этим при отладке мини-дампов с сайта.Как это случилось в вашем случае, я не уверен.Обычно это происходит, когда версия 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 снова.Возможно, результат этих двух команд точно скажет вам, что он пытается загрузить, и вы сможете понять, почему он этого не сделает ...

12 голосов
/ 13 августа 2013

Я просто потратил день на отладку множества случаев, когда мы сталкивались с этим сценарием.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:     <b>4.0.30319.18052</b>
    Product version:  <b>4.0.30319.18052</b>
    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:   <b>4.0.30319.18047</b>
    FileVersion:      <b>4.0.30319.18047</b> built by: FX45RTMGDR
    PrivateBuild:     DDBLD320
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

Сведения о поддержке

временная метка файла (0x5173C114), контрольная сумма (0x0095F379) и версия (4.0.30319.18052), хранящиеся в структуре MINIDUMP_MODULE в потоке списка модулей minidump, предназначались для более новой CLR.Взломав файл минидампа сам и взглянув непосредственно на данные потока:

MINIDUMP_MODULE : (pack:8 size:112) 
  +0x000 .BaseOfImage UInt64 : 8791579230208 (0x7FEF2F50000)
  +0x008 .SizeOfImage UInt32 : 9830400 (0x960000)
  +0x00C <b>.CheckSum UInt32 : 9827193 (0x95F379)</b>
  +0x010 <b>.TimeDateStamp UInt32 : 1366540564 (0x5173C114)</b>
  +0x014 .ModuleNameRva UInt32 : 107828 (0x1A534)
  +0x018 .VersionInfo tagVS_FIXEDFILEINFO : (pack:8 size:52) 
    +0x000 .dwSignature UInt32 : 4277077181 (0xFEEF04BD)
    +0x004 .dwStrucVersion UInt32 : 65536 (0x10000)
    +0x008 <b>.dwFileVersionMS UInt32 : 262144 (0x40000)</b>
    +0x00C <b>.dwFileVersionLS UInt32 : 1987004036 (0x766F4684)</b>

Разделив старшие и младшие слова из dwFileVersionMS, мы получим 4 и 0.
Разделив старшие и младшие слова из dwFileVersionLSмы получаем 30319 и 18052.


Используя dumpchk.exe , и, глядя на детали модуля в PEB, мы можем увидеть другую временную метку (0x515530CE), которая на самом деле соответствуетдо более старой (18047) версии:

7fef2f50000 <b>515530ce</b> Mar 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> 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  <b><i>ce 30 55 51</i></b> 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  <b><i>80 5f 96 00</i></b> 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)
  • Приложение Crashed
  • MiniDumpWriteDump, по-видимому, использовало информацию о файле на диске при сохранении списка модулей в дампе сбояфайл (4.0.30319.18052)
  • WinDbg не смог соотнести версию, отмеченную в аварийном дампе, с тем, что было в памяти процесса, поскольку в нем содержалась противоречивая информация.

КомуЧтобы убедиться в этом, я вручную изменил запись MINIDUMP_MODULE для clr.dll, чтобы изменить контрольную сумму, метку времени и версию с 18052 на 18047. После перезагрузки взломанного файла .dmp в WinDbg и установки exepath на соответствующие библиотеки sos + clr, яудалось успешно выполнить команды sos и получить правильную трассировку стека.

Итог

По сути, мы получили минимальное количествоp-файл, содержащий противоречивую информацию о том, какая версия clr.dll загружена в процесс, не позволяя SOS определить правильный механизм clr.Это, вероятно, ошибка в MiniDumpWriteDump, поскольку она сохраняет файл аварийного дампа.Но должно происходить только тогда, когда базовая версия CLR была обновлена ​​во время работы вашего приложения.

0 голосов
/ 28 октября 2011

Является ли процесс, который вы пытаетесь отладить, 32-разрядным?Что говорит список процессов менеджера задач?Если это 32-битный процесс, то вам нужно использовать 32-битный windbg.В противном случае, я не понимаю, почему .load sos clr должен потерпеть неудачу.

ps: (windbg noob alert), поэтому я прошу прощения, если это звучит неубедительно.Просто пытаюсь помочь.

0 голосов
/ 24 августа 2011

Похоже, вы сделали пользовательскую установку windbg и не выбрали все необходимые вам расширения.Ошибка Win32 n2 обычно является признаком этой проблемы.

...