Чтение дампа памяти. Как расшифровать BSOD с помощью дампа памяти. Варианты устранения синего экрана

Вероятно, вы знакомы с известной STOP-ошибкой Windows, чаще упоминаемой как «синий экран смерти» (Blue Screen of Death, BSOD). Думаю, Вам будет интересно узнать, что существуют разные типы таких экранов в черном, красном, зеленом, белом, фиолетовом, желтом, сером и коричневом цветах. Подробнее об этом чуть позже, а сначала давайте разберемся с наиболее частой ошибкой системы — BSOD.

Что такое синий экран смерти (Blue Screen of Death)

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

Давайте разберем поподробнее что же такое BSOD:

Если вы вдруг захотите спросить гугл о том, кто создал данный экран, вам будет представлено имя экс-президента Microsoft Стива Баллмера. Однако это не совсем верно из-за неправильной интерпретации письма Чена Реймонда под названием “Кто написал текст для Ctrl + Alt + Delete в Windows 3.1?”, которое было опубликовано такими крупными журналами как The Verge, Engadget, Business Insider, DailyTech в сентябре 2014 года.

В письме шла речь о фундаментальном программном обеспечении — диспетчере задач, впервые появившемся в Windows 3.1, и интерфейсе, аналогичном синему экрану смерти. Возможно это и послужило причиной неверной интерпретации. И хотя Реймонд осознавал, что была совершена ошибка, он критиковал BGR.com за то, что те “полностью сфабриковали сценарий и выдали его за реальность” в публикации от 9 сентября 2014 года в которой писалось о появлении синих экранов смерти с момента запуска Windows NT 3.1 и во всех последующих версиях. Считали, что все дальнейшее развитие приводило к еще более частым сбоям, нестабильности операционной системы. Особенно подверглась критике серия Windows 9x, которой довелось испытать наибольшее количество BSOD из-за несовместимых DLL-файлов и ошибок ядра.

Что вызывает синий экран смерти?

Официальное имя BSOD — STOP-ошибка, вызванная тем, что программное обеспечение на уровне ядра сталкивается с некоторыми неполадками и пользователям не остается ничего кроме как перезагрузить систему. BSOD в большинстве случаев является результатом ошибок, связанных с оборудованием в вашем устройстве.

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

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

Способы решения вопроса синего экрана смерти.

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

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

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

Воспользуйтесь восстановлением системы. Откат состояния Windows до предыдущих состояний может оказаться полезным, поскольку способен устранить причину синего экрана смерти. Если у вас Windows 8.1, вы можете найти эту утилиту пройдя по пути Панель управления > Все элементы панели управления (Маленькие/Крупные значки) > Восстановление .

Альтернативный вариант: Панель управления > Поиск и исправление программ в графе Система и безопасность > Восстановление .

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

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

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

Оставим эти героические саги, просто держите в памяти несколько вещей:

• 1.Стабильно обновляйте свой ПК.
• 2.Регулярно проверяйте систему на наличие вредоносного ПО.
• 3.Дважды задумывайтесь перед установкой неизвестного ПО.
• 4.Никогда не выключайте компьютер непосредственно из источника питания, так как это может повредить файлы Windows.

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

Виды экранов смерти

Синий экран смерти (Blue Screen of Death, BSOD)

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

Черный экран смерти (Black Screen of Death, BkSOD)

Черный экран смерти уже далеко не новая ошибка, которую мы можем встретить в Windows. Он существует с тех пор как люди начали играть в игры на Windows 3.x и возникал, когда происходила критическая системная ошибка. Эд Браун, сотрудник ИТ-подразделения Coca-Cola, первым в 1991 году дал этой ошибке имя Black Screen of Death.

Более новые операционные системы Windows, такие как Windows 7, 8, 10 тоже отображают черный экран смерти, когда происходит сбой в загрузке MBR в момент запуска системы. Это происходит, когда отсутствует какой-то важный DLL-файл или в случае если вы сжали свой диск и операционная система не может быстро распаковать его. При поврежденной загрузочной области диска (записи MBR), восстановить информацию с жесткого диска вам поможет инструмент Starus Partition Recovery .

Красный экран смерти (Red Screen of Death, RSOD)

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

Также существуют другие экраны смерти, в других цветах, но уже в других ОС.

Все Windows-системы при обнаружении фатальной ошибки делают аварийный дамп (снимок) содержимого оперативной памяти и сохраняет его на жесткий диск. Существуют три типа дампа памяти:

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

Дамп памяти ядра – сохраняет информацию оперативной памяти, касающуюся только режима ядра. Информация пользовательского режима не сохраняется, так как не несет в себе информации о причине краха системы. Объем файла дампа зависит от размера оперативной памяти и варьируется от 50 Мб (для систем с 128 Мб оперативной памяти) до 800 Мб (для систем с 8 Гб оперативной памяти).

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

Настройка системы

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

Проделав все манипуляции, после каждого BSoD в папке C:\WINDOWS\Minidump будет сохраняться файл с расширение.dmp. Советую ознакомиться с материалом " ". Также можно установить галочку на “Заменить существующий файл дампа ”. В этом случае каждый новый аварийный дамп будет записываться поверх старого. Я не советую включать данную опцию.

Анализ аварийного дампа памяти с помощью программы BlueScreenView

Итак, после появления синего экрана смерти система сохранила новый аварийный дамп памяти. Для анализа дампа рекомендую использовать программу BlueScreenView. Её можно бесплатно скачать . Программа довольно удобная и имеет интуитивный интерфейс. После её установки первое, что необходимо сделать – это указать место хранение дампов памяти в системе. Для этого необходимо зайти в пункт меню “Options ” и выбрать “Advanced Options ”. Выбираем радиокнопку “Load from the following Mini Dump folder ” и указываем папку, в которой хранятся дампы. Если файлы хранятся в папке C:\WINDOWS\Minidump можно нажатием кнопки “Default ”. Нажимаем OK и попадаем в интерфейс программы.

Программа состоит из трех основных блоков:

1. Блок главного меню и панель управления;
2. Блок списка аварийных дампов памяти;
3. В зависимости от выбранных параметров может содержать в себе:

• список всех драйверов находящихся в оперативной памяти до появления синего экрана (по умолчанию);
• список драйверов находящихся в стеке оперативной памяти;
• скриншот BSoD;
• и другие значения, которые мы использовать не будем.

В блоке списка дамп памяти (на рисунке помечен цифрой 2) выбираем интересующий нас дамп и смотрим на список драйверов, которые были загружены в оперативную память (на рисунке помечен цифрой 3). Розовым цветом окрашены драйвера, которые находились в стеке памяти. Они то и являются причиной появления BSoD. Далее переходите в Главное меню драйвера, определяйте к какому устройству или программе они принадлежат. В первую очередь обращайте внимание на не системные файлы, ведь системные файлы в любом случае загружены в оперативной памяти. Легко понять, что на изображении сбойным драйвером является myfault.sys. Скажу, что это программа была специально запущена для вызова Stop ошибки. После определения сбойного драйвера, необходимо его либо обновить, либо удалить из системы.

Для того чтобы программа показывала список драйверов находящихся в стеке памяти во время возникновения BSoD необходимо зайти в пункт меню “Options ” кликаем на меню “Lower Pane Mode ” и выбираем “Only Drivers Found In Stack ” (или нажмите клавишу F7), а для показа скриншота ошибки выбираем “Blue Screen in XP Style ” (F8). Что бы вернуться к списку всех драйверов, необходимо выбрать пункт “All Drivers ” (F6).

Данная публикация продолжает серию статей по обзору инструментов анализа аварийных дампов. В своем арсенале отладки современный специалист имеет еще одно достаточно полезное средство - это скрипт автоматизации отладчика ядра под названием 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="" . . .

Скрипт писался давно, и попросту "не знал" о существовании новых путей установки средств отладки 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 .

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

• Конфликты драйверов - конфликты с драйверами возникают, когда два или несколько драйверов не могут работать друг с другом должным образом. Это также может произойти, если несколько драйверов установлены для одного и того же устройства без удаления предыдущей версии.
• Конфликты оборудования - Некорректный разгон ПК может сразу создать BSOD. Также "синий экран смерти" может возникать, если ваши планки RAM неправильно установлены или если часть оборудования начинает подходить к износу.
• Ошибки операционной системы (ОС) - Пользовательская ошибка или вредоносное ПО, могут удалять жизненно важные файлы вашей ОС. Существенные недостающие файлы могут привести к пагубной ошибке, в результате чего ваш ПК войдет в цикл BSOD, в котором вы получаете синий экран каждый раз, когда ваш компьютер включается.

Подготовка к анализу дампа файла BSOD

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

• Нажмите Win+R и введите sysdm.cpl

Перейдите на вкладку Дополнительно и выберите снизу Параметры в графе "".

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

Теперь скачиваем программу BlueScreenView , пролистайте в центр на сайте для загрузки файла. Вы увидите три ссылки, как на картинке ниже, выберите наиболее удобный для вас установщик. Если хотите русифицировать программу, то ниже в таблице найдите Russian и загрузите файл. В скаченном файле будет файл "BlueScreenView_lng", просто поместите его в установочную программу в корень.

Узнать коды ошибок Синего Экрана Смерти

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

Как исправить коды ошибок Синего Экрана Смерти

Приведу пару способов, что делать и как устранить ошибки популярными способами:

• Когда к примеру в Windows 10 происходит синий экран смерти, то там будет QR код по которому вас перебросит на сайт .
• На сайте Microsoft уже есть база с ошибками BSOD и подсказывающие инструменты.
• Используйте виртуального агента Майкрасофт, введите в первую строку сообщения BSOD и следуйте инструкциям.
• Microsoft также предлагает запустить

Консультируя клиентов, я обратил внимание на то, что зачастую для них единственный способ борьбы с синим экраном смерти (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 (см.