Стандартный отладчик windows позволяет создавать дампы памяти это

В момент критического сбоя операционная система Windows прерывает работу и показывает синий экран смерти (BSOD). Содержимое оперативной памяти и вся информация о возникшей ошибке записывается в файл подкачки. При следующей загрузке Windows создается аварийный дамп c отладочной информацией на основе сохраненных данных. В системном журнале событий создается запись о критической ошибке.

Внимание! Аварийный дамп не создается, если отказала дисковая подсистема или критическая ошибка возникла на начальной стадии загрузки Windows.

Содержание:

Типы аварийных дампов памяти Windows
Как включить создание дампа памяти в Windows?
Установка WinDBG в Windows
Настройка ассоциации .dmp файлов с WinDBG
Настройка сервера отладочных символов в WinDBG
Анализ аварийного дампа памяти в WinDBG

Типы аварийных дампов памяти Windows

На примере актуальной операционной системы Windows 10 (Windows Server 2016) рассмотрим основные типы дампов памяти, которые может создавать система:

Мини дамп памяти (Small memory dump) (256 КБ). Этот тип файла включает минимальный объем информации. Он содержит только сообщение об ошибке BSOD, информацию о драйверах, процессах, которые были активны в момент сбоя, а также какой процесс или поток ядра вызвал сбой.
Дамп памяти ядра (Kernel memory dump). Как правило, небольшой по размеру — одна треть объема физической памяти. Дамп памяти ядра является более подробным, чем мини дамп. Он содержит информацию о драйверах и программах в режиме ядра, включает память, выделенную ядру Windows и аппаратному уровню абстракции (HAL), а также память, выделенную драйверам и другим программам в режиме ядра.
Полный дамп памяти (Complete memory dump). Самый большой по объему и требует памяти, равной оперативной памяти вашей системы плюс 1MB, необходимый Windows для создания этого файла.
Автоматический дамп памяти (Automatic memory dump). Соответствует дампу памяти ядра с точки зрения информации. Отличается только тем, сколько места он использует для создания файла дампа. Этот тип файлов не существовал в Windows 7. Он был добавлен в Windows 8.
Активный дамп памяти (Active memory dump). Этот тип отсеивает элементы, которые не могут определить причину сбоя системы. Это было добавлено в Windows 10 и особенно полезно, если вы используете виртуальную машину, или если ваша система является хостом Hyper-V.

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

С помощью Win+Pause откройте окно с параметрами системы, выберите «Дополнительные параметры системы» (Advanced system settings). Во вкладке «Дополнительно» (Advanced), раздел «Загрузка и восстановление» (Startup and Recovery) нажмите кнопку «Параметры» (Settings). В открывшемся окне настройте действия при отказе системы. Поставьте галку в чек-боксе «Записать события в системный журнал» (Write an event to the system log), выберите тип дампа, который должен создаваться при сбое системы. Если в чек-боксе «Заменять существующий файл дампа» (Overwrite any existing file) поставить галку, то файл будет перезаписываться при каждом сбое. Лучше эту галку снять, тогда у вас будет больше информации для анализа. Отключите также автоматическую перезагрузку системы (Automatically restart).

В большинстве случаев для анализа причины BSOD вам будет достаточно малого дампа памяти.

Теперь при возникновении BSOD вы сможете проанализировать файл дампа и найти причину сбоев. Мини дамп по умолчанию сохраняется в папке %systemroot%\minidump. Для анализа файла дампа рекомендую воспользоваться программой WinDBG (Microsoft Kernel Debugger).

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

Утилита WinDBG входит в «Пакет SDK для Windows 10» (Windows 10 SDK). Скачать можно здесь.

Файл называется winsdksetup.exe, размер 1,3 МБ.

WinDBG для Windows7 и более ранних систем включен в состав пакета «Microsoft Windows SDK for Windows 7 and .NET Framework 4». Скачать можно здесь.

Запустите установку и выберите, что именно нужно сделать – установить пакет на этот компьютер или загрузить для установки на другие компьютеры. Установим пакет на локальный компьютер.

Можете установить весь пакет, но для установки только инструмента отладки выберите Debugging Tools for Windows.

После установки ярлыки WinDBG можно найти в стартовом меню.

Настройка ассоциации .dmp файлов с WinDBG

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

Откройте командную строку от имени администратора и выполните команды для 64-разрядной системы:
cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 windbg.exe –IA

для 32-разрядной системы:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86 windbg.exe –IA
В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с WinDBG.

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

Отладочные символы (debug-символы или symbol files) – это блоки данных, генерируемые в процессе компиляции программы совместно с исполняемым файлом. В таких блоках данных содержится информация о именах переменных, вызываемых функциях, библиотеках и т.д. Эти данные не нужны при выполнении программы, но полезные при ее отладке. Компоненты Microsoft компилируются с символами, распространяемыми через Microsoft Symbol Server.

Настройте WinDBG на использование Microsoft Symbol Server:

Откройте WinDBG;
Перейдите в меню File –> Symbol File Path;
Пропишите строку, содержащую URL для загрузки символов отладки с сайта Microsoft и папку для сохранения кэша:
SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols
В примере кэш загружается в папку E:\Sym_WinDBG, можете указать любую.
Не забывайте сохранить изменения в меню File –> Save WorkSpace;

WinDBG произведет поиск символов в локальной папке и, если не обнаружит в ней необходимых символов, то самостоятельно загрузит символы с указанного сайта. Если вы хотите добавить собственную папку с символами, то можно сделать это так:

SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols

Если подключение к интернету отсутствует, то загрузите предварительно пакет символов с ресурса Windows Symbol Packages.

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

Отладчик WinDBG открывает файл дампа и загружает необходимые символы для отладки из локальной папки или из интернета. Во время этого процесса вы не можете использовать WinDBG. Внизу окна (в командной строке отладчика) появляется надпись Debugee not connected.

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

Самое главное, на что нужно обратить внимание – это код ошибки, который всегда указывается в шестнадцатеричном значении и имеет вид 0xXXXXXXXX (указываются в одном из вариантов — STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). В нашем примере код ошибки 0х139.

Полный справочник ошибок можно посмотреть здесь.

Отладчик предлагает выполнить команду !analyze -v, достаточно навести указатель мыши на ссылку и кликнуть. Для чего нужна эта команда?

Она выполняет предварительный анализ дампа памяти и предоставляет подробную информацию для начала анализа.
Эта команда отобразит STOP-код и символическое имя ошибки.
Она показывает стек вызовов команд, которые привели к аварийному завершению.
Кроме того, здесь отображаются неисправности IP-адреса, процессов и регистров.
Команда может предоставить готовые рекомендации по решению проблемы.

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !analyze –v (листинг неполный).

1: kd>
!analyze -v

***************************************************************************** * * * Bugcheck Analysis * * * *****************************************************************************

Символическое имя STOP-ошибки (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)

Описание ошибки (Компонент ядра повредил критическую структуру данных. Это повреждение потенциально может позволить злоумышленнику получить контроль над этой машиной):

A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.

Аргументы ошибки:

Arguments: Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove). Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck Arg4: 0000000000000000, Reserved Debugging Details: ------------------

Счетчик показывает сколько раз система упала с аналогичной ошибкой:

CUSTOMER_CRASH_COUNT: 1

Основная категория текущего сбоя:

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Код STOP-ошибки в сокращенном формате:

BUGCHECK_STR: 0x139

Процесс, во время исполнения которого произошел сбой (не обязательно причина ошибки, просто в момент сбоя в памяти выполнялся этот процесс):

PROCESS_NAME: sqlservr.exe

CURRENT_IRQL: 2

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application. EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

Последний вызов в стеке:

LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0

Стек вызовов в момент сбоя:

STACK_TEXT: ffffd000`3a20d2a8 fffff804`0117d6a9 : 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528 : nt!KeBugCheckEx ffffd000`3a20d2b0 fffff804`0117da50 : ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2 : nt!KiBugCheckDispatch+0x69 ffffd000`3a20d3f0 fffff804`0117c150 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiFastFailDispatch+0xd0 ffffd000`3a20d5d0 fffff804`01199482 : ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9 : nt!KiRaiseSecurityCheckFailure+0x3d0 ffffd000`3a20d760 fffff804`014a455d : 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951 : nt! ?? ::FNODOBFM::`string'+0x17252 ffffd000`3a20d8c0 fffff804`013a34ac : 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600 : nt!IopSynchronousServiceTail+0x379 ffffd000`3a20d990 fffff804`0117d313 : ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380 : nt!NtWriteFile+0x694 ffffd000`3a20da90 00007ffb`475307da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 000000ee`f25ed2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`475307da

Участок кода, где возникла ошибка:

FOLLOWUP_IP: nt!KiFastFailDispatch+d0 fffff804`0117da50 c644242000 mov byte ptr [rsp+20h],0 FAULT_INSTR_CODE: 202444c6 SYMBOL_STACK_INDEX: 2 SYMBOL_NAME: nt!KiFastFailDispatch+d0 FOLLOWUP_NAME: MachineOwner

Имя модуля в таблице объектов ядра. Если анализатору удалось обнаружить проблемный драйвер, имя отображается в полях MODULE_NAME и IMAGE_NAME:

MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe

Если кликнете по ссылке модуля (nt), то увидите подробную информацию о пути и других свойствах модуля. Находите указанный файл, и изучаете его свойства.

1: kd>
lmvm nt

Browse full module list Loaded symbol image file: ntkrnlmp.exe Mapped memory image file: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe Image path: ntkrnlmp.exe Image name: ntkrnlmp.exe InternalName: ntkrnlmp.exe OriginalFilename: ntkrnlmp.exe ProductVersion: 6.3.9600.18946 FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

В приведенном примере анализ указал на файл ядра ntkrnlmp.exe. Когда анализ дампа памяти указывает на системный драйвер (например, win32k.sys) или файл ядра (как в нашем примере ntkrnlmp.exe), вероятнее всего данный файл не является причиной проблемы. Очень часто оказывается, что проблема кроется в драйвере устройства, настройках BIOS или в неисправности оборудования.

Если вы увидели, что BSOD возник из-за стороннего драйвера, его имя будет указано в значениях MODULE_NAME и IMAGE_NAME.

Например:

Image path: \SystemRoot\system32\drivers\cmudaxp.sys Image name: cmudaxp.sys

Откройте свойсва файла драйвера и проверьте его версию. В большинстве случаев проблема с драйверами решается их обнвовлением.

Источник

SmallSoft

Диагностика ошибок в программах с помощью дампов памяти

Обычно для поиска и устранения проблем в программах разработчики используют интегрированную среду разработки (IDE), запуская под отладчиком живой процесс и исследуя его память. Но иногда проблема возникает редко и только в специфичных условиях, поэтому ее не получается воспроизвести на машине разработчика, где установлен отладчик. Тогда есть несколько путей: удаленная отладка, использование логов или данных телеметрии, а также запись и анализ дампов памяти. Последний способ мы и рассмотрим в данной статье. Рассматривать работу с дампами мы будем на примере Windows 7+ и Visual Studio 2012+. Статья в основном рассчитана на разработчиков, но может также быть полезна администраторам и продвинутым пользователям.

Бесплатную для некоммерческого использования версию Visual Studio можно скачать здесь: https://visualstudio.microsoft.com/ru/vs/community/. При установке выберите рабочую нагрузку “Desktop development with C++”.

Настройка компьютера для записи дампов пользовательской памяти

Много в интернете понаписано про использование дампов памяти ядра для диагностики синих экранов (BSoD), но менее известно, что аналогичный механизм можно использовать и для обычных приложений (уровня пользователя). Но по умолчанию такие дампы при сбоях программ не сохраняются, нужны специальные настройки в реестре: Collecting User-Mode dumps.

Открываем редактор реестра (Пуск — Выполнить — regedit).
Переходим в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting
Создаем раздел LocalDumps, если его нет
Создаем в разделе ключи:

DumpFolder (Расширяемый строковый параметр/REG_EXPAND_SZ) — Путь к каталогу, в который будут сохраняться дампы
DumpType (Параметр DWORD) — Тип дампа (задаем значение 1 — минидамп)
DumpCount (Параметр DWORD) — Максимальное количество дампов в каталоге, по умолчанию 10

Минидамп отличается от полного дампа только компактностью, т.е. данные сжимаются более эффективно. Вся необходимая информация для диагностики в минидамп включена, поэтому смело выбираем его. Подробнее о типах дампов можно почитать здесь: User mode dump files.

Максимальное количество дампов можно задать для экономии дискового пространства, на случай, если какая-то программа постоянно будет падать и плодить дампы. Когда количество дампов превысит максимальное, старые будут перезаписаны.

Готово, теперь при критическом сбое в любой программе (необработанное исключение SEH/C++/.NET) в указанном каталоге будет создан файл дампа памяти (.dmp). Файл дампа содержит информацию об адресном пространстве упавшего процесса в момент сбоя, которую мы далее будет анализировать.

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

Тестовая программа для демонстрации сбоя

Чтобы продемонстрировать работу с дампами, напишем такую простую программу на С++:

#include <stdio.h>

int Divide(int x, int y)
{
	return x/y;
}

void Crash(){
	printf("%d",Divide(1,0));
}

int main()
{
	Crash();	
}

Как можно видеть из кода, программа пытается разделить целое число на ноль, и поэтому должна выдать при запуске необработанное исключение SEH. Соберем программу как консольное приложение С++ в Visual Studio (можно использовать Express), в конфигурации Debug. Запустите программу и убедитесь, что она упала и дамп записался. Если вы переносите программу на другой компьютер, переносите ее вместе в символами (файлом .pdb), иначе анализ дампа будет затруднен.

Анализ дампа памяти в помощью Visual Studio

Популярный инструмент для анализа дампов — это WinDBG, но часто проще использовать Visual Studio. Для анализа дампа берем файл .dmp, нажимаем по нему правой кнопкой мыши и выбираем Открыть с помощью — Visual Studio. Отроется окно Visual Studio:

Нажимаем в нем Отладка с использованием только машинного кода (Debug with Native only). Откроется окно, в котором отображаются данные об исключении:

В окне можно увидеть код исключения (NTSTATUS), его описание, информацию о последовательности вызовов функций, которая привела к нему, и даже строку кода в файле .cpp исходного кода, на которой остановилось выполнение программы. Нажмите Прервать (Break), чтобы остановить отладку и изучить состояние программы более подробно. В окне Стек вызовов (Call stack) отображаются функции, последовательность которых привела к сбою. Каждый элемент списка называется кадром стека. Для кадра стека отображается модуль (EXE/DLL) и название функции после восклицательного знака. Двойным щелчком по функции можно перейти к ее исходникам, если они доступны. Также можно использовать меню Debug — Windows — Threads для отображения всех потоков, которые были активны в момент ошибки. В этом окне можно перейти и к стекам других потоков.

Из рисунка также видно, что для кадра стека из kernel32.dll не отобразилось имя функции. Это происходит, потому что символы для системных библиотек по умолчанию не загружаются. Рассмотрим, как включить загрузку символов.

Настройка загрузки символов в Visual Studio

Отладочные символы — это файл, который содержит информацию, необходимую для отладки. В первую очередь это таблица соответствия адресов памяти в исполняемом файле и имен функций, к которым относится код по этому адресу. Также символы могут содержать и информацию о строках файла исходников, соответствующих адресам кода в бинарнике (для продуктов с закрытым кодом этого обычно не будет). Для включения загрузки символов с серверов Microsoft выбираем в меню Options and settings — Debugging — Symbols. В открывшемся окне устанавливаем галку Microsoft symbol servers.

Можно включить загрузку всех символов, но тогда они грузиться будут долго. Пока включим лишь для одной библиотеки, для этого установим переключатель в значение Only specified modules, и нажмем Specify modules. В открывшемся окне добавим kernel32.dll, и отметим его галкой. Теперь переоткроем дамп, дождемся загрузки символов, и увидим, что название функции из kernel32.dll появилось:

Для библиотек собственной разработки также нужно будет включить загрузку символов, только вместо сервера символов указать путь к каталогу. Обратите внимание, что в нашем упрощенном случае символы для модуля программы DumpTest.exe загрузились автоматически, так как на компьютере и бинарник программы и символы лежали по тому же пути, что и сохранен в дампе. При переносе дампа на другой компьютер это в общем случае может не соблюдаться, тогда понадобится либо прописать путь для каталога с символами, либо загрузить символы вручную.

Для просмотра списка модулей и информации о загруженных символах выберите в меню Debug — Windows — Modules

Если в графе Symbol status отображается, что символы не прогрузились, можно подсунуть их вручную. Для этого нужно нажать по модулю правой кнопкой мыши и выбрать в меню Load symbols from — Symbol path. В появившихся диалоговых окнах нужно будет выбрать исполняемый файл и файл символов (иногда только что-то одно, если второе нашлось автоматически). При этом следует предоставить именно тот исполняемый файл, который использовался процессом, и именно те символы, которые соответствуют этому исполняемому файлу. В исполняемом файле в Debug directory прошивается специальный идентификатор символов; если файл символов ему не соответствует, отладчик пошлет вас подальше…

Таким образом, мы научились сохранять и анализировать дампы памяти для диагностики трудновоспроизводимых сбоев в программах для Windows. В Linux/Unix, к слову, аналогом этого метода будет использование Core dumps и их анализ с помощью GDB. Один из главных плюсов дампов памяти в том, что не нужно вносить никаких изменений в код, как это было бы в случае добавления дополнительного логирования. Если вы хотите реализовать аналогичную диагностику, с получением стеков, через логирование, для этого можно использовать библиотеку ErrLib.

Источник

Дамп памяти (снимок состояния оперативной, содержащий отладочную информацию) — то, что часто оказывается наиболее полезными при возникновении синего экрана смерти (BSoD) для диагностики причин возникновения ошибок и их исправления. Дамп памяти сохраняется в файл C:\Windows\MEMORY.DMP, а мини дампы (малый дамп памяти) — в папку C:\Windows\Minidump (подробнее об этом далее в статье).

Автоматическое создание и сохранение дампов памяти не всегда включено в Windows 10, и в инструкциях на тему исправления тех или иных ошибок BSoD мне время от времени приходится описывать и путь включения автоматического сохранения дампов памяти в системе для последующего просмотра в BlueScreenView и аналогах — потому и было решено написать отдельное руководство именно о том, как включить автоматическое создание дампа памяти при ошибках системы, чтобы в дальнейшем ссылаться на него.

Настройка создания дампов памяти при ошибках Windows 10

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

Зайдите в панель управления (для этого в Windows 10 вы можете начать набирать «Панель управления» в поиске на панели задач), если в панели управления в поле «Просмотр» включено «Категории», установите «Значки» и откройте пункт «Система».

Картинка с сайта: remontka.pro
В меню слева выберите пункт «Дополнительные параметры системы».

Картинка с сайта: remontka.pro
На вкладке «Дополнительно» в разделе «Загрузка и восстановление» нажмите кнопку «Параметры».

Картинка с сайта: remontka.pro
Параметры создания и сохранения дампов памяти находятся в разделе «Отказ системы». По умолчанию включены опции записи в системный журнал, автоматической перезагрузки и замены существующего дампа памяти, создается «Автоматический дамп памяти», хранящийся в %SystemRoot%\MEMORY.DMP (т.е. файл MEMORY.DMP внутри системной папки Windows). Параметры для включения автоматического создания дампов памяти, используемые по умолчанию вы также можете увидеть на скриншоте ниже.

Картинка с сайта: remontka.pro

Опция «Автоматический дамп памяти» сохраняет снимок памяти ядра Windows 10 с необходимой отладочной информацией, а также память, выделенную для устройств, драйверов и ПО, работающего на уровне ядра. Также, при выборе автоматического дампа памяти, в папке C:\Windows\Minidump сохраняются малые дампы памяти. В большинстве случаев этот параметр оптимален.

Помимо «Автоматический дамп памяти» в параметрах сохранения отладочной информации есть и другие варианты:

Полный дамп памяти — содержит полный снимок оперативной памяти Windows. Т.е. размер файла дампа памяти MEMORY.DMP будет равен объему используемой (занятой) оперативной памяти на момент появления ошибки. Обычному пользователю обычно не требуется.
Дамп памяти ядра — содержит те же данные что и «Автоматический дамп памяти», по сути это одна и та же опция, за исключением того, как Windows устанавливает размер файла подкачки в случае выбора одной из них. В общем случае вариант «Автоматический» подходит лучше (подробнее для интересующихся, на английском — здесь.)
Малый дамп памяти — создание только мини дампов в C:\Windows\Minidump. При выборе данной опции сохраняются файлы по 256 Кб, содержащие базовую информацию о синем экране смерти, списке загруженных драйверов, процессах. В большинстве случаев при непрофессиональном использовании (например, как в инструкциях на этом сайте по исправлению ошибок BSoD в Windows 10), используется именно малый дамп памяти. Например, при диагностике причины синего экрана смерти в BlueScreenView используются файлы мини дампов. Однако в некоторых случаях может потребоваться и полный (автоматический) дамп памяти — часто службы поддержки ПО при возникновении неполадок (предположительно вызванных этим ПО) могут просить предоставить именно его.

Дополнительная информация

В случае, если вам нужно удалить дамп памяти, вы можете сделать это вручную, удалив файл MEMORY.DMP в системной папке Windows и файлы, содержащиеся в папке Minidump. Также можно использовать утилиту «Очистка диска» Windows (нажать клавиши Win+R, ввести cleanmgr и нажать Enter). В «Очистке диска» нажмите кнопку «Очистить системные файлы», а затем в списке отметьте файла дампа памяти для системных ошибок, чтобы удалить их (при отсутствии таких пунктов можно предположить, что дампы памяти пока не создавались).

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

Источник

Время на прочтение4 мин

Количество просмотров8.3K

Статья представляет собой мануал по тому как пользоваться Windbg. Будет рассмотрена «классическая» версия отладчика. Настроим внешний вид и изучим команды, которые можно использовать для исследования приложения.

Установка

Установка возможна только при использовании Windows SDK. Версию для Windows 10 можно найти здесь. Для работы с отладчиком необходимо запустить процесс установки SDK и выбрать только опции с набором инструментов для отладки. Пример выбора представлен на снимке ниже.

После установки набора инструментов, можно найти все файлы в директории «Windows Kits». Отладчик устанавливается сразу для нескольких версий процессоров. Для выполнения дальнейших команд в мануале нужно выбирать соответствую исследуемому файлу архитектуру процессора. Для исследования возьмем вот этот файл и попробуем найти ключ. Перед началом исследования файла, рекомендуется сделать дополнительную настройку:

Установить директорию и сервер для отладочных символов Проще всего это сделать можно через меню: File → Symbol File Path. В открывшемся меню нужно прописать вот эту строку: «SRV*C:\symbols*http://msdl.microsoft.com/download/symbols». Затем создать директорию C:\symbols;
Установить WorkPlace с удобной раскладкой рабочих панелей. Взять готовый Workspace можно отсюда. В итоге, если запустить для теста notepad.exe в отладчике, он будет выглядеть вот так:

Теперь можно перейти к исследованию команд. Откроем в отладчике файл и приступим.

Набор команд и анализ приложения

Полный справочник по всем командам отладчика можно найти по команде «.hh». Появится справка, как на рисунке ниже. Здесь можно вводить описание или конкретную команду.

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

Определим откуда начинается выполнение приложения. Если не вдаваться в подробности, то самое начало работы приложения это EntryPoint из заголовка файла, однако это не совсем так. EntryPoint для современных языков программирования сегодня это начало подготовительных операций для работы всего приложения. Поэтому если необходимо найти код, который был написан программистом, нам придется еще немного попутешествовать по дизасемблированному листингу.

Первая команда — lm. Показывает список модулей, которые загружены в память процесса, по выдаче этой команды можно получить базовый адрес файла.

Главные команды, которые станут глазами и ушами при исследовании данных в оперативной памяти — d? (b,c,a,p,w,q). Команда показывает дамп памяти по указанному адресу. Можно использовать конкретный адрес или регистр. Например, можно посмотреть как выглядит часть заголовка файла в памяти:

Команда !dh разбирает файл и показывает заголовки. Нам нужен файловый заголовок, поэтому добавим флаг -f. Если необходимо показать все данные о файловых и секционных заголовках, то можно не дополнять команду.

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

Локализуем точку входа с помощью суммирования базового адреса и информации из заголовка. Выполнить эту опирацию можно рядом команд: ? — выполнение выражения, uf — дизассемблирование функции, bp — установка точки останова. А теперь по порядку на примере:

Расчет адреса.

Дизассемблирование функции от адреса до ret команды.

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

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

Как только алгоритм загрузчика ОС выполнит все подготовительные действия мы увидим в командной строке следующие данные:

Можно приступать к поиску функции main. Сделать это достаточно просто, необходимо локализовать константы из интерфейса файла, когда выполняется приветствие и запрос данных:

Для поиска данных будем использовать команду s. Эта команда проводит поиск по определенному в команде объему данных. Соответственно чтобы получить данные о местоположении приглашения к вводу ключа, нужно указать всё адресное пространство исследуемого приложения. Так же необходимо указать тип данных, которые нужно искать.

Теперь, когда мы знаем адрес данных, которые используются, мы можем поставить точку останова, которая будет следить за доступом к данным. Сделать это можно с помощью команды ba. Для такой точки останова нужно указывать размер данных за которыми отладчик будет наблюдать, а там же адрес и тип доступа. Адрес должен быть выровнен по границе в 4 байта. После остановки снова нужно запустить приложение через команду g. На рисунке ниже показан вариант команды:

Когда сработает точка останова, нужно найти часть алгоритма приложения, которая печатает приветствие на экран. Для этого удобно использовать стек вызовов функций. Для этого можно выполнить команду k.

Из рисунка видно, что копирование строки для работы с ней выполняется библиотечной функцией, а её вызов был сделан из «For_Crackme+0x15f2».

2. Локализуем функцию проверки ключа. Функция проверки будет недалеко от предложения ввести данные пользователя. В прошлом этапе мы нашли смещение внутри функции до этой операции. Введем можифицированную команду uf — u для того чтобы посмотреть несколько команд после адреса "For_Crackme+0x15f":

Фрагмент кода не содержит дополнительных отладочных символов, поэтому просто просмотрим данные рядом:

offset For_Crackme+0x40a2
offset For_Crackme+0x40bb

Чтобы это сделать, используем команду db:

Похоже, что функция подготавливает данные для выдачи информации пользователю. Значит проверка ключа должна быть где-то рядом. Обратим внимание на 2 константы, которые помещаются в память через следующие команды:

...
00401612 c744241c30372f31 mov     dword ptr [esp+1Ch],312F3730h
0040161a c7442420302f3937 mov     dword ptr [esp+20h],37392F30h
...

Если раскодировать константы, то мы получим вот такое значение: «07/10/97». Выполнить раскодирование может помочь команда .formats 312F3730h. Из списка форматов нас интересует Char или символьное представление. Стоит помнить, что данные в памяти хранятся в LittleEndian формате, поэтому если прочитать наоборот, то получатся данные необходимые для прохождения валидации.

Таким образом можно анализировать приложения с использованием Windbg и не прибегать к дополнительному инструментарию.

Статья написана в преддверии старта курса «Reverse-Engineering. Professional». Напоминаем о том, что завтра пройдет второй день бесплатного интенсива по теме «Пишем дампер процессов». Записаться на интенсив можно по ссылке ниже:

ЗАПИСАТЬСЯ НА БЕСПЛАТНЫЙ ИНТЕНСИВ

Источник

Дамп памяти – это очень важный инструмент для диагностики и исправления ошибок в Windows 10. Он представляет собой полный снимок состояния операционной системы и всех запущенных процессов в момент возникновения сбоя.

Включение дампа памяти в Windows 10 может предоставить ценную информацию при диагностике системных проблем. При возникновении системной ошибки, такой как синий экран смерти (BSOD), Windows 10 может создать файл дампа памяти, содержащий информацию о состоянии системы на момент возникновения ошибки. Этот файл можно проанализировать, чтобы определить первопричину проблемы и помочь ее устранить.

Чтобы включить дамп памяти в Windows 10, выполните следующие действия. Нажмите правой кнопкой мыши по значку «Мой компьютер» и выберите «Свойства». В открывшемся окне выберите «Дополнительные параметры системы».

В окне «Свойств системы» перейдите на вкладку «Дополнительно». В разделе «Загрузка и восстановление» нажмите на «Параметры».

В окне «Загрузка и восстановление» в разделе «Отказ системы» установите флажок в «Записать событие в системный журнал» и установите флажок в «Выполнить автоматическую перезагрузку».

В том же окне в разделе «Запись отладочной информации» выберите тип дампа памяти, который вы хотите создать. Вы можете выбрать один из следующих вариантов.

Автоматический дамп памяти: Этот тип дампа памяти сохраняет снимок ядра с необходимой информацией для отладки.
Малый дамп памяти (256 КБ): Этот тип дампа памяти содержит наименьший объем информации и полезен для большинства целей.
Дамп памяти ядра: Этот тип дампа памяти содержит больше информации, чем малый дамп памяти, и полезен для отладки проблем в режиме ядра .
Полный дамп памяти: Этот тип дампа памяти содержит все содержимое физической памяти и может быть очень большим.
Обратите внимание, что для опции полного дампа памяти требуется файл подкачки по крайней мере того же размера, что и объем физической памяти, установленной в системе.
Активный дамп памяти работает также, как и предыдущий. Отличие его заключается в том, что он фильтрует страницы, которые связанны с устранением проблем на хост компьютере.

Затем выберите папку, в которой должен сохраняться дамп памяти. Рекомендуется выбирать папку на другом диске, чтобы в случае сбоя диск с дампом не повредился.

Нажмите кнопку ОК для сохранения изменений. Чтобы изменения вступили в силу, необходимо перезагрузить компьютер.

Теперь Windows 10 будет создавать дамп памяти в случае сбоя. Он может быть очень полезен при диагностировании и устранении ошибок в системе. Однако следует иметь в виду, что размер полного дампа памяти может быть очень большим (обычно несколько гигабайт), поэтому необходимо обеспечить достаточно места на диске для его сохранения. Также следует помнить, что создание дампа памяти может занять довольно продолжительное время, поэтому при возникновении сбоя необходимо дождаться завершения процесса.

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

Легкий доступ к информации о системных ошибках: При возникновении системной ошибки файл дампа памяти можно использовать для быстрого определения причины проблемы.
Улучшенная отладка: Дампы памяти могут предоставить подробную информацию о состоянии системы на момент возникновения ошибки, что облегчает диагностику и решение проблем.
Более быстрое решение проблем: Дампы памяти могут помочь определить первопричину системных проблем, что позволяет быстрее решать проблемы и повышать производительность системы.
Повышение стабильности системы: Включив функцию дампа памяти, пользователи могут обнаружить и устранить проблемы, которые могут вызвать сбои системы и другие проблемы стабильности.
Ценная информация для разработчиков программного обеспечения: Дампы памяти могут предоставить разработчикам программного обеспечения ценную информацию, которая поможет им выявить и устранить ошибки и проблемы в программном обеспечении.
Расширенный поиск и устранение неисправностей: Дампы памяти обеспечивают расширенные возможности поиска и устранения неисправностей, позволяя пользователям выявлять и устранять сложные системные проблемы, которые трудно диагностировать другими способами.
Улучшение производительности системы: Выявляя и устраняя системные проблемы, дампы памяти могут помочь улучшить производительность системы и сократить время простоя.

Утилиты

Существует возможность создания дампа памяти с помощью специальных утилит, таких как WinDbg или ProcDump. Эти утилиты позволяют создавать дамп памяти выбранных процессов или даже отдельных потоков, что может быть полезно при диагностировании проблем, связанных с конкретными приложениями или процессами.

Процесс создания дампа памяти с помощью WinDbg или ProcDump может быть более сложным и требовать дополнительных знаний, но в целом он сводится к следующим простым шагам:

установка утилиты WinDbg или ProcDump;
запуск утилиты и указание параметров для создания дампа памяти;
ожидание завершения создания дампа памяти.

Для создания дампа памяти с помощью WinDbg необходимо запустить утилиту и подключиться к отладочному сеансу, который может быть создан на локальном компьютере или на удаленном компьютере. Затем можно использовать команду «.dump» для создания дампа памяти.

Для создания дампа памяти с помощью ProcDump необходимо запустить утилиту и указать параметры для создания дампа памяти, такие как PID процесса, для которого необходимо создать дамп, или тип события, при возникновении которого должен быть создан дамп.

Использование специальных утилит для создания дампа памяти может быть полезным при диагностировании сложных проблем в Windows 10.

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

Post Views: 462

Источник