Здравствуйте друзья, сегодня разберем интересную тему, которая поможет вам в будущем при появлении синего экрана смерти (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 — системные исключения, которые пользователь видит в виде «синего экрана смерти» (BSOD). Как правило, эта фатальная ошибка возникает или из-за неисправности драйверов, оборудования (чаще при загрузке ОС) или из-за действия вирусов и антивирусов.

На синем экране смерти содержится информация о причинах, вызвавших исключение (в виде кода STOP-ошибки вида 0x0000007b), адреса в памяти, при обращении к которым произошло исключение и прочая полезная информация. Такая информация называется STOP-ошибкой, переменными параметрами которой как раз являются адреса памяти. Иногда там же содержится имя файла, вызвавшего исключение.

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

Что такое дамп

• dump (англ.) – мусорная куча; свалка; дыра; трущоба.
• dump (memory dump) – 1) дамп, вывод содержимого оперативной памяти на печать или экран; 2) «снимок» оперативной памяти; данные, получаемые в результате дампинга; 3) аварийное снятие, выключение, сброс.
• dumping – дампинг, снятие дампа.

Настройки для сохранения дампа памяти хранятся в системном реестре Windows.

Информация о дампе памяти в системном Реестре:

В разделе Реестра Windows аварийный дамп памяти определяется следующими параметрами:

– REG_DWORD-параметр AutoReboot со значением 0×1 (опция Выполнить автоматическую перезагрузку вспомогательного окна Загрузка и восстановление диалогового окна Свойства системы);

– REG_DWORD-параметр CrashDumpEnabled со значением 0×0, если дамп памяти не создается; 0×1 – Полный дамп памяти; 0×2 – Дамп памяти ядра; 0×3 – Малый дамп памяти (64КБ);

– REG_EXPAND_SZ-параметр DumpFile со значением по умолчанию %SystemRoot%\MEMORY.DMP (место хранения файла дампа);

– REG_DWORD-параметр LogEvent со значением по умолчанию 0×1 (опция Записать событие в системный журнал окна Загрузка и восстановление);

– REG_EXPAND_SZ-параметр MinidumpDir со значением по умолчанию %SystemRoot%\Minidump (опция Папка малого дампа окна Загрузка и восстановление);

– REG_DWORD-параметр Overwrite со значением по умолчанию 0×1 (опция Заменять существующий файл дампа окна Загрузка и восстановление);

– REG_DWORD-параметр SendAlert со значением по умолчанию 0×1 (опция Отправить административное оповещение окна Загрузка и восстановление).

Как система создает файл аварийного дампа памяти

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

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

Сначала ядро системы проверяет состояние каждого компонента, задействованного в процессе сохранения дампа. Это делается для того, чтобы при прямой записи в секторы диска не повредить данные, лежащие вне страничного файла. Размер страничного файла должен быть на 1МБ больше размера физической памяти, потому что при записи информации в дамп создается заголовок, в котором содержатся сигнатура аварийного дампа и значения нескольких важнейших переменных ядра системы. Заголовок занимает меньше 1МБ, но операционная система может увеличивать (или уменьшать) размер файла подкачки не менее чем на 1МБ.

После загрузки системы Session Manager (Диспетчер сеанса Windows NT; дисковый адрес – \WINDOWS\system32\smss.exe) инициализирует страничные файлы системы, используя для создания каждого файла собственную функцию NtCreatePagingFile. NtCreatePagingFile определяет, существует ли инициализируемый страничный файл, и если да, то имеется ли в нем заголовок дампа. Если заголовок есть, то NtCreatePagingFile посылает в Session Manager специальный код. После этого Session Manager запускает процесс Winlogon (Программа входа в систему Windows NT; дисковый адрес – \WINDOWS\system32\winlogon.exe), который извещается о существовании аварийного дампа. Winlogon запускает программу SaveDump (Программа сохранения копии памяти Windows NT; дисковый адрес – \WINDOWS\system32\savedump.exe), которая анализирует заголовок дампа и определяет дальнейшие действия в аварийной ситуации.

Если заголовок указывает на существование дампа, то SaveDump копирует данные из страничного файла в файл аварийного дампа, имя которого задано REG_EXPAND_SZ-параметром DumpFile раздела Реестра . Пока SaveDump переписывает файл дампа, операционная система не задействует ту часть страничного файла, в которой содержится аварийный дамп. В это время объем виртуальной памяти, доступной для системы и приложений, уменьшается на размер дампа (при этом на экране могут появиться сообщения, указывающие на нехватку виртуальной памяти). Затем SaveDump информирует диспетчер памяти о завершении сохранения дампа, и тот высвобождает ту часть страничного файла, в которой хранится дамп, для общего пользования.

Сохранив файл дампа, программа SaveDump делает запись о создании аварийного дампа в журнале событий Система, например: «Компьютер был перезагружен после критической ошибки: 0x100000d1 (0xc84d90a6, 0×00000010, 0×00000000, 0xc84d90a6). Копия памяти сохранена: C:\WINDOWS\Minidump\Mini060309-01.dmp».

Если включена опция Отправить административное оповещение, то SaveDump отправляет оповещение администратору.

Разновидности дампов

• Полный дамп памяти записывает всё содержимое системной памяти при возникновении неустранимой ошибки. Для этого варианта необходимо иметь на загрузочном томе файл подкачки, размер которого равен объему всей физической оперативной памяти плюс 1МБ. По умолчанию полный дамп памяти записывается в файл %SystemRoot%\Memory.dmp. При возникновении новой ошибки и создании нового файла полного дампа памяти (или дампа памяти ядра) предыдущий файл заменяется (перезаписывается). Параметр Полный дамп памяти недоступен на ПК, на которых установлена 32-битная операционная система и 2 или более гигабайта оперативной памяти.

При возникновении новой ошибки и создании нового файла полного дампа памяти предыдущий файл заменяется.

• Дамп памяти ядра записывает только память ядра, благодаря чему процесс записи данных в журнал при внезапной остановке системы протекает быстрее. В зависимости от объема физической памяти ПК в этом случае для файла подкачки требуется от 50 до 800МБ или одна треть физической памяти компьютера на загрузочном томе. По умолчанию дамп памяти ядра записывается в файл %SystemRoot%\Memory.dmp.

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

• Малый дамп памяти записывает наименьший объем полезной информации, необходимых для определения причины неполадок. Для создания малого дампа памяти необходимо, чтобы размер файла подкачки составлял как минимум 2МБ на загрузочном томе.

Файлы малого дампа памяти содержат следующие сведения:

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

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

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

Операционная система Windows XP, несомненно, значительно надежнее предыдущих версий, – благодаря усилиям как разработчиков Microsoft, так и разработчиков драйверов аппаратного обеспечения, так и разработчиков прикладного программного обеспечения. Однако аварийные ситуации – всевозможные сбои и крахи системы – неизбежны, и от того, владеет ли пользователь ПК знаниями и навыками в их устранении, зависит, придется ему затратить несколько минут на поиск и устранение неисправности (например, на обновление/отладку драйвера или переустановку прикладной программы, вызывающей системный сбой), – или несколько часов на переустановку/настройку операционной системы и прикладного программного обеспечения (что не гарантирует отсутствия сбоев и крахов в дальнейшем!).

Многие системные администраторы всё еще пренебрегают анализом аварийных дампов Windows, считая, что работать с ними слишком трудно. Трудно, но можно: даже если, например, анализ одного дампа из десяти окажется успешным, – усилия, потраченные на освоение простейших приемов анализа аварийных дампов, будут не напрасны!..

Приведу примеры из своей «сисадминской» практики.

В локальной сети без видимой причины («железо» в порядке, отсутствие вирусов гарантировано, пользователи – с «нормальными руками») «полегли» несколько рабочих станций с Windows XP SP1/SP2 «на борту». Компьютеры загрузить в нормальном режиме не удавалось, – доходило до «Приветствия» – и на перезагрузку до бесконечности. При этом, в Безопасном режиме ПК загружались.

Изучение дампов памяти позволило выявить причину неисправности: виновником оказался антивирус Касперского , точнее, свежие антивирусные базы (если еще точнее, то два модуля баз – base372c.avc, base032c.avc).

…Еще был такой случай. На локальном ПК с Windows XP SP3 при попытке открыть видеофайлы форматов.avi и.mpeg происходила перезагрузка. Изучение дампа памяти позволило выявить причину неисправности – файл nv4_disp.dll драйвера видеокарты NVIDIA GeForce 6600. После обновления драйвера неисправность была устранена. Вообще, драйвер nv4_disp.dll — один из самых нестабильных драйверов, который часто приводил к BSOD.

В обоих указанных случаях изучение аварийного дампа памяти позволило до минимума (несколько минут!) свести время для диагностирования и устранения неисправности.

Анализ дампа памяти

Для анализа аварийных дампов памяти существует множество программ, например, DumpChk, Kanalyze, WinDbg.

Рассмотрим анализ аварийных дампов памяти с помощью программы WinDbg (входит в состав Debugging Tools for Windows).

Установка средств отладки

• посетите веб-узел http://www.microsoft.com/whdc/devtools/debugging/default.mspx корпорации Microsoft;
• загрузите Debugging Tools for Windows, например, для 32-битной версии Windows это можно сделать на странице Download the Debugging Tools for Windows ;
• после скачивания запустите установочный файл;
• в окне Debugging Tools for Windows Setup Wizard нажмите Next;
• в окне с лицензионным соглашением установите переключатель I agree –> Next;
• в следующем окне выберите тип установки (по умолчанию средства отладки устанавливаются в папку \Program Files\Debugging Tools for Windows) –> Next –> Install –> Finish;
• для интерпретации файлов дампа памяти необходимо также загрузить пакет символов (Symbol Packages, так называемые символьные файлы, или файлы символов отладки) для своей версии Windows, – зайдите на страницу Download Windows Symbol Packages ;
• выберите свою версию Windows, скачайте и запустите установочный файл Symbol Packages;
• в окне с лицензионным соглашением нажмите Yes;
• в следующем окне выберите папку для установки (по умолчанию предлагается \WINDOWS\Symbols) –> OK –> Да;
• в окне Microsoft Windows Symbols с сообщением «Installation is complete» нажмите OK.

Использование программы WinDbg для анализа аварийных дампов памяти

• запустите WinDbg (по умолчанию устанавливается в папку \Program Files\Debugging Tools for Windows);
• выберите меню File –> Symbol File Path…;
• в окне Symbol Search Path нажмите кнопку Browse…;
• в окне Обзор папок укажите расположение папки Symbols (по умолчанию – \WINDOWS\Symbols) –> OK –> OK;
• выберите меню File –> Open Crash Dump… (или нажмите Ctrl + D);
• в окне Open Crash Dump укажите расположение Crash Dump File (*.dmp) –> Открыть;
• в окне Workspace с вопросом «Save information for workspace?», установите флажок Don"t ask again –> No;
• в окне WinDbg откроется окно Command Dump <путь_и_имя_файла_дампа> с анализом дампа;
• просмотрите анализ дампа памяти;
• в разделе «Bugcheck Analysis» будет указана возможная причина краха, например, «Probably caused by: smwdm.sys (smwdm+454d5)»;
• для просмотра детальной информации нажмите ссылку «!analyze -v» в строке «Use !analyze -v to get detailed debugging information»;
• закройте WinDbg;
• используйте полученную информацию для устранения причины неисправности.

Например, на следующем скриншоте причина неисправности – файл nv4_disp.dll драйвера видеокарты.

Данная небольшая заметка ставит целью своей показать, каким же образом можно сконфигурировать систему, чтобы получить в своё распоряжение аварийный дамп памяти 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. Заменять существующий файл дампа.

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

Малый дамп памяти (Small memory dump)

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

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

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

Дамп памяти ядра (Kernel memory dump)

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

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

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

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

Полный дамп памяти (Complete memory dump)

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

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

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

Автоматический дамп памяти (Automatic memory dump)

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

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

Параметры реестра

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

Параметры:

Параметр	Тип	Описание
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 прерывает работу и показывает синий экран смерти (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

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

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

– REG_DWORD -параметр AutoReboot со значением 0x1 (опция Выполнить автоматическую перезагрузку вспомогательного окна окна Свойства системы );

– REG_DWORD -параметр CrashDumpEnabled со значением 0x0 , если дамп памяти не создаётся; 0x1 – Полный дамп памяти ; 0x2 – Дамп памяти ядра ; 0x3 – Малый дамп памяти (64КБ) ;

– REG_EXPAND_SZ -параметр DumpFile со значением %SystemRoot%\MEMORY.DMP (место хранения файла дампа);

– REG_DWORD -параметр LogEvent со значением 0x1 (опция Записать событие в журнал окна );

– REG_EXPAND_SZ -параметр MinidumpDir со значением %SystemRoot%\Minidump (опция );

– REG_DWORD -параметр Overwrite со значением 0x1 (опция Заменять существующий файл окна );

– REG_DWORD -параметр SendAlert со значением 0x1 (опция Отправить административное оповещение окна ).

Как система создаёт файл аварийного памяти

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

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

Сначала ядро системы проверяет состояние каждого компонента, задействованного в процессе сохранения дампа. Это делается для того, чтобы при прямой записи в секторы диска не повредить данные, лежащие вне файла. Размер файла должен быть на 1МБ больше размера физической памяти, потому что при записи информации в создаётся заголовок, в котором содержатся сигнатура аварийного и значения нескольких важнейших переменных ядра системы. Заголовок занимает меньше 1МБ , но операционная система может увеличивать (или уменьшать) размер файла подкачки не менее чем на 1МБ .

После загрузки системы Session Manager (Диспетчер сеанса Windows NT ; дисковый адрес – \WINDOWS\system32\smss.exe ) инициализирует файлы системы, используя для создания каждого файла собственную функцию NtCreatePagingFile . NtCreatePagingFile определяет, существует ли инициализируемый файл, и если да, то имеется ли в нём заголовок . Если заголовок есть, то NtCreatePagingFile посылает в Session Manager специальный код. После этого Session Manager запускает процесс Winlogon (Программа входа в систему Windows NT ; дисковый адрес – \WINDOWS\system32\winlogon.exe ), который извещается о существовании аварийного . Winlogon запускает программу SaveDump (Программа сохранения копии памяти Windows NT ; дисковый адрес – \WINDOWS\system32\savedump.exe ), которая анализирует заголовок и определяет дальнейшие действия в аварийной ситуации.

Если заголовок указывает на существование , то SaveDump копирует данные из файла в файл аварийного , имя которого задано REG_EXPAND_SZ -параметром DumpFile раздела . Пока SaveDump переписывает файл , операционная система не задействует ту часть страничного файла, в которой содержится аварийный . В это время объём виртуальной памяти, доступной для системы и приложений, уменьшается на размер (при этом на экране могут появиться сообщения, указывающие на нехватку виртуальной памяти). Затем SaveDump информирует диспетчер памяти о завершении сохранения , и тот высвобождает ту часть файла, в которой хранится , для общего пользования.

Сохранив файл , программа SaveDump делает запись о создании аварийного в журнале событий , например: «Компьютер был перезагружен после критической ошибки: 0x100000d1 (0xc84d90a6, 0x00000010, 0x00000000, 0xc84d90a6). Копия памяти сохранена: C:\WINDOWS\Minidump\Mini060309-01.dmp» .

Полный дамп памяти записывает всё содержимое памяти при возникновении неустранимой ошибки. Для этого варианта необходимо иметь на загрузочном томе файл подкачки, размер которого равен объёму всей физической оперативной памяти плюс 1МБ . По умолчанию полный памяти записывается в файл %SystemRoot%\Memory.dmp . При возникновении новой ошибки и создании нового файла полного памяти (или памяти ядра) предыдущий файл заменяется (перезаписывается). Параметр Полный дамп памяти недоступен на , на которых установлена 32-битная операционная система и 2 или более оперативной памяти.

При возникновении новой ошибки и создании нового файла полного памяти предыдущий файл заменяется.

Дамп памяти ядра записывает только память ядра, благодаря чему процесс записи данных в журнал при внезапной остановке системы протекает быстрее. В зависимости от объёма физической памяти в этом случае для файла подкачки требуется от 50 до 800МБ или одна треть физической памяти на загрузочном томе. памяти ядра записывается в файл %SystemRoot%\Memory.dmp .

Этот не включает нераспределённую память или память, выделенную для программ режима. Он включает только память, выделенную для ядра и аппаратно-зависимого уровня (HAL ) в Windows 2000 и более поздних версиях системы, а также память, выделенную для режима ядра и других программ режима ядра. В большинстве случаев такой является наиболее предпочтительным вариантом. Он занимает намного меньше места по сравнению с полным памяти, при этом исключая только те сектора памяти, которые, скорее всего, не связаны с ошибкой.

При возникновении новой ошибки и создании нового файла памяти ядра предыдущий файл заменяется.

Малый дамп памяти записывает наименьший объём полезной информации, необходимой для определения причины неполадок. Для создания малого памяти необходимо, чтобы размер файла подкачки составлял как минимум 2МБ на загрузочном томе.

Файлы малого памяти содержат следующие сведения:

– сообщение о неустранимой ошибке, её параметры и прочие данные;

– список загруженных ;

– контекст (PRCB ), на котором произошел сбой;

EPROCESS ) для процесса, вызвавшего ошибку;

– сведения о процессе и контекст ядра (ETHREAD ) для потока, вызвавшего ошибку;

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

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

При возникновении следующей ошибки и создании второго файла малого памяти предыдущий файл сохраняется. Каждому дополнительному файлу даётся уникальное имя. Дата закодирована в имени файла. Например, Mini051509-01.dmp - это первый файл памяти, созданный 15 мая 2009 г. Список всех файлов малого памяти хранится в папке %SystemRoot%\Minidump .

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

Многие администраторы пренебрегают анализом аварийных дампов Windows , считая, что работать с ними слишком трудно. Трудно, но можно: даже если, например, анализ одного из десяти окажется успешным, – усилия, потраченные на освоение простейших приёмов анализа аварийных , будут не напрасны!..