Аварийный дамп памяти

Общие сведения об аварийном дампе памяти

Все Windows-системы при обнаружении фатальной ошибки делают аварийный дамп (снимок) содержимого оперативной памяти и сохраняет его на жесткий диск. Существуют три типа дампа памяти:

Полный дамп памяти – сохраняет все содержимое оперативной памяти. Размер снимка равен размеру оперативной памяти + 1 Мб (заголовок). Используется очень редко, так как в системах с большим объемом памяти размер дампа будет слишком большим.

Дамп памяти ядра – сохраняет информацию оперативной памяти, касающуюся только режима ядра. Информация пользовательского режима не сохраняется, так как не несет в себе информации о причине краха системы. Объем файла дампа зависит от размера оперативной памяти и варьируется от 50 Мб (для систем с 128 Мб оперативной памяти) до 800 Мб (для систем с 8 Гб оперативной памяти).

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

Настройка системы

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

Проделав все манипуляции, после каждого BSoD в папке C:WINDOWSMinidump будет сохраняться файл с расширение .dmp. Советую ознакомиться с материалом “Как создать папку”. Также можно установить галочку на “Заменить существующий файл дампа”. В этом случае каждый новый аварийный дамп будет записываться поверх старого. Я не советую включать данную опцию.

Анализ аварийного дампа памяти с помощью программы BlueScreenView

Итак, после появления синего экрана смерти система сохранила новый аварийный дамп памяти. Для анализа дампа рекомендую использовать программу BlueScreenView. Её можно бесплатно скачать тут. Программа довольно удобная и имеет интуитивный интерфейс. После её установки первое, что необходимо сделать – это указать место хранение дампов памяти в системе. Для этого необходимо зайти в пункт меню “Options” и выбрать “Advanced Options”. Выбираем радиокнопку “Load from the following Mini Dump folder” и указываем папку, в которой хранятся дампы. Если файлы хранятся в папке C:WINDOWSMinidump можно нажатием кнопки “Default”. Нажимаем OK и попадаем в интерфейс программы.

Программа состоит из трех основных блоков:

Блок главного меню и панель управления;
Блок списка аварийных дампов памяти;
В зависимости от выбранных параметров может содержать в себе:

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

В блоке списка дамп памяти (на рисунке помечен цифрой 2) выбираем интересующий нас дамп и смотрим на список драйверов, которые были загружены в оперативную память (на рисунке помечен цифрой 3). Розовым цветом окрашены драйвера, которые находились в стеке памяти. Они то и являются причиной появления BSoD. Далее переходите в Главное меню драйвера, определяйте к какому устройству или программе они принадлежат. В первую очередь обращайте внимание на не системные файлы, ведь системные файлы в любом случае загружены в оперативной памяти. Легко понять, что на изображении сбойным драйвером является myfault.sys. Скажу, что это программа была специально запущена для вызова Stop ошибки. После определения сбойного драйвера, необходимо его либо обновить, либо удалить из системы.

Для того чтобы программа показывала список драйверов находящихся в стеке памяти во время возникновения BSoD необходимо зайти в пункт меню “Options” кликаем на меню “LowerPaneMode” и выбираем “OnlyDriversFoundInStack” (или нажмите клавишу F7), а для показа скриншота ошибки выбираем “BlueScreeninXPStyle” (F8). Что бы вернуться к списку всех драйверов, необходимо выбрать пункт “AllDrivers” (F6).

Буду признателен, если воспользуетесь кнопочками:

Какие параметры существуют?

Параметры указываются после указания самой команды, через пробел. На сайте Майкрософт не совсем понятно написано как работать с параметрами. Поэтому пришлось еще поискать информации — нашел. Итак, смотрите:

Читать еще: Как скрытые папки сделать видимыми win 7

Вы открываете консоль. Как — написал выше.

Далее нужно прописать dumpchk.exe. Если установили Debugging Tools for Windows (DTW) — указывайте в таком виде:

C:Program FilesDebugging Tools for Windows (x86)dumpchk.exe

Нужно прописывать полный путь. Если установили средства поддержки — возможно команда будет в папке:

Кстати, возможно Debugging Tools for Windows и есть средства поддержки.

Далее нужны файлы символов, мы выяснили, они находятся здесь:

Аварийный файл находится как правило здесь (название файла приведено для примера):

В итоге чтобы запустить команду поиска символов для анализа дампа (возможно неправильно написал, заранее прошу прощение) необходимо написать:

“C:Program FilesDebugging Tools for Windows (x86)dumpchk.exe” -y C:WINDOWSSymbols C:WINDOWSMinidumpMini010609-01.dmp

Буква -y в строке — параметр, необходим как раз для поиска символов. Кроме него есть другие:

-? — показывает справку по команде.
-p — печатает только заголовок, не совсем понятно что имеется ввиду.
-v — режим подробного вывода.
-c — проверка файла дампа.
-x — дополнительная проверка.
-e — анализ дампа.
-q — быстрая проверка (не применима в XP).

Также с dumpchk.exe может быть ошибка (Application Error):

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

Просмотр полного дампа памяти MEMORY.DMP.

Чтобы посмотреть содержимое полного дампа памяти необходимо открыть файл MEMORY.DMP при помощи утилиты WinDBG, которая входит в пакет Microsoft Windows SDK. Скачать эту утилиту можно с официального сайта Майкрософт по этой ссылке https://developer.microsoft.com/ru-ru/windows/downloads/windows-10-sdk .

Установка и настройка WinDBG.

Запускаем установку пакета Windows Software Development KIT и на этапе выбора компонентов отмечаем “Debugging Tools for Windows”.

При первом запуске WinDBG необходимо выполнить настройку сервера отладочных символов.
1. Переходим в меню File > Symbol File Path и вставляем строку:

где C:symbol_cache – это директория куда будут загружаться символы.

2. Сохраняем настройку File > Save Workspace.

Просмотр и анализ файла MEMORY.DMP.

Открываем файл MEMORY.DMP: File > Open Crash Dump. Начинается процесс загрузки отладочных символов, в этот момент внизу будет видна надпись: Debugee not connected.

По окончанию загрузки появится подсказка: “для анализа этого файла запустите !analize-v”.

Щелкаем по надписи !analize-v и запускается анализ дампа. В этот момент в строке состояние будет надпись *BUSY*.

По завершении обработки файла дампа памяти Windows нам необходимо найти среди полученной информации модуль, который вызвал сбой в работе. Найти сбойный модуль можно в строках MODULE_NAME и IMAGE_NAME.

В моем случае произошел сбой в работе драйвера srv.sys. В строке MODULE_NAME имя представлено в виде ссылке, щелкнув по которому можно получить информацию о модуле.

После выявления драйвера послужившего причиной сбоя в работе Windows и появления “Синего экрана смерти” необходимо попытаться обновить его.

Большинство проблем с драйверами решаются их обновлением.

Шаг 3 — Анализ дампа памяти

Теперь все сводится к выполнению одной команды. Откройте командную строку и перейдите в папку, в которую вы распаковали kdfe.cmd. Запустите файл, указав в качестве параметра путь к файлу дампа памяти (в примере ниже файл называется Mini1110307-01.dmp)

Через минуту вы увидите результат.

Драйвер, послуживший причиной ошибки, определен!

Что это за папка Minidump

Не все сбои вашей ОС приведут к созданию dmp-документа, в основном это глобальные баги. Размещается малый дамп памяти в директории системного диска: C:WindowsMinidump и только тут. Название самого файла несколько видоизменено, а его основа состоит из даты, когда произошла ошибка. То есть, можно увидеть что-то наподобие этого: 091117-0913-01.dmp. Главное обращайте внимание на окончание оно всегда имеет расширение DMP.

Папка Минидамп содержит dmp-файлы сбоев

Эксклюзивным моментом, который ранее не встречался, становится следующее – для создания дампа обязательно должен быть включен файл подкачки и иметь показатель в 2 Мб. Этот параметр непосредственно влияет на изготовление информационного листа и без него директория просто не появится.

Другие программы, связанные с расширением DMP

Файл дампа ORACLE

Oracle Corporation

Читать еще: Где находится корневая папка на андроид

Популярность:

Файл дампа клиента Steam

Valve Corporation

/tmp/dumps

crash_YYYYMMDDHHMMSS_N.dmp

Популярность:

Файл карты Dream Maker

BYOND

Популярность:

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

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

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

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

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

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

Основные моменты, на которые вы должны обратить внимание при анализе после выполнения команды !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:
——————

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

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

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

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

Расшифровка кода ошибки: В этом приложении система обнаружила переполнение буфера стека, что может позволить злоумышленнику получить контроль над этим приложением.

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:ProgramDatadbgsymntoskrnl.exe5A9A2147787000ntoskrnl.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: SystemRootsystem32driverscmudaxp.sys
Image name: cmudaxp.sys

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

Почему возникает и как исправить?

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

All replies

Loading page content

Page content loaded

I have exactly the same problem, it’s preventing me from setting up my new iphone 8+ because I can’t start itunes.

Nov 25, 2017 11:53 AM

If iTunes is apparently installed correctly try the following in turn until iTunes opens/closes/reopens normally:

Remove any SD card that might be in a card reader.
Exit the BTTray.exe Bluetooth utility if installed.
Locate the shortcut for iTunes, right-click on it, and select Run as administrator. Doing this once may fix certain launch issues. Some users were finding that with the 12.6.1.25 build they had to use this method every time and modified the shortcut accordingly.
Try holding ctrl+shift as you launch iTunes so it opens in safe-mode. Again doing this once may sometimes help.
Try disconnecting your computer from the Internet before running iTunes.
Delete the iTunes shortcuts from the start menu, desktop, task bar, or similar, then repair iTunes from the programs and features control panel.
Try Fix unexpected quits or launch issues in iTunes for Windows – Apple Support and test the behaviour in a different user profile or with a different library. If the problem only exists in your profile it may be possible delete some of the iTunes preference files which it would seem that iTunes may be choking on. We can go into details later if the issue is limited to your own profile.
Temporarily disable any non-Microsoft anti-virus and see if that has any impact on the behaviour.
See the second box in Troubleshooting issues with iTunes for Windows updates for detailed tear down and rebuild advice. Disable any non-Microsoft anti-virus software when reinstalling and run the installer as the administrator.
Or see the iTunes installers section of the troubleshooting tip and reinstall the last version that worked correctly for you.

Nov 25, 2017 11:56 AM

Question: Q: iTunes 12.7.1.14 Crashed More Less

голоса

Рейтинг статьи