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

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

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

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

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

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

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

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

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

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

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

Анализ дампа памяти с помощью Microsoft Kernel Debuggers

Для разных версий систем нужно скачивать свой тип утилиты. Например, для 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».

Анализ дампа памяти с помощью BlueScreenView

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

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

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

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

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

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

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

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

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

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

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

Когда в Windows 10 происходит неустранимая ошибка, которую система не в состоянии обработать, работа компьютера аварийно завершается, при этом создавая дамп памяти и выводя на экран информацию о причине ошибке. Этот экран называют синим экраном смерти (Blue Screen of Dead, BSOD). Но иногда BSOD необходимо вызвать специально, чтобы создать дамп памяти. Расскажу, как это сделать.

Как принудительно запустить BSOD и создать дамп памяти в Windows 10

1. Откройте редактор реестра: нажмите «Windows+R» , наберите «regedit» и нажмите «ОК» .

2. Создайте резервную копию реестра: «Файл» > «Экспорт» .

3. Перейдите к следующим ключам:

Для USB клавиатуры:

HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

Для PS\2 клавиатуры:

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

4. Создайте параметр типа DWORD с именем CrashOnCtrlScroll :

5. Зайдите в CrashOnCtrlScroll и измените значения с 0 на 1.

6. Нажмите «ОК» и «Перезапустите систему» , чтобы применить изменения.

Для отключения ручного вывода BSOD можно изменить параметр
CrashOnCtrlScroll на 0 или просто удалить его.

Как вызвать BSOD

После перезагрузки достаточно удерживать клавишу Ctrl и дважды нажать Scroll Lock. После этого система выпадет в синий экран.

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

HKLM\SYSTEM\CurrentControlSet\Control\CrashControl

И установить параметру AutoReboot значение 0.

Спасибо, что читаете! Подписывайтесь на мой канал в Telegram и Яндекс.Дзен . Только там последние обновления блога и новости мира информационных технологий. Также, читайте меня в социальных сетях: Facebook , Twitter , VK , OK .

Респект за пост! Спасибо за работу!

На данный момент есть возможность стать патроном , чтобы ежемесячно поддерживать блог донатом, или воспользоваться

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

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

Типы аварийных дампов памяти 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 МБ.

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

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

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

Настройка ассоциации.dmp файлов с 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.

Настройка сервера отладочных символов в 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: , 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

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

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 ,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

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

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

В ОС Windows очень часто случаются ошибки, даже в случае с «чистой» системой. Если обычные ошибки программ решить можно (появляется сообщение о недостающем компоненте), то исправить критические ошибки будет намного сложнее.

Что такое дамп памяти в Windows

Для решения проблем с системой обычно используют аварийный дамп памяти – это снимок части или полного объема оперативной памяти и помещение его на энергонезависимый носитель (жёсткий диск). Другими словами, содержимое оперативной памяти полностью или частично копируется на носитель, и пользователь может провести анализ дампа памяти.

Существует несколько видов дампов памяти:

Малый дамп (Small Memory Dump) – сохраняет минимальный объем ОЗУ, где находятся сведения по критическим ошибкам (BSoD) и компонентах, которые были загружены во время работы системы, например, драйвера, программы. MiniDump хранится по пути C:\Windows\Minidump.

Полный дамп (Complete Memory Dump) – сохраняется полный объем ОЗУ. Это значит, что размер файла будет равен объему оперативной памяти. Если места на диске мало, будет проблематично сохранить, например, 32 Гб. Также бывают проблемы с созданием файла дампа памяти более 4 Гб. Данный вид используется очень редко. Храниться по пути C:\Windows\MEMORY.DMP.

Дамп памяти ядра – сохраняется только информация, относящаяся к ядру системы.

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

Информация в реестре

Если заглянуть в реестр Windows, то можно обнаружить некоторые полезные параметры снимков. Щелкаем сочетание клавиш Win+R, вводим команду regedit и открываем следующие ветки:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

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

• AutoReboot – активация или отключение перезагрузки после создания синего экрана смерти (BSoD).
• DumpFile – название видов дампов и расположение.
• CrashDumpEnabled – номер создаваемого файла, например, число 0 – дамп не создается; 1 – создание полного дампа; 2 – создание дампа ядра; 3 – создание малого дампа.
• DumpFilters – параметр позволяет добавить новые функции перед созданием снимка. Например, шифрование файла.
• MinidumpDir – название малого дампа и его расположение.
• LogEvent – активация записи сведений в системный журнал.
• MinidumpsCount – задать количество создаваемых малых дампов. (Превышение этого количества будет уничтожать старые файлы и заменять их).
• Overwrite – функция для полного дампа или системного. При создании нового снимка, предыдущий будет всегда заменяться на новый.
• DedicatedDumpFile – создание альтернативного файла снимка и указание его пути.
• IgnorePagefileSize – используется для временного расположения снимка, без использования файла подкачки.

Как это работает

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

Обычно файл сохраняется в выделенном для файла подкачки блоке жёсткого диска, после появления BSoD файл перезаписывается в тот вид, который пользователь сам и настроил (Малый, полный или дамп ядра). Хотя, в современных ОС участие файла подкачки не обязательно.

Как включить дампы

В Windows 7 :

В Windows 8 и 10 :

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

Второй вариант для Wi ndows 10 :

Следует заметить, что в новых версиях Windows 10 появились новые пункты, которых не было в «семерке»:

• Малый дамп памяти 256 КБ – минимальные данные о сбое.
• Активный дамп – появился в десятой версии системы и сохраняет только активную память компьютера, ядра системы и пользователя. Рекомендуется использовать на серверах.

Как удалить дамп

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

Если никаких пунктов обнаружено не было, возможно дампы не были включены.

Даже если вы когда-то включали их, некоторые используемые утилиты по оптимизации системы могут легко отключить некоторый функционал . Часто много чего отключается при использовании SSD накопителей, так как многократные процедуры чтения и записи сильно вредят здоровью данного диска.

Анализ дампа памяти при помощи WinDbg

Скачиваем с официального сайта Microsoft данную программу на шаге 2, где описана «Установка WDK » — https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk .

Чтобы работать с программой еще понадобиться специальный пакет отладочных символов. Он называется Debugging Symbols , раньше его можно было скачать с сайта Microsoft, но теперь они отказались от этой идеи и придется использовать функцию программы File — «Symbol File Path », куда следует вписать следующую строчку и нажать ОК:

set _NT_SYMBOL_PATH=srv*DownstreamStore*https://msdl.microsoft.com/download/symbols

Если не сработало, пробуем вот эту команду:

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

Снова нажимаем пункт «File» и выбираем опцию «Save Workspace».

Утилита настроена. Остается указать путь до файлов дампов памяти. Для этого нажимаем File и щелкаем опцию «O pen Crash Dump ». Расположение всех дампов указано в начале статьи.

После выбора закончится анализ и проблемный компонент автоматически будет выделен. Для получения большего количества информации в этом же окошке можно ввести такую команду: !analyze –v

Анализ с помощью BlueScreenView

Загрузить инструмент бесплатно можно с этого сайта — http://www.nirsoft.net/utils/blue_screen_view.html . Установка не требует каких-то навыков. Используется только в Windows 7 и выше.

Запускаем и настраиваем. Нажмите «Настройки» (Options) – «Дополнительные параметры » (Advanced Options). Выберите первый пункт «Загружать МиниДампы из этой папки » и указываем каталог — C:\WINDOWS\Minidump . Хотя можно просто нажать кнопку «По умолчанию». Нажимаем ОК.

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

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

Теперь нажимаем «Файл» и выбираем, например, пункт «Найти в Go ogle код ошибки + драйвер ». Если нашли нужный драйвер, установите и перезагрузите компьютер. Возможно ошибка исчезнет.

Продолжу расскажу о синем экране смерти, начатый в .

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

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

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

Для этого нужно зайти в раздел Система .

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

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

Также здесь отображается путь к дампам — мы видим, что дамп сохраняется в папку %SystemRoot% — это обозначение папки Windows.

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

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

Для анализа дампов существуют специальные программы и одной из самых популярных является утилита BlueScreenView .

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

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

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

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

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

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

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

Также с помощью этой утилиты можно быстро найти местоположение проблемного файла на диске.

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

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

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

Ответ логичен и прост — нужно создать загрузочную флешку, с помощью которой «вытянуть» файл дампа с жесткого диска и проанализировать его на другом компьютере. Для этого загружаемся с флешки и на жестком диске компьютера в папке Windows или в подпапке minidump находим файл дампа, который копируем на флешку. Затем на другом компьютере с помощью утилиты BlueScreenView анализируем дамп, как было рассказано в этой заметке.