Как открыть файл дампа памяти windows 7. Проводим анализ дампа памяти или как выявить причину BSoD? Как с помощью дампа памяти определить драйвер, вызывающий BSOD

Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство - это скрипт автоматизации отладчика ядра под названием kdfe . Kdfe расшифровывается как Kernel Debugger Front End , то есть интерфейс или надстройка для взаимодействия пользователя с ядерным отладчиком kd.exe (Kernel Debugger) на достаточно простом и понятном уровне. Фактически, kdfe представляет собой скрипт, автоматизирующий определенные действия пользователя и позволяющий в достаточно сжатый промежуток времени получить анализ аварийного дампа памяти системы, либо полностью автоматизировать действия по получению результата анализа и использовать их в более развитых и глобальных автоматизированных системах (правда в этом случае скрипт придется слегка доработать). В стандартном режиме kdfe перенаправляет вывод отладчика ядра kd.exe , что позволяет использовать только необходимые выходные данные отладчика. Понятное дело что kdfe не является панацеей, в его отсутствии нам просто пришлось бы анализировать аварийный дамп памяти системы вручную, непосредственно в консоли при помощи отладчика ядра kd с определенными входными параметрами, что, согласитесь, менее удобно и более времязатратно. Автор скрипта, Александр Суховей (Alexander Suhovey), несомненно создал хороший инструментарий, за что хотелось бы сказать ему отдельное спасибо и за весомый вклад в науку отладки и сэкономленное время.

Подготовка к анализу

Как было уже сказано ранее, скрипт kdfe требует наличия в системе отладчика ядра kd.exe , входящего в состав комплекта Debugging Tools for Windows. Из этого следует, что нам требуется сперва .
На следующем этапе нам необходимо получить в свое распоряжение сам скрипт kdfe. В сети мне удалось найти сайт, носящий название abandoned blog , который оказался домашней страницей автора. Могу предположить, что сайт давно не обновляется, поэтому я решил, на всякий случай, продублировать скрипт и на своем ресурсе.

Исходный код скрипта приводить не вижу особого смысла, во избежание разночтений. После того, как вы скачали скрипт на свою машину, его можно распаковать (как вариант) во временную папку (системная переменная %TEMP%), лично у меня она ссылается, по старой-доброй традиции, на C:\TEMP .

Настройка пути к средствам отладки

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

. . . ::Kernel debugger path. Default is: ::For version 6.8.4.0 - October 18, 2007 and older IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows\kd.exe" (set dbgpath="%PROGRAMFILES%\Debugging Tools for Windows") ELSE (rem For version 6.9.3.113 - April 29, 2008 and newer rem 32 bit IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows (x86)\kd.exe" (set dbgpath="%PROGRAMFILES%\Debugging Tools for Windows (x86)") ELSE (rem 64 bit IF EXIST "%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)\kd.exe" (set dbgpath="%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)") ELSE (IF EXIST "%PROGRAMW6432%\Debugging Tools for Windows (x64)\kd.exe" (set dbgpath="%PROGRAMW6432%\Debugging Tools for Windows (x64)") ELSE (echo ERROR: Debugging Tools for Windows not found^^! pause exit /b 1)))) :: Or set the path to Debugging Tools below:: set dbgpath="" . . .

. . . :: Kernel debugger path . Default is : IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows\kd.exe" ( Set dbgpath = "%PROGRAMFILES%\Debugging Tools for Windows" ) ELSE ( Rem 32 bit IF EXIST "%PROGRAMFILES%\Debugging Tools for Windows (x86)\kd.exe" ( Set dbgpath = "%PROGRAMFILES%\Debugging Tools for Windows (x86)" ) ELSE ( Rem 64 bit IF EXIST "%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)\kd.exe" ( Set dbgpath = "%PROGRAMFILES(x86)%\Debugging Tools for Windows (x86)" ) ELSE ( IF EXIST "%PROGRAMW6432%\Debugging Tools for Windows (x64)\kd.exe" ( Set dbgpath = "%PROGRAMW6432%\Debugging Tools for Windows (x64)" ) ELSE ( Echo ERROR : Debugging Tools for Windows not found ^ ^ ! Pause Exit / b 1 :: Or set the path to Debugging Tools below :: set dbgpath = "" . . .

Скрипт писался давно, и попросту "не знал" о существовании новых путей установки средств отладки Microsoft. С определенной версии путь установки изменился на:

• %PROGRAMFILES(X86)%\Windows Kits\10\Debuggers\x86 ;
• %PROGRAMFILES(X86)%\Windows Kits\10\Debuggers\x64 ;

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

Настройка символов

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

Для анализа дампа памяти отладчику требуются компонентов системы.

У нас есть два варианта решения данной проблемы:

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

Вам необходимы символы для той системы, которая создала дамп памяти, но не для той системы, на который Вы этот дамп анализируете!

Скрипт kdfe написан таким образом, чтобы указывать отладчику kd скачивать с сервера символов Microsoft только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. Задается это в скрипте при помощи переменной smbpath , которая указывает каталог, в который kd.exe будет сохранять необходимые файлы. По-умолчанию это %SYSTEMDRIVE%\symbols , соответственно, в большинстве случаев это C:\symbols . Надо ли вручную создавать эту директорию, либо kd создаст её сам?

Запуск скрипта

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

kdfe

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

kdfe d:\junk\memory.dmp

Непосредственно после запуска скрипт kdfe определяет рабочую директорию средств отладки (Debugging Tools for Windows). Среди возможных вариантов перебираются все возможные пути установки средств отладки. Необходимо это для того, чтобы адресно запускать отладчик ядра kd.exe с указанием полного пути до исполняемого файла.

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

Если скрипт kdfe без параметров командной строки, то он анализирует параметры ветки реестра HKLM\SYSTEM\CurrentControlSet\Control\CrashControl и использует сконфигурированные в параметрах DumpFile и MinidumpDir места расположения дампов в системе. После этого сканирует директории и выводит все обнаруженные файлы дампов в виде меню выбора, предлагая пользователю указать требуемый файл дампа для анализа:

Соответственно, после того, как пользователь выбирает дамп для анализа, скрипт kdfe запускает отладчик kd.exe с определенными параметрами командной строки, дожидается результатов, фильтрует вывод отладчика и перенаправляет его на консоль.

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

Анализ результатов

Теперь пришло время проанализировать вывод, предоставленный нам скриптом kdfe.

Прежде всего, нас интересует главный и самый важный параметр, который выводится после строки probably caused by . В нем обозначается источник проблемы, то есть причина синего экрана смерти . По выводу мы можем понять, что в данном конкретном случае присутствует исключительно аппаратная проблема (ключевое слово hardware). Забегая вперед скажу, что виновником оказался процессор. Да, да, да, сам был чрезвычайно удивлен, потому как столкнулся с подобным впервые, но после долгой диагностики всего железа с последующей заменой частей, последним вариантом оказался именно процессор. Итогом всего этого стала замена процессора, и вот только после этого синие экраны прекратились.
Однако, по статистике, в большинстве случаев виновниками синих экранов являются драйвера устройств сторонних производителей, в подобном случае в строке probably caused by мы можем увидеть нечто вроде igxpdv32.dll . После чего необходимо понять, что именно это за драйвер и скачать+установить более новую (либо более старую) стабильную версию.
Довольно часто рекомендуется обращать внимание так же и на строку Process name , поскольку проблема бывает многосоставная и в этом параметре указывается контекст процесса, то есть (вероятный) виновник более общего, высокого уровня. Например, исполняемый.exe-файл какой-либо программы, библиотека.dll, и зачастую проблема может быть связана с указанной программой, а не с драйвером/компонентом. Дополнительно, имейте эту информацию в виду, и если проблема не устранилась непосредственной работой с источником, указанным в строке probably caused by .

Консультируя клиентов, я обратил внимание на то, что зачастую для них единственный способ борьбы с синим экраном смерти (Blue Screen of Death, BSoD) — это поиск неисправности по номеру STOP-ошибки. Обычно такой подход может помочь выбрать общее направление решения проблемы, но не всегда позволяет ее локализовать. Например, определить какой конкретный драйвер устройства вызывает BSoD. Строго говоря, анализ дампов памяти — это основной метод борьбы с STOP-ошибками.

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

1. Нажмите кнопку Пуск и выберите в меню Настройка пункт Панель управления
2. Дважды щелкните по значку Система
3. Откройте вкладку Дополнительно и нажмите кнопку
4. В области Запись отладочной информации выберите пункт Малый дамп памяти (64 КБ)

В файле малого дампа памяти записывается минимальная информация, позволяющая установить причину сбоя компьютера. Для этого на загрузочном томе требуется файл подкачки размером не менее 2 МБ. По умолчанию файлы малого дампа памяти хранятся в папке %SystemRoot%\Minidump.

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

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

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

Для анализа дампов памяти используются утилиты kd.exe и windbg.exe . Эти утилиты входят в набор Debugging Tools for Windows . Для того чтобы упростить работу с ними, рекомендую использовать скрипт (автор Alexander Suhovey). Вам так же понадобится утилита reg.exe (включена в Microsoft Windows XP и выше; для Windows 2000 входит в состав Windows 2000 Support Tools).

Скачайте и распакуйте архив со скриптом в папку D:\KDFE . Для работы отладчику требуются символьные файлы, которые можно скачать там же, где и Debugging Tools for Windows. Полный размер пакета с этими файлами довольно внушителен (может составить более 1Гб в зависимости от выбранной платформы). Поэтому скрипт настроен таким образом, чтобы автоматически скачивать с Microsoft Symbol Server только необходимые символьные файлы для работы с конкретным дампом памяти и сохранять их локально на диске для последующего использования. При необходимости можно отредактировать скрипт и изменить переменную smbpath , которая указывает на папку, в которую kd.exe будет сохранять необходимые файлы.

Для использования выполните kdfe.cmd с именем файла дампа памяти в качестве параметра. Например:

D:\KDFE>kdfe mini111208-01.dmp

Analyzing "D:\KDFE\Mini111208-01.dmp", please wait... Done.

Crash date: Wed Nov 12 08:35:56.214 2008 (GMT+2)
Stop error code: 0x50
Process name: AUM.exe
Probably caused by: nv4_disp.dll (nv4_disp+41213)

Надо отметить, что бывают ситуации, когда из-за некорректной работы одного из драйверов, STOP-ошибка впоследствии возникает в совершенно нормальном драйвере. В этом случае рекомендую использовать утилиту verifier.exe (см.

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

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

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

Как исправить синий экран ошибка дампа памяти?

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

1. Проверить диспетчер устройств

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

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

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

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

2. Восстановление реестра Windows

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

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

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

Оно автоматически сканирует и исправляет проблемы для любого вопроса, касающегося реестра операционной системы.

3. Проверить модули памяти

Иногда синий экран и какое-то сообщение об ошибке также появляется, которое обычно гласит: “UNEXPECTED_KERNEL_MODE_TRAP”, такая ошибка обычно означает, что ошибка возникает в основном из-за проблемы с памятью.

Для решения вопроса с памятью вашего компьютера, необходимы два основных модуля которые могут быть проверены SIMM и CMOS. SIMM стенды для одиночных модулей встроенной памяти, который обрабатывает совместимость скорости работы операционной системы и КМОП расшифровывается как Комплементарный металло-оксидный полупроводник, которые должны быть установлены правильно согласно конфигурации оперативной памяти.

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

4. Ремонт жесткого диска, который поврежден

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

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

5. Проверка на вирусы

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

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

Это может привести к синему экрану смерти, что, и конечном счете, начинается демпинг физической памяти, и снова и снова перезапуск системы.

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

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

На следующем шаге выбора компонент к установке (Select the features you want to install ) отмечаем только то, что нам нужно - Debugging tools for Windows и нажимаем Install

В указанную на первом экране папку из Интернета будет загружен и установлен набор утилит.

После окончания установки находим в меню “Пуск” или на стартовом экране в группе ярлыков Windows Kits утилиту WinDbg и запускаем её с правами администратора

Если по какой-то причине ярлык найти не удалось, то можно запустить исполняемый файл из каталога установки - С:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe

В главном меню программы WinDbg выбираем пункты File > Symbol File Path . В открывшееся окно вставляем строку определяющую пусть к локальному каталогу символьного кэша и его онлайн-источнику:

SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols

Сохраняем настройки, выбрав в главном меню пункты File > Save Workspace

Открываем файл дампа памяти, выбрав в меню File > Open Crash Dump ...

Выбираем файл MEMORY.DMP (по умолчанию расположен в каталоге C:\Windows ) и нажимаем Open

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

Туже самую информацию можно получить и с помощью командной строки используя примерно следующую последовательность команд:

cd /d "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\ " kd -z "D:\DOWNLOADS\VM05\MEMORY.DMP " .logopen C:\Debuglog.txt .sympath srv*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols

В этом примере вся информация о разборе дампа будет выгружена в читаемом виде в файл C:\Debuglog.txt

Источники информации: