Снять дамп что это значит

Дамп памяти в Windows – зачем нужен и как его включить

С критическими ошибками «оконной» ОС знаком практически каждый её пользователь, и появляющиеся при этом синие экраны смерти (BSoD) обычно ничего хорошего не предвещают. Они могут быть спровоцированы программными или аппаратными причинами, и поскольку источник неприятности не всегда очевиден, решение начинается с диагностических мероприятий.

Исправить ошибку бывает непросто, и часто самым полезным средством для диагностики причин возникшего сбоя становится дамп памяти, представляющий собой снимок состояния оперативной памяти операционки с отладочными сведениями. Причём в Windows не всегда активировано автоматическое создание и сохранение на жёсткий диск дампов памяти, тогда как в исправлении BSoD независимо от характера сбоя эти данные могут сильно помочь.

Для чего нужен дамп памяти Windows

Содержимое оперативной памяти и материалы, касающиеся сбоя, могут писаться в файл подкачки, при следующем старте операционки создаётся аварийный дамп с информацией об отладке, сформированной на базе сохранённых данных (ОС может создавать memory dump и минуя файл подкачки). В журнале событий будет сделана запись об ошибке, если данная опция настроена.

Вывод участка дампа 32-х битной ОС Windows с помощью программы Debug.exe

Тип записываемого дампа может задаваться в свойствах ОС, поддерживаются варианты:

1. Малый дамп памяти. Включает немного сведений, в частности это код ошибки с параметрами, список установленных в Виндовс драйверов и т. д., но этой информации бывает достаточно для выявления источника проблемы. Элемент, как правило, будет записан в каталоге C:\Windows\Minidump.
2. Дамп памяти ядра. Выполняется сохранение сведений оперативной памяти, связанных только с режимом ядра, исключая информацию, не указывающую на источник появления сбоя.
3. Полный дамп системы. Содержимым является вся память операционки, что может создать проблемы при создании снимка, если объём ОЗУ составляет более 4Гб. Обычно пишется в файл C:\Windows\MEMORY.DMP.
4. Автоматический дамп памяти (стал доступным с восьмой версии Виндовс). Содержит те же записи, что и memory dump ядра, при этом отличается способом управления системой размером файла подкачки.
5. Активный дамп памяти (представлен в «Десятке»). Содержит только активную память хоста из режимов ядра и пользователя* (возможность была изначально реализована для серверов, чтобы при диагностике в дамп не попадали виртуальные машины).

*Дамп пользовательского режима представляет собой дамп определённого процесса. Так, содержимым может являться полная память процесса или фрагмент, список, стек, состояние потоков, списки библиотек, состояние потоков, дескрипторы объектов ядра.

Чаще всего аварийный дамп памяти Windows 7, 8, 10 используется в целях диагностики и позволяет выяснить, как исправить критическую ошибку. Проанализировав содержимое, можно понять, что стало причиной неполадки, и приступить к её устранению.

Как включить создание дампа памяти в Windows

Чтобы активировать автоматическое сохранение memory dump в Виндовс, нужно сделать следующее:

1. Переходим к свойствам системы любым удобным способом. Например, жмём правой кнопкой мыши по значку «Мой компьютер» (или «Этот компьютер» на «Десятке»). Выбираем «Свойства», затем в перечне опций в левой колонке жмём «Дополнительные параметры системы». Альтернативный вариант – использование Панели управления, где следует перейти в раздел «Система» (то же окно появится при использовании клавиш Win+Pause), а затем в «Дополнительные параметры системы». В Виндовс 10 также можно применить оснастку «Параметры»(Win+I). В окне нужно перейти к разделу «Система – «О системе» – «Сведения о системе» и далее в дополнительные параметры ОС.
2. В открывшемся окне на вкладке «Дополнительно» в области «Загрузка и восстановление» жмём «Параметры».
3. В итоге манипуляций откроется следующее окно, где следует выбрать тип записи отладочной информации, задать параметры, проставив в нужных пунктах галочки, после чего нажать кнопку «ОК».

Как настроить дамп памяти в Windows

Настройки действий, производимых при аварийной остановке работы ОС, выполняются в том же окне, что и включение создания memory dump («Загрузка и восстановление»), куда мы попадаем из свойств системы.

Здесь можно настроить параметры запуска ОС и назначить определённые действия в случае её отказа, например:

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

При эксплуатации SSD лучше оставить тип записи «Автоматический дамп памяти», но если нужен файл аварийного дампа, лучше выставить «Малый дамп памяти», он самый лёгкий и его несложно переслать другому пользователю, если вам нужна помощь в анализе состояния.

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

Прочитать memory dump можно посредством специализированных утилит, таких как Microsoft Kernel Debugger, BlueScreenView и других.

Установка WinDbg в Windows

Утилита, являющаяся отладчиком для юзермодных приложений и драйверов, позволяет проанализировать снимок памяти и выяснить, что спровоцировало BSoD. Поставляется она в составе пакета SDK для Windows 10, инсталлятор скачивается на сайте Microsoft. Для Семёрки и ранних версий систем WinDbg можно найти в пакете Microsoft Windows SDK for Windows 7 and NET Framework 4.

• идём на страницу загрузки SDK (в зависимости от версии ОС выбираем нужный пакет, ссылки выше), скачиваем инсталлятор;
• после скачивания файла запускаем процесс инсталляции;
• выбираем первый вариант установки – на этот компьютер (второй предполагает загрузку для установки пакета на другие компьютеры);
• оставляем путь установки по умолчанию или меняем, если это необходимо;
• соглашаемся с условиями лицензионного соглашения;
  
• можно поставить весь пакет или выбрать в списке только отладчик Debagging Tools for Windows.

Анализ аварийного дампа памяти в WinDbg

Перед анализом memory dump необходимо выполнить некоторые настройки. Для работ с софтом понадобится пакет символов отладки Debugging Symbols, загруженный с учётом версии и разрядности системы.

Можно настроить извлечение утилитой символов из интернета, что безопасно, поскольку используется официальный ресурс компании Майкрософт.

Ассоциирование файлов .dmp с WinDbg

Для того чтобы объекты при нажатии на них открывались посредством утилиты:

В консоли командной строки, запущенной от имени администратора (например, через меню Пуск) выполняем команды (зависимо от разрядности ОС):

cd C:\Progran Files (x86)\Windows Kits\10\Debuggers\x64
exe –IA

cd C:\Progran Files (x86)\Windows Kits\10\Debuggers\x86
exe –IA

Теперь файлы типов .DMP, .HDMP, .MDMP, .KDMP, .WEW будут ассоциироваться с приложением.

Настройка сервера отладочных символов

Отладочные символы, которые генерируются в процессе компиляции приложения вместе с исполняемым файлом, нужны при отладке. Настраиваем WinDbg на извлечение символов из сети:

• в окне WinDbg жмём «File» и выбираем «Symbol Fie Path…» или жмём Ctrl+S;
• указываем путь для загрузки, прописав строчку:

применяем корректировки нажатием «File» – «Save Workspace».

Анализ memory dump в WinDbg

Чтобы перейти к процедуре, открываем объект в утилите (File – Open Crash Dump) или, если предварительно настраивались ассоциации файлов, открываем элемент щелчком мыши. Утилита начнёт анализировать файл, затем выдаст результат.

В окне предполагается ввод команд. Запрос «!analyze –v» позволит получить более детальные сведения о сбое (STOP-код, имя ошибки, стек вызовов команд, приведших к проблеме и другие данные), а также рекомендации по исправлению. Для остановки отладчика в меню программы жмём «Debug» – «Stop Debugging».

Как удалить файлы дампа памяти

Если понадобилось удалить memory dump, это можно выполнить вручную, пройдя по пути месторасположения объекта на диске. Так, в системном каталоге Windows нужно найти и удалить файл MEMORY.DMP, а также элементы в каталоге Minidump. Кроме того, можно использовать штатный инструмент системы «Очистка диска»:

• вызываем консоль «Выполнить» (Win+R) и вводим команду «Cleanmgr», чтобы перейти к службе;
• жмём кнопку очищения системных файлов, затем находим и отмечаем в списке строчки, касающиеся memory dump. Если не нашлось, значит, их не создавали.

Создание снимков бывает отключено, даже если вы когда-либо активировали эту функцию по причине деятельности специального софта. Если речь о SSD-накопителе, это могут быть программы для работы с твердотельными дисками. Отключение некоторых опций ОС выполняется ими с целью оптимизации работы, поскольку многократные процессы чтения/записи сокращают продолжительность жизни диска. Также причиной отключения дампа памяти могут быть различные программы очистки компьютера и оптимизации системы.

Источник

Снимаем дамп объектов с памяти .Net приложения

Продолжаем тему интересного на .Net, от чего мир Java будет посмеиваться (хотя у них это также возможно сделать), а приверженцы С++ говорить: «чего они только не сделают чтобы не учить C++».

В данной заметке мы напишем по сути – простенькое ядрышко профилировщика памяти для платформы .Net, который будет снимать дамп с SOH кучи (а в перспективе и с LOH).

Для написания статьи нам понадобится код из статьи Получение указателя на объект .Net и Ручное клонирование потока (измерение размера объектов).

Наши цели на сегодня:

• Научиться итерировать кучу .Net
• Научиться находить начало кучи .Net
• Попробовать сытерировать все объекты чужого домена.

Ссылка на проект в GitHub: DotNetEx

Как и в прошлый раз, будем решать проблемы по мере их поступления:

Найдем начало кучи в .Net

Как мы, наверное, знаем, в .Net существует два вида куч. Это куча для маленьких объектов и куча для больших объектов (> 85K). Они отличаются прежде всего организацией объектов внутри себя. Если в SOH объекты выделяются друг за другом, то в LOH все основано на связанных списках и таблице свободных промежутков между занятыми участками. Это то, что мы знаем. Но правда заключается в другом. Во-первых SOH не может быть непрерывной ввиду возможности наткнуться на занятый участок виртуальной памяти при ее расширении. Второе – на самом деле то, что объекты выделяются непрерывно друг за другом – красивое допущение, поскольку есть pinned объекты, которые нельзя двигать, а значит при сжатии кучи возникнут пустые промежутки. А это значит что SOH также содержит таблицу пустот. И по итогу это должно означать конкретно для нас что: (а) в памяти может быть несколько зон виртуальной памяти, которые выделены под кучу, (б) вероятнее всего они выделены через VirtualAlloc, (в) объекты находятся не непрерывно, а значит наш алгоритм не может на это полагаться.

Для упрощения примера, давайте будем снимать дамп только с объектов своей кучи. Для того чтобы это сделать, мы возмем указатель на любой объект и при помощи WinApi функции VirtualQuery попробуем получить регион виртуальной памяти, которая была выделена под эту кучу

Прекрасно! Теперь мы знаем участок памяти, на котором искать объекты.

Сытерируем все объекты чужого домена
Для того чтобы это сделать, нам необходимо понять как их распознать. Так вот если мы посидим с отладчиком и поизучаем память, то можно в итоге прийти к выводу, что ссылка на объект указывает не на первое поле объекта, а на указатель на таблицу виртуальных методов. Которая на самом деле не только таблица виртуальных методов, а методов вообще и описания типа. Ведь мы не в C++ мире, а в мире .Net, где по каждому объекту можно понять, «чей будешь?». А как же SyncBlockIndex, просите вы? А он, как выяснилось, находится «перед» объектом, за вычетом размера слова (4 байта на 32-х и 8 — на 64-х разрядной системе). Потому структура заголовка любого объекта выглядит следующим образом:

Далее посмотрим, как выглядит MethodTableInfo:

Здесь — только часть всей информации с этой структуры. На самом деле она более обширная. Нам тут важно поле EEClass, которое ведет на структуру описания типа. Его я практически не изучал. Выглядит содержимое примерно так:

Поскольку для нас важно только поле MethodsTable, я только его и нашел. Остальное — пропустил. Зачем оно нам? Это — обратная ссылка на MethodsTable, который своим полем EEClass ссылается сюда.

Таким вот не хитрым образом мы нашли несколько не точный, однако прекрасно работающий метод детектирования .Net объекта. Выглядит он так:

Для каждого указателя проверяется, указывает ли он на выделенный участок памяти. Это первый барьер. Второй барьер — если у теоретического объекта первое поле указывает на нечто, что мы изначально интерпретируем как MethodsTable. Проверяем что поле EEClass указывает на выделенный участок памяти и интерпретируем этот указатель как указатель на структуру ObjectTypeInfo, после чего проверяем, равен ли указатель на MethodsTable нашему найденному указателю (есть ли обратная ссылка?) Если все норм, объект найден.

Осталось только пройтись по всем участкам памяти и попробовать распознать там объекты. Я не буду выкладывать эту простыню, поскольку там также есть код для регистрации найденного и вывода на экран. Скажу только что задача решена, ссылка вывода из программы — ниже.

Можно ли получить объекты с чужого домена?

Конечно! Ведь мы смотрим на виртуальную память. Это раз… А второе… между доменами нет границ, объекты выделяются друг за другом даже при пересечении границы доменов. Разница — в коде. Потому можно, например, передать между доменами объект без сериализации.

Источник