- Синий экран смерти в Windows 10: как расшифровать ошибку и дамп памяти?
- Два способа как расшифровать малый дам памяти minidump
- Обзор параметров файлов сброса памяти для Windows
- Аннотация
- Полная свалка памяти
- Сброс памяти ядра
- Небольшая свалка памяти
- Настройка типа сброса
- Средства для различных типов сброса
- Определения тома
- Значения реестра для запуска и восстановления
- Проверка, чтобы убедиться в том, что файл сброса может быть создан
- Параметры типа демпинга по умолчанию
- Максимальный размер файла для paging
- Техническая поддержка версий Windows на основе x64
- Опять завис ноутбук. Почему папка Minidump после этого пуста?
Синий экран смерти в Windows 10: как расшифровать ошибку и дамп памяти?
Если перед вами появился так называемый синий экран смерти в Windows 10 и вы уже готовы впасть в нервное коматозное состояние, возьмите себя в руки и попробуйте решить возникшую проблему. Для начала стоит сказать, что это зловещее сообщение сигнализирует вам о критической системной ошибке. Более того, далеко не всегда можно словить момент и успеть прочитать код ошибки, когда Windows вывалится в синий экран смерти и произойдет перезагрузка устройства. Сразу отметим, что существует огромное количество решений этой проблемы, как и причин появления синего экрана. В этой статье мы попробуем рассмотреть вероятные причины появления синего экрана счастья, а также о возможных решениях проблемы.
В подавляющем большинстве случаев синий экран смерти сигнализирует про ошибку BAD_POOL_CALLER — stop 0x000000c2. Диагностировать эту ошибку скажем прямо сложно, но возможно и мы попытаемся на примере этой ошибке описать алгоритм ваших следующих действий.
Чтобы правильно осуществить диагностику проблемы, сначала следует проанализировать специальный файл системы под названием minidump (дамп памяти). К созданию таких файлов приводит сбой в работе системы, более того, они могут нас проинформировать – что именно привело к сбою.
1. Чтобы включить такую автоматическую запись малого дампа памяти (по-умолчанию отключено) зайдите в свойства компьютера и перейдите в раздел «Дополнительные параметры системы» (такое включение предусмотрено для все систем, а не только Windows 10):
2. Далее нажимаем «Параметры» в разделе «Загрузка и восстановление» и в открывшемся окне выбираем пункт «Малый дамп памяти (256KB):
Как правило все файлы minidump при появлении синего экрана смерти (BSOD) сохраняются, а найти их можно в папке C:\Windows\Minidump. Примечательно, что в имени файла содержится текущая дата – когда он был создан, что значительно облегчает идентификацию даты возникновения ошибки, особенно учитывая, что такой файл может быть не один.
Два способа как расшифровать малый дам памяти minidump
Первый способ, заключается в использовании довольно популярной утилите BlueScreenView. Эта утилита может также стать хорошим вариантом для анализа дампа памяти. Применение этой утилиты как нельзя кстати пригодится, как способ чтобы определить проблемный драйвер.
Более того, она особенно примечательна тем, что с ее помощью возможен просмотр BSOD (синего экрана смерти) как бы в стоп-кадре, как это было, когда система крашилась. Она отображает время и дату сбоя, данные о драйвере или модуле с версией и кратким описанием. Кроме того, утилита доступна на множестве языков, включая русский. Так что утилита BlueScreenView как раз самое то, если нужно произвести быстрый анализ дампов памяти при BSOD.
Для второго способа нужно установить Debugging Tools for Windows, а также загрузить утилиту bsdos_utility. Далее после распаковки скрипта bsdos_utility.cmd следует переместить его на диск C:\ (можно создать отдельную папку, но стоит помнить, что строка адреса запуска скрипта будет отличатся от нашего примера). Затем в командной строке следует написать:
После выведения списка всех дампов из списка C:\Windows\Minidump\, после чего скрипт спросит какой именно дамп должен подвергнуться анализу. Выбрать нужный минидамп можно также самостоятельно при запуске скрипта:
Подобным образом возможно обнаружение массы ошибок Windows 10, из-за которых выпал BSOD, а также проблематичных программ .exe из-за которых случился синий экран.
Обзор параметров файлов сброса памяти для Windows
В этой статье описываются параметры файлов сброса памяти для Windows.
Оригинальная версия продукта: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 254649
Аннотация
Для записи данных об отладке можно настроить следующие операционные системы:
- Windows 7
- Windows Server 2012 R2
Сведения об отладке могут быть записаны в различные форматы файлов (также известные как файлы сброса памяти), когда компьютер неожиданно останавливается из-за ошибки Stop (также известной как синий экран, сбой системы или проверка ошибки). Вы также можете настроить Windows, чтобы не записывать данные отладки в файл сброса памяти.
Windows может создавать любой из следующих типов файлов сброса памяти:
- Полная свалка памяти
- Сброс памяти ядра
- Небольшая свалка памяти (64 КБ)
- Автоматическая свалка памяти
Полная свалка памяти
Полная свалка памяти записи все содержимое системной памяти, когда компьютер неожиданно останавливается. Полная свалка памяти может содержать данные из процессов, запущенных при сборе свалки памяти.
Если вы выберете параметр «Полная демпинговая память», необходимо иметь файл paging на томе загрузки, достаточный для удержания всей физической оперативной памяти плюс 1 мегабайт (МБ).
Если следующие условия верны, предыдущий файл перезаписан.
- Возникает вторая проблема.
- Создается еще один полный файл сброса памяти (или свалка памяти ядра).
- В Windows 7 файл paging может быть на разделе, который отличается от раздела, на котором установлена операционная система.
- В Windows 7 не нужно использовать запись реестра DedicatedDumpFile для того, чтобы поместить файл paging в другой раздел.
- На компьютерах с 32-битной операционной системой и с 2 гигабайтами (ГБ) или более оперативной памяти недоступна опция «Полная демпинговая память». Дополнительные сведения см. в дополнительных сведениях: Укажите, что происходит при неожиданной остановке системы.
Сброс памяти ядра
Сброс памяти ядра записи только памяти ядра. Это ускоряет процесс записи сведений в журнале, когда компьютер неожиданно останавливается. У вас должен быть достаточно большой pagefile, чтобы вместить память ядра. Для 32-битных систем память ядра обычно составляет от 150 до 2 ГБ.
Этот файл сброса не содержит неуловимую память или память, выделенную для программ в режиме пользователя. Он включает следующее:
- Память, выделенная на слой абстракции ядра и оборудования (HAL) в Windows 2000 и более поздней версии.
- Память, выделенная драйверам в режиме ядра и другим программам в режиме ядра.
Для большинства целей этот файл сброса является наиболее полезным. Это меньше, чем полный файл сброса памяти. Но он не передает только те части памяти, которые вряд ли были вовлечены в проблему.
Если следующие условия верны, предыдущий файл перезаписывается при проверке перезаписи любого существующего параметра файла.
- Возникает вторая проблема.
- Создается еще один файл сброса памяти ядра (или полный файл сброса памяти).
Небольшая свалка памяти
Небольшая свалка памяти записи наименьший набор полезных сведений, которые могут помочь определить, почему компьютер неожиданно остановился. Этот параметр требует файла paging по крайней мере 2 МБ на том загрузки и указывает, что Windows 2000 и более поздней версии создать новый файл каждый раз, когда компьютер неожиданно останавливается. История этих файлов хранится в папке.
Этот тип файла сброса включает следующие сведения:
- Сообщение Stop, его параметры и другие данные
- Список загруженных драйверов
- Контекст процессора (PRCB) для остановленного процессора
- Сведения о процессе и контекст ядра (EPROCESS) для остановленного процесса
- Сведения о процессе и контекст ядра (ETHREAD) для остановленного потока
- Стек вызовов в режиме ядра для остановленного потока
Этот вид файла сброса может быть полезен при ограниченном пространстве. Однако из-за ограниченной информации ошибки, которые непосредственно не были вызваны потоком, запущенным во время проблемы, могут не быть обнаружены при анализе этого файла.
Если следующие условия верны, предыдущий файл сохраняется.
- Возникает вторая проблема.
- Создается второй небольшой файл сброса памяти.
Каждому дополнительному файлу дается отдельное имя. Дата закодирована в имени файла. Например, Mini022900-01.dmp — это первая свалка памяти, созданная 29 февраля 2000 г. Список всех небольших файлов сброса памяти хранится в %SystemRoot%\Minidump папке.
Настройка типа сброса
Чтобы настроить параметры запуска и восстановления (включая тип сброса), выполните следующие действия.
Так как существует несколько версий Windows, следующие действия могут быть разными на вашем компьютере. Если они есть, см. документацию по продуктам для выполнения этих действий.
- Нажмите кнопку Пуск и выберите Панель управления.
- Нажмите кнопку Производительность и обслуживание, а затем щелкните System.
- На вкладке Advanced щелкните Параметры под запуском и восстановлением.
Чтобы изменения вступили в силу, необходимо перезапустить Windows.
Средства для различных типов сброса
Вы можете загружать полные сбросы памяти и сбросы памяти ядра стандартными символическими отладчиками, такими как I386kd.exe. I386kd.exe включена в cd-диск поддержки Windows 2000.
Загрузка небольших свалок памяти с помощью Dumpchk.exe. Вы также можете Dumpchk.exe проверку правильности создания файла сброса памяти.
Определения тома
Объем загрузки: том, содержащий операционную систему Windows и ее файлы поддержки. Объем загрузки может быть, но не должен быть таким же, как и объем системы.
Том системы. Объем, содержащий файлы, определенные для оборудования, которые необходимо загрузить Windows. Объем системы может быть, но не должен быть таким же, как и объем загрузки. Файлы Boot.ini и Ntbootdd.sys являются примерами файлов, расположенных Ntdetect.com в томе системы.
Значения реестра для запуска и восстановления
Ниже используется значение реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl .
- CrashDumpEnabled REG_DWORD 0x0 = None
- CrashDumpEnabled REG_DWORD 0x1 = Полная свалка памяти
- CrashDumpEnabled REG_DWORD 0x2 = сброс памяти ядра
- CrashDumpEnabled REG_DWORD 0x3 = Небольшая свалка памяти (64 КБ)
- CrashDumpEnabled REG_DWORD 0x7 = автоматическая свалка памяти
Дополнительные значения реестра для CrashControl:
AutoReboot REG_DWORD 0x1
DumpFile REG_EXPAND_SZ %SystemRoot%\Memory.dmp
LogEvent REG_DWORD 0x1
MinidumpDir REG_EXPAND_SZ %SystemRoot%\Minidump
Переописывание REG_DWORD 0x1
SendAlert REG_DWORD 0x1
Чтобы изменения вступили в силу, необходимо перезапустить Windows.
Проверка, чтобы убедиться в том, что файл сброса может быть создан
Дополнительные сведения о настройке компьютера для создания файла сброса для тестирования см. в материалах, которые позволяют создавать файл сброса памяти с помощью клавиатуры.
Параметры типа демпинга по умолчанию
- Windows 7 (все выпуски): сброс памяти ядра
- Windows Server 2012 R2 (Все выпуски): Автоматическая память.dmp
Максимальный размер файла для paging
Максимальный размер файла для paging ограничен следующим образом:
Ограничение | x86 | x64 | IA-64 |
---|---|---|---|
Максимальный размер файла paging | 4 гигабайта (без PAE) 16 терабайт (PAE) | 16 терабайт | 32 терабайта |
Максимальное количество файлов для paging | 16 | 16 | 16 |
Общий размер файла для paging | 64 гигабайта (без PAE) 256 терабайт (PAE) | 256 терабайт | 512 терабайт |
Техническая поддержка версий Windows на основе x64
Производитель оборудования предоставляет техническую поддержку и помощь для версий Windows на основе x64. Ваш производитель оборудования обеспечивает поддержку, так как x64-версия Windows была включена с вашим оборудованием. Возможно, производитель оборудования настраивал установку Windows с уникальными компонентами. Уникальные компоненты могут включать определенные драйверы устройств или могут включать необязательные параметры для максимальной производительности оборудования. Корпорация Майкрософт предоставит необходимую помощь, если вам потребуется техническая помощь с помощью x64-версии Windows. Однако вам может потребоваться связаться с производителем напрямую. Ваш производитель лучше всего может поддерживать программное обеспечение, установленное производителем на оборудовании.
Опять завис ноутбук. Почему папка Minidump после этого пуста?
Ноутбук ASUS K53SC. Был в интернете, играло видео, неожиданно ноутбук завис, звук,что в тот момент, зациклился до звука трррр. Кнопки ноутбука, функциональные не действуют.
Выключил нажатием кнопки, включил. Пошел в папку Minidump, а там ничего. Почему папка Minidump пуста?
Случались Блю скрин и такое завсиание. После Блю Скрина в папке Minidump было, что взять.
Может от того, что Блю Скрин это програмная часть, а это зависание относится к ноутбуку, к деталям и есть аппаратная часть?
От чего это может быть с ноутбуком?
Ноутбук ASUS K53SC. Был в интернете, играло видео, неожиданно ноутбук завис, звук,что в тот момент, зациклился до звука трррр. Кнопки ноутбука, функциональные не действуют.
Выключил нажатием кнопки, включил. Пошел в папку Minidump, а там ничего. Почему папка Minidump пуста?
Случались Блю скрин и такое завсиание. После Блю Скрина в папке Minidump было, что взять.
Может от того, что Блю Скрин это програмная часть, а это зависание относится к ноутбуку, к деталям и есть аппаратная часть?
От чего это может быть с ноутбуком?
Для того, чтобы создался файл минидампа, система должна отреагировать на ошибку, и должно быть достаточно места для создания минидампов.
В вашем случае, был аппаратный сбой, так как звук тр-р-р, обычно, происходит при плохом контакте.
Ну а про минидампы, полезно прочитать статью Вадима Стеркина, в его блоге:
Причиной критических ошибок Windows, сопровождаемых синими экранами (BSOD), часто является драйвер — вновь установленный или поврежденный. Определив, какой именно драйвер служит причиной ошибки, можно приступать к устранению проблемы: обновить драйвер, откатиться к более ранней версии, переустановить или удалить приложение, установившее драйвер и т. д. Не всегда название драйвера отображается на синем экране. Однако существует очень простой способ, позволяющий с помощью дампа памяти определить проблемный драйвер за пару минут.
Шаг 1 — Включение записи дампов памяти
Сначала нужно убедиться, что запись дампов включена. Для этого нужно открыть свойства системы, нажав комбинацию клавиш Win+Pause, [в Vista щелкнуть ссылку Дополнительные параметры системы], перейти на вкладку Дополнительно, и наконец нажать кнопку Загрузка и восстановление.
Малых дампов памяти должно быть достаточно для наших целей.
Обратите внимание на путь к папке, куда они будут сохраняться при возникновении критической ошибки.
Теперь вы можете запаковать файл в архив, прикрепить его к сообщению в форуме Устранение критических ошибок Windows и подождать, пока вам кто-то сообщит название проблемного драйвера 🙂 Но вы можете сделать это самостоятельно, не прилагая больших усилий.
Шаг 2 — Загрузка и установка диагностических средств
Это не так страшно, как можно подумать 🙂
- Загрузите и установите Debugging Tools for Windows (ссылки на пакеты MSI вы найдете здесь). Они также входят в состав веб-установщика Windows SDK, где после запуска в нужно выбрать Debugging Tools:
- в разделе Common Utilities для установки в 32-разрядной ОС
- в разделе Redistributable Packages для установки в 64-разрядной ОС (будут загружены все три версии — x86, x64, Itanium)
- Загрузите сценарий (kdfe.cmd), который написал Александр Суховей и опубликовал на ресурсе sysadmins.ru (поскольку живую ссылку мне там найти не удалось, предлагаю свою). Распакуйте архив в любую папку.
Примечание. В случае нестандартного расположения папки Program Files вам может потребоваться указать в kdfe.cmd путь к папке, в которую установлены средства Debugging Tools for Windows. Используйте переменную dbgpath в строке 41.
Шаг 3 — Анализ дампа памяти
Теперь все сводится к выполнению одной команды. Откройте командную строку и перейдите в папку, в которую вы распаковали kdfe.cmd. Запустите файл, указав в качестве параметра путь к файлу дампа памяти (в примере ниже файл называется Mini1110307-01.dmp)
Через минуту вы увидите результат.
Драйвер, послуживший причиной ошибки, определен!