DLL не загружается в WinDbg при анализе файла cra sh -dump - PullRequest
Новая
       141

DLL не загружается в WinDbg при анализе файла cra sh -dump

0 голосов
/ 18 июня 2020

После того, как не удалось получить DebugDiag для анализа файлов cra sh -dump , мне было предложено попробовать вместо этого WinDbg.

Cra sh -dump файлы были созданы на сервере Windows Server 2016, на котором запущено мое веб-приложение ASP. Net 4.5.2 на IIS-10. Мое ASP. Net веб-приложение содержит несколько сторонних компонентов с их отдельными библиотеками DLL.

Я скопировал файлы cra sh -dump на свою машину разработки Windows 10 и запускаю WinDbg локально, а не на сервере.

Проблема в том, что ... когда я запускаю !analyze -v в WinDbg на любом из файлов cra sh -dump, он фактически зависает, пока «Загрузка файла xxx.DLL» (xxx.DLL - это имя только одной из сторонних компонентных DLL), и в конечном итоге самопроизвольно отменяется через некоторое время.

Я запускаю WinDbg на том же компьютере на котором я изначально построил веб-сайт ... так есть ли способ сообщить WinDbg, что он может найти DLL в определенном месте на локальном компьютере?

Я, очевидно, у меня нет файла .pdb для любого из сторонних компонентов, поэтому меня не беспокоит, что он загружает символы для этих DLL ... но либо я как-то говорю ему игнорировать эти конкретные DLL, либо я говорю ему как найти их loca lly.

Кто-нибудь может указать мне правильное направление?

Ответы [ 3 ]

0 голосов
/ 19 июня 2020

В принципе, нет, вы не можете ускорить процесс загрузки символов для библиотек DLL, в которых у вас нет символов. ИМХО, единственный способ ускорить процесс символа - отключить HTTP-сервер, чтобы символы ищутся только на вашем локальном диске.

См. Также: Как настроить символы в WinDbg , если вы не делали это часто.

Получение HTTP 404 для этих файлов не займет много времени. Однако он пробует различные окончания файлов и указатели et c. Иногда серверы Microsoft работают медленно. Кроме того, конечно, наличие большого количества сторонних DLL может подвести итог. Это может сильно раздражать.

0 голосов
/ 23 июня 2020

Начну с того, что я не на 100% понимаю все, что мне нужно было сделать, но вот шаг, который я предпринял, чтобы выяснить, где проблема с переполнением стека была в моем приложении ...

Большинство информации пришло из этого блога .

  • На сервере я добавил следующие параметры реестра для создания файлов дампа cra sh ... 

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpCount"=dword:00000005
"DumpFolder"=hex(2):43,00,3a,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,\
00,6d,00,70,00,73,00,5c,00,00,00

(DumpCount - это количество файлов, которые нужно сохранить перед тем, как он начнет перезаписывать старые - DumpFolder - это место, где файлы должны быть сохранены, это REG_EXPAND_SZ и в мой случай представляет C:\CrashDumps\)

  • Ожидал сбоев
  • Скопировал файлы cra sh в каталог на моем локальном компьютере с именем C:\WinDbg\CrashDumps\
  • Создайте еще один каталог с именем C:\WinDbg\Symbols, в который я поместил ...
    • clr.dll (с сервера, взято из C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
    • sos.dll (с сервера, взяты из C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
    • всех .dll и .pdb файлов из моей локальной среды разработки, включая th компонент стороннего производителя .dll файлы
  • Установлен WinDbg через Windows Сохранить на моей Windows 10 машине разработки
  • Выполнить windbgx -y c:\windbg\symbols через команду Выполнить ( по какой-то причине на моей машине это windbgx, но, возможно, это потому, что это через Магазин, а не ручная загрузка)
  • В меню файлов Open dump file и выберите один из файлов дампа в C:\WinDbg\CrashDumps
  • Выполнение следующих команд ...
    • .symfix
    • .reload
    • .load c:\windbg\symbols\sos.dll (см. Примечание 1 ниже)
    • !clrstack (см. Примечание 2 ниже)

Хотя это не дало мне всей информации, которую я ожидал, он показал, что один из моих сторонних компонентов был 100 % виноват в исключении stackoverflow.

Примечание 1. Во многих местах, которые я читал, говорилось, что .loadby sos clr следует использовать, но это дало мне The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed, и я не мог понять, как это исправить ... поэтому вместо этого я использовал .load c:\windbg\symbols\sos.dll.

Примечание 2 - Команда !clrstack работала, потому что WinDbg, казалось, предварительно выбирал поток, который было исключение. Другой вариант - использовать ~*e !clrstack, который покажет вам стеки вызовов для ВСЕХ потоков.

0 голосов
/ 19 июня 2020

Вам не нужно анализировать файл дампа с помощью! Анализировать -v. Если вам нужно загрузить dll, то достаточно .load D: ....

Для анализа файла дампа. Пожалуйста, запустите .loadb sos clr, чтобы загрузить модуль отладки. Если на сервере cra sh и на вашем компьютере установлена ​​другая версия. net framework. Затем вам нужно загрузить sos.dll вручную.

Когда вам нужно отладить приложение. net в IIS, рекомендуется расширение! Mex. https://www.microsoft.com/en-us/download/details.aspx?id=53304

Вы можете загрузить mex.dll через .load c:\.....\mex.dll

!mex.aspxpages может отображать все запросы внутри процесса и их процесс

!mex.mthreads показать статус всех потоков

!mex.clrstack2 покажет все исключения и управляемый стек вызовов в указанном c потоке.

1. Вы можете использовать ~* k для загрузить полный стек вызовов во все потоки и !mex.mthreads проверить статус. Затем вы можете найти что-то вроде KERNELBASE!RaiseException в конкретном c потоке

2. Затем go в этот поток через threadid~ как 12~

3. Запустите !mex.clrstack2 и он покажет cra sh исключение

...