Меню Рубрики

Как сделать анализ дампа памяти

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

На примере актуальной операционной системы 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.

С помощью 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 входит в «Пакет SDK для Windows 10» (Windows 10 SDK). Скачать можно здесь.

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

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

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

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

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

  1. Откройте командную строку от имени администратора и выполните команды для 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
  2. В результате типы файлов: .DMP, .HDMP, .MDMP, .KDMP, .WEW – будут сопоставлены с 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 произведет поиск символов в локальной папке и, если не обнаружит в ней необходимых символов, то самостоятельно загрузит символы с указанного сайта. Если вы хотите добавить собственную папку с символами, то можно сделать это так:

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

Отладчик 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:\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

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

источник

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

Как и мне, так и многим другим пользователям приходилось наблюдать появление экрана с синим фоном, на котором что-то написано (белым по синему). Данное явление говорит о критической неполадке, как в программном обеспечении, например, конфликт драйверов, так и в физической неисправности какого-то компонента компьютера.

Недавно у меня снова появился голубой экран в Windows 10, но я быстро от него избавился и скоро об этом вам расскажу.

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

Есть три типа дампа памяти:

Полный дамп памяти – эта функция позволяет полностью сохранить содержимое оперативной памяти. Он редко используется, так как представьте, что у вас 32 Гб оперативной памяти, при полном дампе весь этот объем сохранится на диске.

Дамп ядра – сохраняет информацию о режиме ядра.

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

Расположение, как малого, так и полного дампа отличается, например, малый дамп находится по следующему пути: %systemroot%\minidump.

Полный дамп находится здесь: %systemroot%.

Для анализа дампов памяти существуют различные программы, но мы воспользуемся двумя. Первая — Microsoft Kernel Debuggers, как понятно из названия утилита от Microsoft. Скачать ее можно с официального сайта. Вторая программа – BlueScreenView, бесплатная программка, скачиваем отсюда.

Для разных версий систем нужно скачивать свой тип утилиты. Например, для 64-х разрядной операционной системы, нужна 64-битовая программа, для 32-х разрядной – 32-битная версия.

Это еще не все, вам нужно скачать и установить пакет отладочных символов, нужные для программы. Называется Debugging Symbols. Каждая версия данного пакета тоже скачивается под определённою ОС, для начала узнайте какая у вас система, а потом скачивайте. Дабы вам не искать где попало эти символы, вот ссылка на скачивание. Установка, желательно, должна производиться по этому пути: %systemroot%\symbols.

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

Прежде чем проанализировать дампы мы кое-что настроим в утилите. Во-первых, нужно указать программе, куда мы установили отладочные символы. Для этого нажимаем на кнопку «File» и выбираем пункт «Symbol File Path», потом указываем путь до символов.

Программа позволяет извлекать символы прямо из сети, поэтому вам даже не придется их скачивать (извините те, кто уже скачал). Они буду браться с сервером Microsoft, поэтому все безопасно. Итак, вам нужно снова открыть «File», потом «Symbol File Path» и ввести следующую команду:

SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

Таким образом мы указали программе, что символы должны браться из сети. Как только мы это сделали нажимаем «File» и выбираем пункт «Save Workspace», потом жмем ОК.

Читайте также:  Мужские гормоны при беременности какие анализы

Вот и все. Мы настроили программу на нужный лад, теперь приступаем к анализу дампов памяти. В программе нажимаем кнопочку «File», потом «Open Crash Dump» и выбираем нужный файл.

Kernel Debuggers начнет анализ файла и после этого выведет результат о причине ошибки.

В появившемся окне можно вводить команды. Если мы введем !analyze –v , то получим больше информации.

Вот и все с этой программой. Чтобы остановить работу отладчика, выберите «Debug» и пункт «Stop Debugging».

Скачайте программу по указанной выше ссылке и установите. После запуска утилиты нужно ее настроить. Зайдите в параметры: «Настройки» — «Дополнительные параметры». Откроется небольшое окошко, в котором есть пару пунктов. В первом пункте нужно указать местонахождение дампов памяти. Обычно они находятся по пути C:\WINDOWS\Minidump. Тогда просто нажмите кнопку «По умолчанию».

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

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

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

В интернете можно найти все о коде ошибке и драйвере, который может быть виной BSoD. Для этого нажимаем «Файл», а потом «Найти в Google код ошибки + Драйвер».

Можно сделать показ только драйверов, которые были на момент появления ошибки. Для этого нужно нажать «Настройки» — «Режим нижнего окна» — «Только драйвера, найденные в крэш-стеке». Либо нажать клавишу F7.

Чтобы показать скриншот BSoD нажмите клавишу F8.

Для показа всех драйверов и файлов нажимаем F6.

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

Также не забывайте задавать вопросы в комментариях.

источник

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

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

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

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

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

Для Windows Xp
  1. Правой клавишей мыши нажать на значке Мой компьютер из контекстного меню выберите Свойства (или комбинация клавиш Win+Pause);
  2. Переходите на вкладку Дополнительно;
  3. В поле Загрузка и восстановление необходимо нажать кнопку Параметры;
  4. В поле Запись отладочной информации выбираем Малый дамп памяти (64 Кб).
источник

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

Сначала нужно убедиться, что запись дампов включена. Для этого нужно открыть свойства системы, нажав комбинацию клавиш Win+Pause, [в Vista щелкнуть ссылку Дополнительные параметры системы], перейти на вкладку Дополнительно, и наконец нажать кнопку Загрузка и восстановление.

Малых дампов памяти должно быть достаточно для наших целей.

Обратите внимание на путь к папке, куда они будут сохраняться при возникновении критической ошибки.

Теперь вы можете запаковать файл в архив, прикрепить его к сообщению в форуме Устранение критических ошибок Windows и подождать, пока вам кто-то сообщит название проблемного драйвера 🙂 Но вы можете сделать это самостоятельно, не прилагая больших усилий.

Рассказ об утилите вы найдете в этой статье.

Ранее в этом материале я рекомендовал kdfe.cmd, но MiniDumper проще и удобнее. Сведения о kdfe.cmd остаются тут для истории.

Это не так страшно, как можно подумать 🙂

  1. Загрузите и установите Debugging Tools for Windows. Они входят в состав веб-установщика Windows SDK, где после запуска в нужно выбрать Debugging Tools в разделе Common Utilities.
  2. Загрузите сценарий (kdfe.cmd), который написал Александр Суховей и опубликовал на ресурсе sysadmins.ru (поскольку живую ссылку мне там найти не удалось, предлагаю свою). Распакуйте архив в любую папку.
    Примечание. В случае нестандартного расположения папки Program Files вам может потребоваться указать в kdfe.cmd путь к папке, в которую установлены средства Debugging Tools for Windows. Используйте переменную dbgpath в строке 41.

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

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

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

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

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

Метки: BSOD Информация в статье применима к Windows 7 и новее

Вадим является владельцем этого блога, и большинство записей здесь вышло из-под его пера. Подробности о блоге и авторе здесь.

Подпишитесь на бесплатные уведомления о новых записях и получите в подарок мою книгу об ускорении загрузки Windows!

источник

Инструкция по интерпретации файла малого дампа памяти .

Очень часто можно встретить вопросы, связанные с появлением синего экрана смерти (Blue Screen Of Death = BSOD ). Однако практически любой человек может самостоятельно определить причину возникновения ошибки, которая привела к появлению BSOD . Дело в том, что во время появления синего экрана на жесткий диск записывается специальный файл , который называется Малый Дамп Памяти (конечно, при условии, что его запись разрешена в настройках).

Включить запись Малого Дампа можно следующим образом:

1. Нажмите кнопку Пуск и выберите в меню Настройка пункт Панель управления .

2. Дважды щелкните значок Система .

3. Откройте вкладку Дополнительно и нажмите кнопку .

4. В списке Запись отладочной информации выберите Малый дамп памяти (64 КБ) .

В файле малого дампа памяти записывается минимальный набор полезной информации, позволяющей определить причину неожиданного сбоя компьютера . Для этого параметра на загрузочном томе требуется файл подкачки размером не менее 2 МБ . На компьютерах с операционной системой Microsoft Windows 2000 или более поздними версиями Windows при непредвиденном сбое компьютера каждый раз создается новый файл.

При возникновении следующей ошибки и создании второго файла малого дампа памяти Windows сохраняет предыдущий файл. Windows присваивает каждому файлу отдельное имя с указанием даты. Например, Mini022900-01.dmp — это первый файл дампа памяти, созданный 29 февраля 2000 г. Список всех файлов малого дампа памяти хранится в папке %SystemRoot%\Minidump.

Для загрузки файлов малого дампа памяти можно воспользоваться служебной программой Dump Check (Dumpchk.exe). Программа Dumpchk.exe используется также для проверки правильности создания файла дампа памяти. Dump Check не требует доступа к символам отладки. Программа Dump Check входит в комплект средств поддержки Microsoft Windows 2000 Support Tools и Microsoft Windows XP Support Tools. Скачать данные пакеты вы можете, пройдя по данной ссылке http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Для интерпретации файлов малого дампа памяти можно воспользоваться также средствами WinDbg или the KD.exe . Программы WinDbg и KD.exe входят в последнюю версию пакета средств отладки для Windows.

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

  1. Нажмите кнопку Пуск , выберите пункт Выполнить , введите команду cmd и нажмите кнопку ОК .
  2. Перейдитевпапку «Debugging Tools for Windows». Для этого введите в командной строке

cd c:\program files\debugging tools for windows

  1. Для загрузки файла дампа памяти в программу отладки введите одну из следующих команд и нажмите клавишу ВВОД:

windbg -y путь_к_символу -i путь_к_образу -z путь_к_файлу_дампа

kd -y путь_к_символу -i путь_к_образу -z путь_к_файлу_дампа

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

Путь к этим файлам. Эти файлы содержатся в папке I386 на компакт-диске Windows XP. Пример пути: C:\Windows\I386.

Путь к анализируемому файлу дампа памяти и имя этого файла.

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

  • Команда !analyze -show отображает код неустранимой ошибки и ее параметры. Код неустранимой ошибки известен также как контрольный код неполадки.
  • Команда !analyze -v отображает подробный результат анализа.
  • Команда lm N T выводит список указанных загруженных модулей. Данные включают состояние и путь модуля.

Примечание . Команда с раширением !drivers выводит список всех драйверов, загруженных на конечный компьютер, а также сведения об используемой ими памяти. Расширение !drivers не используется в Windows XP и более поздних версиях. Для отображения сведений о загруженных драйверах и других модулях воспользуйтесь командой lm . Команда lm N T выводит сведения в таком же формате, как и устаревшее расширение !drivers .

Сведения о других командах и полном синтаксисе команд см. в справочной документации к средствам отладки. Справочная документация к средствам отладки размещается в файле: C:\Program Files\Debugging Tools for Windows\Debugger.chm

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

311503 (http://support.microsoft.com/kb/311503/) Получение файлов символов отладки с сервера символов Майкрософт

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

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

Для чего нам может потребоваться данное содержимое, то есть дамп памяти Windows ? Пожалуй, наиболее часто дамп памяти используется для изучения причин возникновения системного сбоя (), который явился причиной полного останова операционной системы. В дополнение к этому, состояние памяти может использоваться и для других целей. Немаловажен и тот факт, что дамп памяти — это буквально единственный способ получения информации о любом сбое! А снятие (получение) дампа памяти системы — это, фактически, единственный точный метод получения мгновенного отпечатка (копии) содержимого физической памяти системы.

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

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

Теоретически, статичность (неизменность) «отпечатка» памяти объясняется тем, что когда вызывается функция KeBugCheckEx , выводящая на экран информацию о сбое и стартующая процесс создания дампа памяти, система уже полностью остановлена и содержимое физической памяти записано в блоки, занимаемые на диске файлом подкачки, после чего, уже в процессе последующей загрузки операционной системы оно сбрасывается в файл на системном носителе. Ну а практически один раз наблюдал ситуацию, когда сбоящая материнская плата не давала сохранить дамп памяти: а) подвисая в процессе работы логики сохранения дампа (процесс не доходил до 100%), б) повреждая файл дампа памяти (отладчик ругался на структуры), в) записывая файлы дампов memory.dmp нулевой длины. Поэтому, не смотря на то, что система в момент создания дампа памяти уже полностью остановлена, и работает только аварийный код, сбойное железо может вносить свои коррективы в любую без исключения логику на любом этапе функционирования.
Традиционно, на начальном этапе для сохранения дампа памяти Windows используются блоки диска, выделенные файлу подкачки (pagefile). Затем, после возникновения синего экрана и перезагрузки, данные перемещаются в отдельный файл, а затем файл переименовывается по шаблону, зависящему от типа дампа. Однако, начиная с версии Windows Vista, подобное положение вещей возможно изменить, теперь пользователю дана возможность сохранять выделенный дамп без участия файла подкачки, помещая информацию о сбое во временный файл. Сделано это для того, чтобы исключить ошибки конфигурации, связанные с неправильной настройкой размера и положения файла подкачки, что зачастую приводило к проблемам в процессе сохранения дампа памяти.
Давайте посмотрим, какие же разновидности дампов позволяет нам создавать операционная система Windows:

  • Дамп памяти процесса (приложения);
  • Дамп памяти ядра;
  • Полный дамп памяти (дамп доступной части физической памяти системы).

Все аварийные дампы можно разделить на две основных категории:

  • Аварийные дампы с информацией о возникшем исключении . Обычно создаются в автоматическом режиме, когда в приложении/ядре возникает необрабатываемое исключение (unhandled exception) и, соответственно, может быть вызван системный (встроенный) отладчик. В этом случае информация об исключении записывается в дамп, что упрощает определение типа исключения и места возникновения при последующем анализе.
  • Аварийные дампы без информации об исключении . Обычно создаются пользователем в ручную, когда необходимо создать просто мгновенный снимок процесса для последующего анализа. Анализ этот подразумевает не определение типа исключения, поскольку никакого исключения и не возникало, а анализ совершенно другого рода, например изучение структур данных процесса и прочее.

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

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

  1. Нажать правой кнопкой мыши на значке «Мой Компьютер» — «Свойства» — «Дополнительные параметры системы» — «Дополнительно».
  2. Кнопка «Пуск» — «Панель управления» — «Система» — «Дополнительные параметры системы» — «Дополнительно».
  3. Сочетание клавиш «Windows» + «Pause» — «Дополнительные параметры системы» — «Дополнительно».
  4. control system.cpl,3
  5. Выполнить в командной строке (cmd):
    SystemPropertiesAdvanced

Результатом описанных действий является открытие окна «Свойства системы» и выбор вкладки «Дополнительно»:

После этого в разделе «Загрузка и восстановление» мы нажимаем выбираем «Параметры» и тем самым открываем новое окно под названием «Загрузка и восстановление»:

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

  1. Записать события в системный журнал.
  2. Выполнить автоматическую перезагрузку.
  3. Запись отладочной информации.
  4. Файл дампа.
  5. Заменять существующий файл дампа.

Как видите, многие параметры из списка достаточно тривиальны и просты в понимании. Однако, я бы хотел подробнее остановиться на параметре «Файл дампа». Параметр представлен в виде ниспадающего списка, и имеет четыре возможных значения:

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

  • Сообщение об ошибке.
  • Значение ошибки.
  • Параметры ошибки.
  • Контекст процессора (PRCB), на котором произошел сбой.
  • Сведения о процессе и контекст ядра (EPROCESS) для процесса, являющего причиной сбоя, со всеми его потоками.
  • Сведения о процессе и контекст ядра (ETHREAD) для потока, являющегося причиной сбоя.
  • Стек режима ядра для потока, который явился причиной сбоя.
  • Список загруженных драйверов.

Размещение: %SystemRoot%\Minidump\MMDDYY-XXXXX-NN.dmp . Где MMDDYY — месяц, день и год соответственно, NN — порядковый номер дампа.
Объем: Размер зависит от разрядности операционной системы: требуется всего-то 128 килобайт для 32-разрядной и 256 килобайт для 64-разрядной ОС в файле подкачки (либо в файле, указанном в DedicatedDumpFile). Поскольку выставить столь малый размер мы не сможем, то округляем до 1 мегабайта.

Данный тип дампа содержит копию всей памяти ядра на момент сбоя.
Состав:

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

В дампе памяти ядра отсутствуют нераспределенные страницы памяти и страницы пользовательского режима. Согласитесь, ведь маловероятно, что страницы процесса пользовательского режима будут нам интересны при системном сбое (BugCheck), поскольку обычно системный сбой инициируется кодом режима ядра.

Объем: Варьируется в зависимости от размера адресного пространства ядра, выделенной операционной системой и количества драйверов режима ядра. Обычно, требуется около трети объема физической памяти в файле подкачки (либо в файле, указанном в DedicatedDumpFile). Может варьироваться.

Полный дамп памяти содержит копию всей физической памяти (ОЗУ, RAM) в момент сбоя. Соответственно, в файл попадает и все содержимое памяти системы. Это одновременно преимущество и главный недостаток, поскольку размер его на некоторых серверах с большим объемом ОЗУ может оказаться существенным.
Состав:

  • Все страницы «видимой» физической памяти. Это практически вся память системы, за исключением областей, используемых аппаратной частью: BIOS, пространство PCI и прч.
  • Данные процессов, которые выполнялись в системе в момент сбоя.
  • Страницы физической памяти, которые не отображены на виртуальное адресное пространство, но которые могут помочь в изучении причин сбоя.

В полный дамп памяти не включаются, по-умолчанию, области физической памяти, используемой BIOS.
Размещение: %SystemRoot%\MEMORY.DMP . Предыдущий дамп перезаписывается.
Объем: В файле подкачки (либо в файле, указанном в DedicatedDumpFile) требуется объем, равный размеру физической памяти + 257 мегабайт (эти 257 Мб делятся на некий заголовок + данные драйверов). На деле же, в некоторых ОС, нижний порог файла подкачки можно выставить точно в значение размера физической памяти.

Начиная с Windows 8/Windows Server 2012, в систему введен новый тип дампа под названием «Автоматический дамп памяти», который устанавливается типом по умолчанию. В этом случае система сама решает, какой дамп памяти записать в ситуации того или иного сбоя. Причем логика выбора зависит от многих критериев, в том числе от частоты «падения» операционной системы.

После изменения конфигурации дампа памяти Windows, может потребоваться перезагрузка компьютера.

Раздел реестра, который определяет параметры аварийного дампа:

Параметр Тип Описание
AutoReboot REG_DWORD Включение/отключение автоматической перезагрузки при возникновении BSOD.
CrashDumpEnabled REG_DWORD Вид создаваемого дампа.
  • 0 — не создавать дамп памяти;
  • 1 — полный дамп памяти;
  • 2 — дамп памяти ядра;
  • 3 — малый дамп памяти;
DumpFile REG_EXPAND_SZ Путь и название дампа памяти ядра и полного дампа памяти.
DumpFilters REG_MULTI_SZ Драйвер-фильтр в стеке драйверов дампа памяти. Позволяет добавлять новый функционал на этапе создания аварийных дампов. Например, шифрование содержимого дампа. Изменять значение не рекомендуется.
LogEvent REG_DWORD Запись события в системный журнал.
MinidumpDir REG_EZPAND_SZ Путь и название малого дампа памяти.
MinidumpsCount REG_DWORD Максимальное количество малых дампов памяти. При превышении начинают затираться более старые версии.
Overwrite REG_DWORD Заменять существующий файл дампа. Только для дампа памяти ядра и полного дампа памяти.
IgnorePagefileSize REG_DWORD Игнорирует стандартный файл подкачки как место для временного (промежуточного) хранения дампа памяти. Указывает на необходимость записать дамп памяти в отдельный файл. Используется совместно с опцией DedicatedDumpFile.
DedicatedDumpFile REG_EZPAND_SZ Путь и название временного альтернативного файла для записи дампа памяти. Во втором проходе данные все равно будут перемещены в DumpFile/MinidumpDir.

Выше мы описывали настройки для автоматического создания аварийных дампов системы в случае возникновения критической ошибки, то есть необрабатываемого исключения в коде ядра. Но ведь в реальной жизни, помимо падения операционной системы, существуют ситуации, когда необходимо получить дамп памяти системы в конкретный момент времени. Как быть в этом случае? Существуют методы получения мгновенной копии всей физической памяти, например с помощью команды.dump в отладчиках WinDbg/LiveKD. LiveKD — программа, позволяющая запускать отладчик ядра Kd в функционирующей системе в локальном режиме. В отладчике WinDbg тоже имеется подобная возможность. Однако метод получения дампа «на лету» не точен, поскольку дамп создается в этом случае «противоречивый», так как для создания дампа требуется время, а в случае использования отладчика режима ядра система продолжает работать и вносить изменения в страницы памяти.

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

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

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

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

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

Для Windows Xp Для Windows 7
  1. Мой компьютерСвойства
  2. Переходите на вкладку Дополнительно;
  3. Параметры;
  4. В поле Запись отладочной информации выбираем Малый дамп памяти (64 Кб ).
  1. Правой клавишей мыши нажать на значке Компьютер из контекстного меню выберите Свойства (или комбинация клавиш Win+Pause);
  2. В левом меню щелкаем на пункт Дополнительные параметры системы ;
  3. Переходите на вкладку Дополнительно;
  4. В поле Загрузка и восстановление необходимо нажать кнопку Параметры;
  5. В поле Запись отладочной информации выбираем Малый дамп памяти (128 Кб ).

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

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

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

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

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

Для того чтобы программа показывала список драйверов находящихся в стеке памяти во время возникновения BSoD необходимо зайти в пункт меню “Options ” кликаем на меню “Lower Pane Mode ” и выбираем “Only Drivers Found In Stack ” (или нажмите клавишу F7), а для показа скриншота ошибки выбираем “Blue Screen in XP Style ” (F8). Что бы вернуться к списку всех драйверов, необходимо выбрать пункт “All Drivers ” (F6).

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

То, что вы отключите дамп памяти, никак не повлияет на быстродействие системы. Когда вы пользуетесь компьютером, система к дампу не обращается, будь он включен или нет. Запись происходит только тогда, когда Windows «довели» до BSOD (синий экран). Длится она от силы пару секунд.

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

Дамп ядра – самый распространенный вид дампа. Обычно именно эта опция задана по умолчанию. Записывает он в себя всю память, которая выделена на ядро, – состояние рабочих драйверах и данные о аппаратно-зависимом уровне. Для него нужно выделить около 30 % от общего объема ОЗУ. Например, если у вас 2 Гб DDR, значит выделяйте около 700 Мб для файла подкачки.

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

В Windows 7 параметры дампа запрятаны довольно глубоко. Введите в строе поиска в меню «Пуск » слово «система », например.

Выберите результат «Система ». Откроется окно. Справа вверху есть список опций, там выбирайте последнюю — «Дополнительные параметры системы ».

В Windows 8, Microsoft представила новый дамп памяти — опция автоматического дампа памяти. Этот параметр в операционной системе установлен по умолчанию. В Windows 10 ввели новый тип файла дампа — активный дамп памяти. Для тех, кто не знает, в Windows 7 у нас есть малый дамп, дамп ядра и полный дамп памяти. Вы можете удивиться, почему Microsoft решила создать этот новый параметр дамп памяти? По словам Роберта Симпкинса, старшего инженера поддержки, автоматический дамп памяти, может создать поддержку для страницы “системы” в файле конфигурации.
Система управления конфигурацией файла подкачки отвечает за управление размером файла подкачки – это позволяет избежать излишнего запаса или размера файла подкачки. Эта опция введена в основном для ПК, которые работают на SSD-дисках, которые, как правило, имеют меньший размер, но огромное количество оперативной памяти.

Главное преимущество “Автоматический дамп памяти” заключается в том, что это позволит сеансу подсистемы в диспетчере процессов автоматически уменьшить файл подкачки до размера, меньшего, чем размер оперативной памяти. Для тех, кто не знает, сессия диспетчера подсистемы отвечает за инициализацию системы, среду запуска служб и процессов, которые необходимы для входа пользователя в систему. Он в основном устанавливает страницу файлов в виртуальную память и запускает процесс winlogon.exe.

Если вы хотите изменить параметры автоматического дампа памяти, вот как это можно сделать. Нажмите клавиши Windows + X и выберите — Система. Далее нажмите на кнопку “Дополнительные параметры системы — Advance System Settings ”.

Нажмите на кнопку Дополнительные параметры системы.

Здесь вы можете увидеть выпадающее меню, где написано “Дополнительно”.

Здесь вы можете выбрать нужный вариант. Предлагаемые варианты:

Никаких дампов памяти.
Малый дамп памяти.
Дамп памяти ядра.
Полный дамп памяти.
Автоматический дамп памяти. Добавлены в Windows 8.
Активный дамп памяти. Добавили в Windows 10.
Расположение файла дампа памяти в файле %SystemRoot%\MEMORY.DMP.

Если вы используете SSD диск, то лучше оставить его на “Автоматический дамп памяти”; но если вы нуждаетесь в файле аварийного дампа, то лучше установить его на “малый дамп памяти”, с ним вы можете, если вы хотите, отправить его кому-то, чтобы он мог взглянуть на него.

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

он называется “LastCrashTime”.

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

В Windows 10 ввели новый файл дампа активный дамп памяти. Он содержит только самое необходимое и, следовательно, он меньшего размера.

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

Вы можете проанализировать дамп памяти Windows.dmp файлов с помощью WhoCrashed. Утилита WhoCrashed Home бесплатная, в ней представлены драйверы, которые были врезаны в ваш компьютер с помощью одного клика. В большинстве случаев она может определить не исправный драйвер, который причиняют страдания вашему компьютеру. Это краш-дамп анализа системы, дампы памяти и здесь представлена вся собранная информация в доступной форме.

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

WhoCrashed полагается на пакет отладки (программы windbg) от Microsoft. Если этот пакет не установлен, WhoCrashed будет сама скачивать и автоматически извлечёт этот пакет для вас. Просто запустите программу и нажмите на кнопку Анализ. Когда у вас есть WhoCrashed установленный в системе и, если он неожиданно сбрасывает или закрывается, программа даст вам знать, если аварийный дамп включен на вашем компьютере, и она будет предлагать Вам предложения о том, как их включить.

источник

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

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

Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).

Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.

BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.

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

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

По двойному клику отображается дополнительная информация.

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

Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки центра разработки.

Для анализа аварийных дампов установка SDK не требуется. Скачать Debugging Tools for Windows (WinDbg) отдельным пакетом можно здесь или здесь.

Загружаем и устанавливаем WinDbg для вашей версии Windows. Версия для Windows 7 работает также в Windows XP и в Windows Vista.

Для Windows 10 требуется WinDbg версии 10.0.10586.567. Скачиваем Изолированный пакет SDK для Windows 10. Будет загружен веб-установщик. При установке, отключаем все компоненты, кроме отладчика.

После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%\Minidump.

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

При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.

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

Если система не подключена к интернету, пакет для установки символов можно предварительно загрузить на странице загрузки пакетов символов Windows, центра разработки Microsoft.

В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.

Указываем путь к дампу %SystemRoot%\MEMORY.DMP или %SystemRoot%\Minidump\файл.dmp.

Загрузка отладочных символов из интернета может занять некоторое время.

Для получения детальной информации выполняем команду:

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

В результате получаем следующий вывод:

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

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%\system32\drivers.

Находим указанный файл, и изучаем его свойства.

Обновляем проблемный драйвер.

Источником критических ошибок нередко бывают неисправности в дисковой подсистеме, или в подсистеме памяти.

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

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

Проверяем параметры S.M.A.R.T жесткого диска, получить их можно, например, с помощью программы SpeedFan.

Особое внимание обращаем на параметры: «Current Pending Sector Count» и «Uncorrectable Sector Count», ненулевые значения этих параметров сигнализируют о неисправности диска.

Ненулевое значение параметра: «UltraDMA CRC Error Count», сигнализирует о проблеме с SATA-кабелем.

Подробнее о параметрах S.M.A.R.T. читаем в статье Википедии.

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

Выявить проблемы с памятью можно с помощью утилиты Memtest86+.

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

Начиная с Windows Vista, в системе имеется свой тест памяти. Для его запуска нажимаем «Пуск», в строке поиска набираем «памяти«, выбираем «Средство диагностики памяти Windows».

Проблемы с памятью в некоторых случаях могут быть устранены обновлением BIOS.

Для изменения параметров сохранения аварийного дампа нажимаем кнопку «Пуск», щелкаем на «Компьютер» правой кнопкой мыши, в контекстном меню выбираем «Свойства». В окне «Система» слева выбираем «Дополнительные параметры системы», в группе «Загрузка и восстановление» нажимаем кнопку «Параметры».

источник