Как мне отладить дамп памяти зарождающегося процесса ASP.NET? - PullRequest
4 голосов
/ 07 октября 2008

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

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

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

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

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

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

    userdump -k 3389

  2. Я загружаю дамп в x86-версию WinDbg.

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

    .load wow64exts

    .effmach x86

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

    .sympath+ c:\inetpub\myapp\bin

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

    .load c:\windows\microsoft.net\framework\v2.0.50727\sos

Отсюда я заблудился. Я пытаюсь использовать любую из команд 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:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll". Но это не так.

Ответы [ 5 ]

3 голосов
/ 07 октября 2008

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

2 голосов
/ 07 октября 2008

По моему опыту, всплывший пул приложений может быть из-за его переработки. Вы пробовали IIS Crash / Hang agent и IIS Dump?

http://www.microsoft.com/downloads/details.aspx?FamilyID=01c4f89d-cc68-42ba-98d2-0c580437efcf&DisplayLang=en

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

1 голос
/ 06 августа 2009

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

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

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

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

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

1 голос
/ 30 октября 2008

Чувак - не уверен, поможет ли это, но, возможно, попробуй это.

  1. Скопируйте c: \ windows \ microsoft.net \ framework \ v2.0.50727 \ sos.dll в тот же каталог, где установлен windbg (например, c: \ program files \ Средства отладки для Windows \). Зачем? упростить загрузку файла sos
  2. запустить windbg
  3. загрузить файл дампа памяти. для меня я использую Ctrl-D или Файл -> Открыть аварийный дамп
  4. .load sos <- запишите полный останов ПЕРЕД командой загрузки </li>
  5. .symfix c: \ temp \ debug_symbols
  6. .reload

Хорошо ... обратите внимание на командную строку. это говорит мне текущую THREAD, в которой был дамп. Это может быть бесполезно для сценария HIGH CPU ... потому что мы можем быть в любом потоке.

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

8! Threadpool <- это так, чтобы я мог видеть загрузку процессора, чтобы проверить, что мы находимся в дерьмовом (занятом) состоянии ... например, 100% процессор или что нет. </p>

9! Runaway <- перечислите нити, которые были вокруг самого длинного ... например. </p>

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 с <- перейти к теме 18. </li>
  2. ! Clrstack <- стек вызовов clr .. который аналогичен отладке в windows. </li>

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

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

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

...