Анализ Дампов Памяти

В этой части я попытаюсь объяснить файлы символов (symbol files). Обычно их называют файлами PDB потому что их имена файлов имеют расширение .PDB. Старые файлы символов также могут иметь расширение .DBG. Файлы PDB необходимы для правильного чтения дампов памяти. Без файлов PDB, дамп памяти представляет собой простой набор чисел, содержимое памяти без какой либо интерпретации. Файлы PDB помогают инструментам и отладчикам типа WinDbg правильно интерпретировать данные и преобразовать их в читабельный формат. Грубо говоря, файлы PDB содержат соответствия между числами и их интерпретацией, выраженной в коротких строках текста:

Поскольку эти соответствия изменяются когда мы устанавливаем патч или исправленную версию программы на компьютер и у нас появился новый файл дампа памяти, нам необходимы новые файлы PDB которые соответствуют измененным компонентам DLL или драйверам.

Некоторое время назад файлы символов необходимо было загружать с сайта компании Microsoft или копировать их с дисков CD. Сейчас компания Microsoft предоставляет выделенный интернет-сервер символьных файлов и отладчик WinDbg может загружать файлы PDB автоматически. Нам только нужно ввести адрес этого сервера в диалоге File \ Symbol File Path… и выделить Reload. Адрес сервера:

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

Если мы не помним этот адрес и мы первый раз запускаем WinDbg на новом компьютере, мы можем выполнить следующую команду .symfix для автоматической установки пути к серверу и задать место на диске для сохранения загруженных файлов. Мы также можем проверить текущие пути поиска и загрузки символьных файлов путём выполнения команды .sympath. После изменения пути поиска или адреса загрузки необходимо явно перезагрузить файлы символов путем выполнения команды .reload:

0:000> .symfix
No downstream store given, using C:\Program Files\Debugging Tools for Windows\sym

0:000> .sympath
Symbol search path is: SRV**http://msdl.microsoft.com/download/symbols

0:000> .symfix c:\websymbols

0:000> .sympath
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

0:000> .reload

На заметку: Используйте эту ссылку для быстрой установки отладчика WinDbg и напоминания о путях и командах загрузки символов:

http://windbg.org

- Дмитрий Востоков @ DumpAnalysis.org -

Оригинальная статья: Crash Dumps for Dummies (Part 5)

В предыдущей части мы рассмотрели падение программ: Часть 3. Другой вид проблем, случающийся не менее чаще, когда нам нужен дамп памяти для анализа: зависания. Здесь существует некоторая путаница в понимании разницы между этими двумя категориями проблем: падение и зависание. Хотя, временами, зависание является прямым следствием падения, большая часть зависаний случается независимо от них. Зависания также проявляют себя отличным образом. Давайте, для начала, рассмотрим падения и зависания приложений (процессов).

Когда приложение (процесс) падает, он часто исчезает. Когда процесс зависает, приложение все еще находится в оперативной памяти: мы можем видеть его в Диспетчере Задач (Task Manager), на пример, но оно не реагирует на команды пользователя или на другие запросы как проверка реакции порта TCP/IP (pinging a TCP/IP port). Если у нас произошло падение операционной системы, то мы наблюдаем синий экран смерти (BSOD) и/или перезагрузку системы. При зависании системы все замирает.

Зависание приложений или системы легко объяснить если рассматривать взаимодействия между приложениями или компонентами системы как обмен сообщениями. Один компонент посылает сообщение другому и ждет ответа. Некоторые компоненты являются критическими, как например, реестр конфигурации и настроек (registry). Следующая картинка иллюстрирует часто встречающуюся ситуацию зависаний, когда реестр перестает отвечать на запросы. Тогда каждое приложение запрашивающее свои собственные или системные настройки перестает работать.

Очень часто встречающейся причиной зависаний является так называемый дедлок (deadlock), когда два приложения (точнее, их вычислительные пути, потоки) взаимно ждут друг друга. Здесь можно привести аналогию с заблокированной дорогой:

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

• Для систем Windows 2003 путём использования отладчика NTSD (всегда установлен)

• Путём использования программы userdump.exe

• Путём присоединения отладчика NTSD и сохранения дампа памяти

• Путём присоединения отладчика WinDbg и сохранения дампа памяти

• Путём использования ADPlus в режиме определения зависаний

Как нам получить дамп памяти, если система зависла?

• В ручную, с помощью клавиатуры

• Путём использования программы Citrix SystemDump удаленно или через графический интерфейс если у нас есть не зависшая терминальная сессия

Для большинства системных зависаний достаточно выбрать дамп ядра (Kernel memory dump) в Контрольной Панели (Control Panel \ System \ Advanced \ Startup and Recovery). Дампы ядра меньше по размеру и меньше подвержены повреждениям и обрубаниям из-за не достаточного размера файла подкачки (page file). Если вы обнаружите что вам нужно посмотреть что происходит внутри приложений, то нужно будет выбрать полный дамп физической памяти (Complete memory dump).

- Дмитрий Востоков @ DumpAnalysis.org -

Оригинальная статья: Crash Dumps for Dummies (Part 4)