myfault sys синий экран как исправить

Главная

Что такое BSOD?

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

BSOD — это защитный механизм ОС Windows, который позволяет предотвратить более серьезные проблемы. Например, если у нас аппаратные проблемы с жестким диском, вряд ли стоит позволять работать такой системе дальше, мы можем потерять важную информацию из-за этого.

Причины возникновения

Основная причина возникновения BSOD (согласно статистике Microsoft) – это ошибки в коде драйверов сторонних разработчиков (70%).

Как уже обсуждалось о режимах работы ОС Windows, только код, который работает в режиме ядра может быть причиной BSOD, за исключением ошибок в важных для системы процессах пользовательского режима: winlogon.exe, crss.exe. Поэтому, такие приложения как:

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

устанавливают свои драйвера, поэтому могут приводить к появлению BSOD.

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

Информация отображаемая во время BSOD

Вот как выглядит экран с BSOD

Давайте рассмотрим каждый из параметров, который присутствует на изображении:

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

Информация на экране, а также сохраненный дамп – это единственные источники данных о причинах BSOD.

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

Настройка параметров ОС Windows, связанных с BSOD

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

В Windows 7 заходим “Пуск / Компьютер” правый клик мыши, выбираем “Свойства”. Выбираем “Дополнительные параметры системы” и выбираем “Параметры” напротив “Загрузка и восстановление”.

Параметр “Файл дампа” задает путь к файлам дампов. %SystemRoot% – означает обычно каталог C:windows. Типы дампов:

Если формируется дамп памяти ядра то предыдущий файл дампа перезаписывается, если установлено “Заменять существующий файл дампа”. Малый дамп памяти записывается по умолчанию в каталог %SystemRoot%Minidump. Малый дамп памяти в имени файла содержит дату и время, поэтому перезаписи не происходит. Конечно же дамп памяти ядра содержит больше полезной информации для анализа, но его размер может достигать значительных размеров, поэтому для того, чтобы быстро помочь пользователю, достаточно файла малого дампа памяти.

В Windows XP параметры практически аналогичны, за исключением типов дампов. Здесь есть следующие типы:

Параметр “Записать событие в системный журнал” полезен в случае если компьютеров много, и есть какое-либо программное обеспечение, которое анализирует события в журналах аудита ОС Windows. Благодаря этому параметру можно включить сохранение специального события. Позже можно будет сформировать статистику по этому событию, например, по нескольким 1000-ам компьютеров, после чего найти проблемные и сделать наряды на работников ИТ.

Способы устранения

Мы подошли к самому интересному моменту. К сожалению, на основании файлов дампов не всегда можно установить причину BSOD, хотя бы в силу того, что сами файлы дампов могут быть повреждены (см. статистику причин появления BSOD). Кроме того, иногда причины могут быть слишком явными, например, поставили новое ПО – получили BSOD, удалили – все нормально. Дампы памяти более полезны, в первую очередь, разработчикам драйверов, которые благодаря им, могут найти ошибки в своем ПО. Часто приходится включать память и смекалку. Я приведу следующий алгоритм, который поможет вам самостоятельно найти причину.

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

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

Анализ аппаратной среды. Вспомните когда возникают синие экраны смерти. Это происходит когда вы играете в свою любимую игрушку, которая загружает ваше железо по полной? Если да, возможно причина в перегреве каких-либо компонент. Проверьте температуру процессора, жесткого диска. Обратите внимание на то, сильно ли запылен корпус вашего компьютера. Также обязательно проверьте память (см. пост — «Как проверить память в Windows 7 встроенной утилитой mdsched?«, а также «Диагностика памяти с помощью Memtestx86+«). Сбойная память также часто приводит к синим экранам смерти. Приводить к BSOD может один из компонентов аппаратной части: жесткий диск, видеокарта и т.д. В этом случае нужно анализировать дампы и делать выводы, является ли причиной сами драйвера. Если это не так то тогда необходимо пробовать менять по очереди видеокарту, память. Смотреть после этого, появляется ли проблема вновь.

Я когда-то купил две планки памяти б/у и не проверил их на работоспособность. Начали постоянно возникать синие экраны смерти. Здесь не трудно было догадаться о причине. Желательно поинтересоваться у продавца, проверял ли он память, например, такой программой как memtest86+. Еще один случай был с совершенно новым ноутбуком, на работе, на который никак не хотела устанавливаться ОС Windows XP (вылетал BSOD). Причина также была в сбойной памяти.

К сожалению, memtest86+ не всегда работает корректно. Я сталкивался с этим на серверах HP. Встроенные в BIOS серверов утилиты проверки памяти показывали, что все нормально, тогда как memtest86+ говорила о сбойной памяти.

Анализ файлов дампов. Выполните анализ сохраненных дампов памяти. Повторяется ли одна и та же ошибка или она разная? Если ошибка одна и та же, скажем, в 5 файлах и это такая ошибка как DRIVER_IRQL_NOT_LESS_OR_EQUAL то это говорит о том, что у вас проблема не с аппаратной частью, а с ошибками в драйвере. Также прочтите статью как выполнять анализ файлов дампов после BSOD — Анализ дампов после BSOD с помощью Debugging Tools for Windows. Если установить проблемный драйвер сложно, обязательно прочтите “Как пользоваться утилитой Driver Verifier”.

Если самому не получилось установить причину BSOD — создайте тему на форуме.

Интересное о BSOD

Марк Руссинович написал не одну полезную программу, которые могут вам пригодится и которые непосредственно связаны с BSOD:

Источник

Анализ дампов после BSOD с помощью Debugging Tools for Windows

Debugging Tools for Windows – это набор утилит от Microsoft, предназначенный для разработчиков и администраторов. Установщик можно бесплатно скачать по ссылке — http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx. Перед этим, вам нужно выбрать версию ОС, в которой вы будете использовать утилиты.

Если вы разработчик драйверов и используете DDK то Debugging Tools for Windows входит туда, и его установку можно выбрать при установке DDK.

После перехода по ссылке, будет загружен веб установщик, который предложит установить Windows SDK (Software Development Kit), в который входит и Debugging Tools.

В ходе установки, вы можете выбрать только Debugging Tools

После того, как установка завершится, вам нужно найти один из файлов установки Debugging Tools. В моей Windows XP SP3 (x86) файлы установки находятся по пути — C:Program FilesMicrosoft SDKsWindowsv7.1RedistDebugging Tools for Windows. Запускаем файл dbg_x86.msi и выполняем установку.

В моей системе набор программ для отладки Debugging Tools по-умолчанию установился в каталог «C:Program FilesDebugging Tools for Windows (x86)»

Теперь нам необходим фал дампа. О том, где его взять вы можете почитать на главной странице – здесь. Если его нет, вы можете его создать с помощью утилиты NotMyFault. Давайте так и поступим, при этом, в качестве ошибки в драйвере, мы выберем DRIVER_IRQL_NOT_LESS_OR_EQUAL. Запускаем программу, выбираем “Hihg IRQL fault (Kernel-mode)” и нажимаем “Crash”. Поскольку в Windows XP, которую я использую, по-умолчанию тип дампа – малый дамп (смотрите здесь — о типах дампов), файл дампа можно найти в каталоге %Systemroot%minidump (c:windowsminidump).

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

Одной из самых простых программ является dumpchk.exe. Давайте запустим ее и перенаправим вывод в файл. Мы получим приблизительно следующий результат (см. вложенный файл ниже)

По результатам анализа можно обратить внимание на следующую важную информацию.

1. Код ошибки (стоп-код) и его параметры, в файле — BugCheck 100000D1, .

2. Строку с названием драйвера, который по мнению утилиты, привел к BSOD — Probably caused by : myfault.sys ( myfault+5ab )

3. Драйвера, которые использовались в системе на момент краха, строки вида:

804d7000 806e4000 nt Sun Apr 13 21:31:06 2008 (4802516A)
806e4000 80704d00 hal Sun Apr 13 21:31:27 2008 (4802517F)
b0b90000 b0ba8b00 bthpan Sun Apr 13 21:51:32 2008 (48025634)
b0ba9000 b0beba80 bthport Sun Apr 13 21:46:29 2008 (48025505)

В простейших случаях, уже этого достаточно для того, чтобы сделать выводы относительно причин BSOD – драйвер myfault.sys как раз и используется утилитой NotMyFault, то есть, мы нашли виновника.

Вы должны были также обратить внимание на наличие в отчете строк вида:

Symbol search path is: *** Invalid ***

Your debugger is not using the correct symbols

Symbols can not be loaded because symbol path is not initialized.

Давайте запустим dumpchk.exe с параметром — “y”, который позволяет указать путь к файлам символов.

Если в каталоге c:symbols будут отсутствовать необходимые символы, они будут загружены с сайта Microsoft. Это может занять некоторое время.

Вложенный файл ниже – это результат работы dumpchk.exe с включенной опцией местонахождения символов.

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

analyze –v

Выбираем “File / Open Crash Dump” открываем наш файла малого дампа.

Мы также увидим сообщение о ошибке — “ERROR: Module load completed but symbols could not be loaded for myfault.sys”. Так и должно быть поскольку для этого драйвера файлы символы не представлены. Теперь в строке ввода команд давайте введем:

Мы получи намного больше информации, чем в случае использования dumpchk.exe (см. вложенный файл)

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: e2ee9008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: badbc5ab, address which referenced memory

FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]

LAST_CONTROL_TRANSFER: from badbc9db to badbc5ab

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4

FOLLOWUP_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]

Давайте рассмотрим полученную информацию.

1. DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) – это символическое описание ошибки

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

Arg1: e2ee9008, memory referenced (адрес памяти по которому происходило обращение)
Arg2: 00000002, IRQL (уровень IRQL на момент обращения)
Arg3: 00000000, value 0 = read operation, 1 = write operation (тип операции, в нашем случае, это операция чтения)
Arg4: badbc5ab, address which referenced memory (адрес в памяти инструкции, которая выполняла операцию чтения)

FAULTING_IP:
myfault+5ab
badbc5ab 8b08 mov ecx,dword ptr [eax]
Здесь показана непосредственно инструкция которая выполнялась – операция записи в регистр ecx содержимого по адресу указанному в eax. Эта инструкция находится по адресу myfault+5ab и относится к драйверу myfault.sys (myfault – это имя драйвера).

Это имя процесса пользовательского режима, который выполнялся во время краха.

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c50 8057f982 898ae708 8936b740 898ae698 nt!IopfCallDriver+0x31
b08f6c64 805807f7 89668958 898ae698 8936b740 nt!IopSynchronousServiceTail+0x70
b08f6d00 80579274 00000094 00000000 00000000 nt!IopXxxControlFile+0x5c5
b08f6d34 8054161c 00000094 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
b08f6d34 7c90e4f4 00000094 00000000 00000000 nt!KiFastCallEntry+0xfc
0006f8e0 00000000 00000000 00000000 00000000 0x7c90e4f4

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

С Ntdll.dll была вызвана функция KiFastCallEntry, которая затем вызвала NtDeviceIoControlFile и т.д., пока при выполнении инструкции по адресу myfault+0x5ab не произошел крах системы.

Анализ данных говорит нам о том, что виновником BSOD был драйвер myfault (myfault.sys)

Если бы мы не использовали символы, у нас была бы следующая информация о стеке

b08f6bfc badbc9db 898ae698 b08f6c40 badbcb26 myfault+0x5ab
b08f6c08 badbcb26 8936b740 00000001 00000000 myfault+0x9db
b08f6c40 804ef18f 89668958 898ae698 806e6410 myfault+0xb26
b08f6c64 805807f7 89668958 898ae698 8936b740 nt+0x1818f
b08f6d00 80579274 00000094 00000000 00000000 nt+0xa97f7
b08f6d34 8054161c 00000094 00000000 00000000 nt+0xa2274
b08f6d64 7c90e4f4 badb0d00 0006f888 b11b2d98 nt+0x6a61c
b08f6d68 badb0d00 0006f888 b11b2d98 b11b2dcc 0x7c90e4f4
b08f6d6c 0006f888 b11b2d98 b11b2dcc 00000000 vmscsi+0xd00
b08f6d70 b11b2d98 b11b2dcc 00000000 00000000 0x6f888
b08f6d74 b11b2dcc 00000000 00000000 00000000 0xb11b2d98
b08f6d78 00000000 00000000 00000000 00000000 0xb11b2dcc

Что менее информативно.

Вообще анализ дампов, кроме самых простых случаев (таких как рассмотренный) требует значительной подготовки и хорошего понимания как работы ОС и драйверов так и владение знанием ассемблера. В открытом доступе можно найти некоторые книги Дмитрия Востокова «Memory Dump Analysis Antology». Если вы их найдете, вы сможете приблизительно оценить уровень автора и приблизительно понять нетривиальность анализа дампов.

Источник

Linux и Windows: помощь админам и пользователям

Администрируем и настраиваем Windows, Linux.

Процесс поиска неисправности BSOD

«Синий» экран (или «синий экран смерти», «синий» экран гибели, или BSOD) известен как «Windows Stop Message”. Данная ошибка появляется на экране, когда ядро Windows или драйвер, работающий в режиме ядра сталкиваются с ошибкой, которая не может быть обработана. Эта ошибка может быть чем-то подобным процессу или драйверу, пытающемуся получить доступ к адресу памяти, в который у него нет доступаразрешения получить доступ, или пытающийся записать в раздел памяти, который отмечен только для чтения.

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

Шаг 1 – Чтение сообщения

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

Хотя это сообщеине выглядит довольно спартанским, здесь все ещё есть немного полезной информации – раздел “Technical Information” включает код остановки (0x0000007B в рисунке 3), и иногда этого может быть достаточно, чтобы начать поиск неисправностей. Однако, независимо от того знаете ли вы как решить данный код остановки, мы перемещаемся в шаг 2: Поиск.

Шаг 2 – Поиск

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

Например, быстрый поиск по MSDN или TechNet покажет, что код остановки, показанный в рисунке 3, 0x0000007B, расшифровывается как INACCESSIBLE_BOOT_DEVICE, что означает, что операционная система была не в состоянии инициализировать устройство хранения данных, с которого она пытается загрузиться во время системной инициализации ввода / вывода. Это вообще указывает на проблему драйвера устройства хранения, и знание того, что проблема вызвана подсистемой хранения, помогает сосредоточиться на поиске неисправностей в определенной области.

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

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

Шаг 3 – Анализ

Полный Дамп Памяти

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

Дамп Памяти ядра

Малый Дамп Памяти

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

После установки WinDbg должен быть [dc]сконфигурирован, чтобы использовать Microsoft Symbol Server[/dc]. Как только символы сконфигурированы, щелкните по меню File, выберите Open Crash Dump, и укажите файл дампа отказа, который Вы хотите проанализировать. Вывод от WinDbg будет похож на это:

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

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

Автор: Ben Lye. Оригинал на английском находится на сайте simple-talk.com

Полезные ссылки:

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

Источник

Myfault sys синий экран как исправить

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

Шаг 1 – Чтение сообщения

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

Шаг 2 – Поиск

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

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

Шаг 3 – Анализ

Полный Дамп Памяти

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

Дамп Памяти ядра

Малый Дамп Памяти

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

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

Источник