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) My Symbol Path: 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".

0:027> .cordll -ve -u -l
CLR DLL status: No load attempts

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=????????

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.

Ответ 1

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

Ответ 2

Я просто провел день, отлаживая кучу случаев, когда мы столкнулись с этим сценарием. 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

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

Временная метка файла (0x5173C114), контрольная сумма (0x0095F379) и версия (4.0.30319.18052), хранящиеся в структуре MINIDUMP_MODULE в модуле minidump -list-stream был для новой 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, вы можете увидеть контрольную сумму (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  [email protected]
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  ._....`.........

Я также прыгнул вперед в памяти и посмотрел на ресурс Версии в памяти и увидел строку версии 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 dll, я смог успешно выполнить команды sos и получить допустимую трассировку стека.

Нижняя линия

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

Ответ 3

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

Ответ 4

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

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