Блог

Главная - Вопросы по программированию - Как отладить дамп памяти с шипами ASP.NET процесс?

Как отладить дамп памяти с шипами ASP.NET процесс?

#asp.net #.net #debugging #windbg

Вопрос:

Извините, я не смог придумать, как лучше сформулировать свой настоящий вопрос.

Я управляю интенсивным движением ASP.NET сайт на 64-разрядной машине. Однако у меня IIS работает в 32-разрядном режиме из-за некоторых устаревших компонентов приложения. Я запускаю это конкретное веб-приложение в пуле приложений, в котором включена опция «Веб-сад» (запуск 6 процессов на 8-ядерном компьютере).

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

Я уже отлаживал с помощью WinDbg раньше, чтобы выяснить, что вызвало тупик на сайте, но это было несколько месяцев назад, и я не могу вспомнить, как я заставил его работать. (В качестве примечания, это урок для документирования всего, что вы делаете.)

Я запускаю WinDbg на сервере Windows 2003, на котором запущен сайт, чтобы предотвратить любые проблемы с версиями DLL. Вот мои шаги до сих пор, пожалуйста, дайте мне знать, где я ошибаюсь, чтобы получить сообщение об ошибке, которое я получаю.

  1. Я сначала дамп памяти для процесса загрузки с помощью UserDump со следующей командой, где 3389-идентификатор процесса:

    userdump -k 3389

  2. Я загружаю дамп в x86-версию WinDbg.
  3. Поскольку я использую 32-разрядную версию на 64-разрядной машине, я сначала загружаю дамп памяти, а затем:

    .load wow64exts

    .effmach x86

  4. Я удостоверяюсь, что мой путь к символу включает каталог, содержащий файлы PDB моих приложений:

    .sympath c:inetpubmyappbin

  5. Запуск просто `.load SOS’ завершается ошибкой «Система не может найти указанный файл», поэтому я иду по полностью определенному маршруту следующего, который работает:

    .load c:windowsmicrosoft.netframeworkv2.0.50727sos

Отсюда я заблудился. Я пробую любую из команд SOS, например !threads , только для того, чтобы получить эту ошибку:

 Failed to load data access DLL, 0x80004005

Эта ошибка также сопровождается пронумерованным списком элементов, которые я должен проверить.
Я проверил, что я запускаю самую последнюю версию отладчика, mscordacwks.dll фактически находится в том же каталоге, что и mscorwks.dll файл, и я выполняю отладку на той же архитектуре, что и файл дампа.

Я также запустил магическую .cordll -ve -u -l команду»», но это ничего не решает. Меня всегда приветствуют» CLR DLL status: No load attempts «, когда я это выполняю. Затем я пробую « .reload «, что дает несколько предупреждений, таких как « WARNING: wldap32 overlaps dnsapi «. Я бы хотел, чтобы там было написано что-то вроде « CLRDLL: Loaded DLL C:WINDOWSMicrosoft.NETFrameworkv2.0.50727mscordacwks.dll «. Но это не так.

Комментарии:

1. Симптом, который вы описываете, звучит как коллекция GC2.

2. Вы заглядывали в блог Тесс?: это золотая жила информации.

Ответ №1:

Попробуйте выполнить !sw перед выполнением команд sos. Смотрите это сообщение в блоге.

Комментарии:

1. Я думаю, что !sw просто переключается между 32-разрядным и 64-разрядным режимами, что, по сути, то же самое, .effmach x86 что и . Я все равно попробовал, но это не помогло. Хотя спасибо, что дал мне что-то попробовать.

Ответ №2:

Ответ №3:

По моему опыту, увеличение пула приложений может быть связано с его переработкой. Вы пробовали агент сбоя / зависания IIS и дамп IIS ?

http://www.microsoft.com/downloads/details.aspx?Идентификатор семьи=01c4f89d-cc68-42ba-98d2-0c580437efcfamp;DisplayLang=ru

Также к ним прилагается анализатор файлов дампа, который расскажет вам об утечках памяти и даже предложит области вашего кода, которые нуждаются в исправлении (в комплекте со ссылками на соответствующие статьи MSKB!)

Ответ №4:

Чувак — не уверен, что это поможет, но, может быть, попробуешь вот это.

  1. Копия c:windowsmicrosoft.netframeworkv2.0.50727sos.dll в тот же каталог, в который установлен windbg (например. c:program файлыСредства отладки для Windows ). Почему? облегчите загрузку файла sos
  2. запустить windbg
  3. загрузите файл дампа памяти. для меня я использую ctrl-D или Файл -> открыть аварийный дамп
  4. .загрузить sos
  5. .symfix c:tempdebug_symbols
  6. .перезагрузите

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

поэтому отсюда я смотрю на запущенные потоки и проверяю самый загруженный поток

8 !пул потоков

9 !сбежавший

 0:027 !runaway
User Mode Time
Thread       Time
18:704       0 days 0:00:17.843   <-- Thread #18
19:9f4       0 days 0:00:13.328   <-- Thread #19
16:1948      0 days 0:00:10.718
26:a7c       0 days 0:00:01.375
24:114       0 days 0:00:01.093
27:d54       0 days 0:00:00.390
28:1b70      0 days 0:00:00.328
0:b7c       0 days 0:00:00.171
25:3f8       0 days 0:00:00.000
23:1968      0 days 0:00:00.000

нити 18 и 19 уже некоторое время болтаются … хм… они застряли в петле?

  1. ~18 лет
  2. !clrstack. это похоже на отладку в Windows.

.. и отсюда вы можете сбрасывать объекты и прочее, указывая ссылки на адреса и прочее.

зацени !помогите перечислить некоторые команды, которые нужно попробовать использовать .. я думаю !help.sos тоже работает?

ХТ … если вы все еще застряли, спросите, что сработало, а что нет.

Ответ №5:

Мне просто пришлось столкнуться с подобной проблемой. В моем случае оказалось, что WinDbg не смог найти правильную версию mscorwks.dll. В дополнение к версии фреймворка, существует также версия библиотеки DLL, которая может отличаться между одной и той же версией фреймворка.

Теоретически серверы символов Microsoft должны иметь возможность предоставлять необходимые библиотеки DLL, но для меня этого не происходило. Чтобы решить эту проблему, я использовал !sym noisy дополнительную информацию о загрузке символов. Когда я это сделал !dumpstack , я получил сообщение об ошибке:

SYMSRV: http://msdl.microsoft.com/download/symbols/mscorwks.dll/492B82C1590000/mscorwks.dll not found

Чтобы исправить это, я создал соответствующие папки в своем локальном кэше символов и скопировал mscorwks.dll от машины, из которой произошла свалка. После a .reload WinDbg нашел необходимую библиотеку DLL в локальном кэше символов и счастливо продолжил.

Кроме того, вы можете найти точную версию mscorwks, с которой используется lm v m mscorwks . Затем вы можете найти обновление, содержащее нужную вам версию, из этого списка. Вам нужно будет извлечь необходимые библиотеки DLL из конкретного обновления в нужное место.

Метки: