Collecting data for crash dump windows 7 что делать


Dumping physical memory to disk 100 на windows 7

Недаром в народе критическую ошибку (BSOD) в виде синего экрана с «какими-то цифрами и буквами» называют «Синий экран смерти».

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

И в данной статье мы рассмотрим одного из представителей категории критических ошибок - «Dumping physical memory to disk», а также обозначим основные причины появления системного сбоя, и предложим наиболее эффективные методы борьбы с ним.

Причины возникновения ошибки "dumping physical memory to disk"

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

Поэтому для начала следует остановиться на решении основных аппаратных проблем.

«Оперативная память»

Довольно часто «Dumping physical memory to disk» возникает после физического вмешательства в компоненты компьютера (чистка пыли, апгрейд, замена термопасты) или после скачков напряжения и перегрева компонентов.

Соответственно, от этого и стоит отталкиваться в решении ошибки:

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

«Видеокарта»

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

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

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

Программные неполадки

Cразу же после столкновения с ошибкой «Dumping physical memory to disk» (как и с любой другой формой «BSOD») следует внимательно проанализировать отчёт по возникшей критической ошибке.

Для этого следует перейти в «С:\windows\minidump» (она же может именоваться «Memory.dmp»).

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

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

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

А также можно попробовать воспользоваться общими рекомендациями, которые будут предоставлены ниже.

Что делать при появлении ошибки "dumping physical memory to disk"

Проверка целостности системных файлов и корректности работы жёсткого диска

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

Утилита «sfc/scannow» предназначена для выявления повреждённых и отсутствующих системных файлов, с их последующим восстановлением.

Для её активации сделайте следующее:

  • Нажмите «Пуск» и в строке поиска введите «cmd.exe».
  • Кликните правой кнопкой мышки по найденному результату и выберите «Запустить от имени администратора».
  • В открывшейся консоли командной строки введите и выполните команду «sfc/scannow».
  • Дождитесь завершения сканирования и просмотрите отчёт утилиты.

Утилита «CHKDSK» предназначена для проверки физических носителей на наличие имеющихся ошибок и их автоматического исправления:

  • Аналогичным образом запустите консоль командной строки.
  • Введите и выполните команду «CHKDSK f/ r/» - параметр «f/» указывает на автоматический поиск и исправление ошибок, параметр «r/» - сканирует жёсткий диск на наличие повреждённых секторов и автоматически их исправляет.
  • Процесс может занять длительное время, поэтому наберитесь терпения и не прерывайте работу утилиты.

Анализ и переустановка графического драйвера

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

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

Если версия драйвера актуальна, то, возможно, причиной возникновения сбоя «dumping physical memory to disk» стала его некорректная установка.

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

  • Нажмите комбинацию клавиш «WIN+R» и выполните «devmgmt.msc».
  • В открывшемся окне «Диспетчер устройств» разверните строку/раздел «Видеоадаптеры».
  • Кликните правой кнопкой мышки по найденному устройству и выберите «Свойства».
  • Перейдите на вкладку «Драйвер» и нажмите на кнопку «Удалить».

Здесь возможно два варианта дальнейших действий:

  1. Перезагрузить компьютер и предоставить операционной системе «карт бланш» на самостоятельную установку драйвера графического адаптера.
  2. Воспользоваться специализированным программным обеспечением (DriverPack или Driver Booster) для самостоятельной полуавтоматической установки необходимых драйверов.

Анализ работы оперативной памяти

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

Делается это достаточно просто:

  • Наиболее популярная и качественная программа для диагностики работы оперативной памяти является «Memtest». Для работы вам потребуется скачать и записать образ программы на загрузочный носитель, с которого и будет осуществляться тестирование.
  • Далее потребуется просто загрузиться с носителя (используя «Boot Menu» или установив соответствующий приоритет загрузки в BIOS) и начать работу с «Memtest».
  • После загрузки с носителя сканирование и тестирование начнётся автоматически.
  • Остаётся набраться терпения, так как сканирование займёт длительное время (это часы тестирования для каждой планки оперативной памяти).

Если по завершению работы «Memtest» внизу активного окна будет предоставлено уведомление «Pass complete, no errors, press Esc to Exit», то программа не обнаружила неисправных блоков.

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

Заключение

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

Crash dump синий экран windows 7

в Советы и хитрости 08.12.2017 0 10,473 Просмотров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BSOD– это ошибка, которая вызывает STOP системы (отсюда и название “ошибка STOP”). Останов системы происходит в связи с тем, существует потенциальная возможность повреждения системы и её файлов. На экране появляется синий экран смерти (Blue Screen of Dead) – это неофициальное название полученное из-за изображения ошибки белым текстом на синем фоне. Синий экран содержит шестнадцатеричные значения из дампа памяти, которые могут быть использованы для определения причины отказа системы.

Когда говорят BSOD, могут подразумевать:

  • Синий экран смерти
  • STOP код
  • Аварийный дамп (crash dump)
  • Дамп памяти (memory dump)


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

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

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

Как узнать причину BSoD

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

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

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

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

Не успеваете прочесть синий экран?

В некоторых случаях конфигурация системы настроена таким образом, что компьютер автоматически перезагрузится после после появления синего экрана, буквально через секунду и вы не успеете ничего прочитать. И этот цикл может быть бесконечным, если проблему не устранила первая перезагрузка. Так что же делать, как увидеть всё что нужно? К счастью всё очень просто.

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

Если вы смогли зайти в безопасный режим, то половина пути уже пройдено 8)

Перейдите на страницу Свойства системы , щелкнув правой кнопкой мыши Мой компьютер и выбрав в Свойства

Если у Вас Windows 7 то слева выберите Дополнительные параметры системы .

В появившемся окошке переходим на вкладку Дополнительно и нажимаем на кнопку Параметры , как на рисунке ниже.

Убираем галочки у опции Выполнить автоматическую перезагрузку .

Теперь при появлении синего экрана он будет оставаться на экране пока вы сами не выполните перезагрузку.

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

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

Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).

Содержание

Анализ аварийного дампа утилитой BlueScreenView

Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.

BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.

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

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

По двойному клику отображается дополнительная информация.

Анализ аварийного дампа отладчиком WinDbg

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

Установка Debugging Tools for Windows (WinDbg)

Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки центра разработки.

Для анализа аварийных дампов установка SDK не требуется. Скачать Debugging Tools for Windows (WinDbg) отдельным пакетом можно здесь или здесь.

Загружаем и устанавливаем WinDbg для вашей версии Windows. Версия для Windows 7 работает также в Windows XP и в Windows Vista.

Для Windows 10 требуется WinDbg версии 10.0.10586.567. Скачиваем Изолированный пакет SDK для Windows 10. Будет загружен веб-установщик. При установке, отключаем все компоненты, кроме отладчика.

После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%Minidump.

Настройка отладочных символов

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

При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.

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

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

Анализ аварийного дампа

В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.

Указываем путь к дампу %SystemRoot%MEMORY.DMP или %SystemRoot%Minidumpфайл.dmp.

Загрузка отладочных символов из интернета может занять некоторое время.

Для получения детальной информации выполняем команду:

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

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

Получение информации о проблемном драйвере

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

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%system32drivers.

Находим указанный файл, и изучаем его свойства.

Обновляем проблемный драйвер.

Аппаратные причины возникновения критических ошибок

Источником критических ошибок нередко бывают неисправности в дисковой подсистеме, или в подсистеме памяти.

Диагностика неисправностей диска

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

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

Проверяем параметры S.M.A.R.T жесткого диска, получить их можно, например, с помощью программы SpeedFan.

Особое внимание обращаем на параметры: "Current Pending Sector Count" и "Uncorrectable Sector Count", ненулевые значения этих параметров сигнализируют о неисправности диска.

Ненулевое значение параметра: "UltraDMA CRC Error Count", сигнализирует о проблеме с SATA-кабелем.

Подробнее о параметрах S.M.A.R.T. читаем в статье Википедии.

Диагностика неисправностей памяти

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

Выявить проблемы с памятью можно с помощью утилиты Memtest86+.

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

Начиная с Windows Vista, в системе имеется свой тест памяти. Для его запуска нажимаем "Пуск", в строке поиска набираем "памяти", выбираем "Средство диагностики памяти Windows".

Проблемы с памятью в некоторых случаях могут быть устранены обновлением BIOS.

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

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

Рекомендуем к прочтению

Анализ аварийных дампов Windows - расшифровка синих экранов (BSOD)

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

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

Аварийный дамп может быть проанализирован с помощью утилиты BlueScreenView или системного отладчика WinDbg (Debugging Tools for Windows).

Содержание

Анализ аварийного дампа утилитой BlueScreenView

Простейшим инструментом для анализа аварийных дампов является утилита BlueScreenView от NirSoft.

Загружаем программу с сайта разработчика.

BlueScreenView сканирует папку с минидампами и отображает информацию по найденным отказам.

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

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

По двойному клику отображается дополнительная информация.

 

 

 

Анализ аварийного дампа отладчиком WinDbg

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

Установка Debugging Tools for Windows (WinDbg)

Microsoft распространяет WinDbg только в составе SDK, загрузить веб-установщик можно на странице загрузки.

Для анализа аварийных дампов установка SDK не требуется. Скачать Debugging Tools for Windows (WinDbg) отдельным пакетом можно здесь.

После установки, корректируем ярлык для запуска WinDbg. В свойствах ярлыка, устанавливаем флажок запуска от имени администратора. Также, в качестве рабочей папки, задаем: %SystemRoot%\Minidump.

Настройка отладочных символов

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

При первом запуске WinDbg, необходимо указать путь к отладочным символам, для этого открываем меню File, Symbol File Path, или используем комбинацию Ctrl+S.

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

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

Анализ аварийного дампа

Запускаем WinDbg.

В меню выбираем File, Open Crash Dump, или нажимаем Ctrl+D.

Указываем путь к дампу %SystemRoot%\MEMORY.DMP или %SystemRoot%\Minidump\файл.dmp.

Загрузка отладочных символов из интернета может занять некоторое время.

Для получения детальной информации выполняем команду:

!analyze -v

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

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

*******************************************************************************
 * *
 * Bugcheck Analysis *
 * *
 *******************************************************************************
 
 Тип ошибки: KMODE_EXCEPTION_NOT_HANDLED (1e)
 Комментарий к ошибке: This is a very common bugcheck. Usually the exception address pinpoints
 the driver/function that caused the problem. Always note this address
 as well as the link date of the driver/image that contains this address.
 Arguments:
 Аргументы ошибки:
 Arg1: 0000000000000000, The exception code that was not handled
 Arg2: 0000000000000000, The address that the exception occurred at
 Arg3: 0000000000000000, Parameter 0 of the exception
 Arg4: 0000000000000000, Parameter 1 of the exception
 
 Debugging Details:
 ------------------
 
 EXCEPTION_CODE: (Win32) 0 (0) - .
 
 FAULTING_IP:
 +3332313336383065
 00000000`00000000 ?? ???
 
 EXCEPTION_PARAMETER1: 0000000000000000
 
 EXCEPTION_PARAMETER2: 0000000000000000
 
 ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0
 
 BUGCHECK_STR: 0x1E_0
 
 CUSTOMER_CRASH_COUNT: 1
 
 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
 
 Процесс, вызвавший ошибку: PROCESS_NAME: VirtualBox.exe
 
 CURRENT_IRQL: 2
 
 EXCEPTION_RECORD: fffff80000ba24d8 -- (.exr 0xfffff80000ba24d8)
 ExceptionAddress: fffff800034d8a70 (nt!DbgBreakPoint)
 ExceptionCode: 80000003 (Break instruction exception)
 ExceptionFlags: 00000000
 NumberParameters: 1
 Parameter[0]: 0000000000000000
 
 TRAP_FRAME: fffff80000ba2580 -- (.trap 0xfffff80000ba2580)
 NOTE: The trap frame does not contain all registers.
 Some register values may be zeroed or incorrect.
 rax=0000000000142940 rbx=0000000000000000 rcx=fffffa80055be690
 rdx=0000000000009018 rsi=0000000000000000 rdi=0000000000000000
 rip=fffff800034d8a71 rsp=fffff80000ba2718 rbp=fffff88006fa0000
 r8=0000000000002274 r9=11d0851b22c6ac61 r10=fffff80003464000
 r11=fffff80000ba27e0 r12=0000000000000000 r13=0000000000000000
 r14=0000000000000000 r15=0000000000000000
 iopl=0 nv up ei pl nz ac po nc
 nt!DbgBreakPoint+0x1:
 fffff800`034d8a71 c3 ret
 Resetting default scope
 
 LAST_CONTROL_TRANSFER: from fffff800034d85fe to fffff800034e0c10
 
 STACK_TEXT:
 Стек вызовов: 
 fffff800`00ba15b8 fffff800`034d85fe : fffffa80`03c05530 00000000`ffffffff fffff800`00ba1d30 fffff800`0350c830 : nt!KeBugCheck
 fffff800`00ba15c0 fffff800`0350c4fd : fffff800`036ea71c fffff800`03627c30 fffff800`03464000 fffff800`00ba24d8 : nt!KiKernelCalloutExceptionHandler+0xe
 fffff800`00ba15f0 fffff800`0350b2d5 : fffff800`0362b028 fffff800`00ba1668 fffff800`00ba24d8 fffff800`03464000 : nt!RtlpExecuteHandlerForException+0xd
 fffff800`00ba1620 fffff800`0351c361 : fffff800`00ba24d8 fffff800`00ba1d30 fffff800`00000000 00000000`00142940 : nt!RtlDispatchException+0x415
 fffff800`00ba1d00 fffff800`034e02c2 : fffff800`00ba24d8 fffffa80`07149010 fffff800`00ba2580 00000000`00000000 : nt!KiDispatchException+0x135
 fffff800`00ba23a0 fffff800`034de0f4 : 00000000`00000016 00000000`00000001 00000000`00000001 00000000`00000000 : nt!KiExceptionDispatch+0xc2
 fffff800`00ba2580 fffff800`034d8a71 : fffff880`05861446 00000000`df029940 fffff880`02f45bec 00000000`deee7000 : nt!KiBreakpointTrap+0xf4
 fffff800`00ba2718 fffff880`05861446 : 00000000`df029940 fffff880`02f45bec 00000000`deee7000 fffff880`01229f06 : nt!DbgBreakPoint+0x1
 fffff800`00ba2720 00000000`df029940 : fffff880`02f45bec 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8 : cmudaxp+0x25446
 fffff800`00ba2728 fffff880`02f45bec : 00000000`deee7000 fffff880`01229f06 fffffa80`05635af8 00000000`00000000 : 0xdf029940
 fffff800`00ba2730 00000000`deee7000 : fffff880`01229f06 fffffa80`05635af8 00000000`00000000 00000000`00000003 : VBoxDrv+0x6bec
 fffff800`00ba2738 fffff880`01229f06 : fffffa80`05635af8 00000000`00000000 00000000`00000003 fffff880`05865913 : 0xdeee7000
 fffff800`00ba2740 00000000`00000000 : 00000000`00000001 00000000`00000006 00000000`00000001 fffff800`00ba2800 : CLASSPNP!ClasspServiceIdleRequest+0x26
 
 STACK_COMMAND: kb
 
 FOLLOWUP_IP:
 cmudaxp+25446
 fffff880`05861446 ?? ???
 
 SYMBOL_STACK_INDEX: 8
 
 SYMBOL_NAME: cmudaxp+25446
 
 FOLLOWUP_NAME: MachineOwner
 
 Драйвер, в котором возникла ошибка: MODULE_NAME: cmudaxp
 
 IMAGE_NAME: cmudaxp.sys
 
 DEBUG_FLR_IMAGE_TIMESTAMP: 47906a45
 
 FAILURE_BUCKET_ID: X64_0x1E_0_cmudaxp+25446
 
 BUCKET_ID: X64_0x1E_0_cmudaxp+25446
 
 Followup: MachineOwner
 ---------

Получение информации о проблемном драйвере

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

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

start end module name
 fffff880`0583c000 fffff880`059ef000 cmudaxp T (no symbols) 
 Loaded symbol image file: cmudaxp.sys
 Image path: \SystemRoot\system32\drivers\cmudaxp.sys
 Image name: cmudaxp.sys
 Timestamp: Fri Jan 18 13:58:45 2008 (47906A45)
 CheckSum: 0013077F
 ImageSize: 001B3000
 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
 

Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%\system32\drivers.

Находим указанный файл, и изучаем его свойства.

Обновляем проблемный драйвер.

Аппаратные причины возникновения критических ошибок

Источником критических ошибок нередко бывают неисправности в дисковой подсистеме, или в подсистеме памяти.

Диагностика неисправностей диска

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

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

Проверяем параметры S.M.A.R.T жесткого диска, получить их можно, например, с помощью программы SpeedFan.

Особое внимание обращаем на параметры: "Current Pending Sector Count" и "Uncorrectable Sector Count", ненулевые значения этих параметров сигнализируют о неисправности диска.

Ненулевое значение параметра: "UltraDMA CRC Error Count", сигнализирует о проблеме с SATA-кабелем.

Подробнее о параметрах S.M.A.R.T. читаем в статье Википедии.

Диагностика неисправностей памяти

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

Выявить проблемы с памятью можно с помощью утилиты Memtest86+.

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

Начиная с Windows Vista, в системе имеется свой тест памяти. Для его запуска нажимаем "Пуск", в строке поиска набираем "памяти", выбираем "Средство диагностики памяти Windows".

Проблемы с памятью в некоторых случаях могут быть устранены обновлением BIOS.

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

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

Подробнее о дампах памяти читаем здесь.

Система вылетает на синий экран смерти с ошибкой (см. в пояснениях) — Спрашивалка

ошибка гласит:

A problem has been detected and windows has been shut down to prevent damage to your computer.

If this is the first time you've seen this stop error screen, restart your computer. If this screen appears again, follow these steps:

Check to be sure you have adequate disk space. If a driver is identified in the stop message, disable the driver or check with the manufacturer for driver updates. Try changing video adapters.

Сheck with your hardware vendor for any BIOS updates. Disable BIOS memory options such as caching or shadowing. If you need to use safe mode to remove or disable components, restart your computer, press F8 to select Advanced startup options, and then select safe mode.

Technical information:

*** STOP: Ox0000007E (OxFFFFFFFFC0000005,0xFFFFF8800482F52E,OxFFFFF8800A1AA5D8,0 xFFFFF8800A1A9E30)

*** bcmw1664.sys - Address FFFFF8800482FS2E base at FFFFF88004804000, Datestamp 5305a9e7

Collecting data for crash dump ...

Initializing disk for crash dump ...

Beginning dump of physical memory.

Dumping physical memory to disk: 50

перевод (через гугл) :

Проблема была обнаружена и окна были закрыты, чтобы предотвратить повреждения компьютера.

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

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

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

Техническая информация:

*** STOP: Ox0000007E (OxFFFFFFFFC0000005,0xFFFFF8800482F52E, OxFFFFF8800A1AA5D8,0 xFFFFF8800A1A9E30)

*** Bcmw1664.sys - Адрес FFFFF8800482FS2E база в FFFFF88004804000, DATESTAMP 5305a9e7

Сбор данных для аварийного дампа ...

При инициализации диска для аварийного дампа ...

Начиная свалка физической памяти.

Демпинг физической памяти на диск: 50

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

что это за процесс и как избавиться от синего экрана при старте Windows?

Появление синего экрана кого угодно может поставить в тупик. Казалось бы, еще вчера система работала нормально, а теперь по неизвестной причине Windows не загружается. Снизу в окне видно, как активируется процесс Dumping physical memory to disk, после чего следует самопроизвольная перезагрузка системы. В чем причина, как бороться с такими явлениями, читайте далее.

Синий экран с активацией процесса Dumping physical memory to disk: в чем причина его появления?

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

Иными словами, в каком-то железном компоненте произошел сбой. И он может носить не обязательно физический характер, хотя такой вариант тоже не исключается. В любом случае пользователь видит ошибку и появление процесса Dumping physical memory to disk: 100, после чего выдается строка Memory dump complete, и следует рестарт.

В данном случае сам процесс представляет собой сброс дампа памяти на диск со 100-секундным отсчетом до рестарта системы. Но почему же так происходит? Большинство специалистов выделяют три возможных причины такого явления:

  • проблемы с видеокартой или ее драйвером;
  • неработоспособные планки оперативной памяти;
  • неполадки в работе жесткого диска.

Dumping physical memory to disk: Windows не загружается. Что делать в первую очередь?

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

Если после принудительного рестарта и отключения компьютера или ноутбука путем длительного нажатия на кнопку питания ничего не происходит, перезагрузку таким способом необходимо выполнить несколько раз. Если и это не поможет, и снова появится уведомление о старте процесса Dumping physical memory to disk, в Windows 7 при начальной загрузке системы можно использовать нажатие клавиши F8, после чего в появившемся меню старта выбрать загрузку последней удачной конфигурации.

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

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

Переустановка драйверов графического адаптера

Однако, как показывает практика, появление процесса Dumping physical memory to disk не всегда может быть связано именно с состоянием операционной системы. Часто виной появления BSoD становится графический адаптер, который при старте ОС активируется в самую первую очередь.

Если причина состоит не физической поломке, опять же, можно загрузиться через стартовое меню с выбором безопасного старта и полностью удалить драйверы видеокарты в «Диспетчере задач», который можно вызвать либо из стандартной «Панели управления», либо из раздела «Администрирование», либо через консоль «Выполнить», прописав в ней команду devmgmt.msc.

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

Но можно поступить еще проще, установив любую программу автоматического апдейта драйверов вроде Driver Booster. Только для этого необходимо загружать систему с тем же безопасным стартом, но уже с поддержкой сетевых драйверов (для обновления потребуется подключение к Интернету).

Если же и это эффекта не даст, и опять возникнет синий экран (Dumping physical memory to disk), возможно, дело в самом адаптере. В качестве одного из решений можно предложить просто переставить видеокарту в другой слот на материнской плате. Если и это не поможет, устройство придется заменить и попробовать произвести загрузку системы заново.

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

Выявление проблем с оперативной памятью

Нередко причиной такого нелицеприятного явления становятся и планки оперативной памяти, особенно если они несовместимы между собой. В случае когда система может загружаться безопасно, выявить проблемы поможет небольшая утилита Memtest86+.

Но в большинстве случаев определить сбойные планки можно самостоятельно, поочередно вынимая их из соответствующих слотов на выключенном компьютере с последующим стартом. В большинстве случаев такая методика дает немедленный результат. При выявлении проблем планки нужно будет заменить (но только так, чтобы все они относились к одному типу, например, DDR3).

Проверка диска

Наконец, причиной активации процесса Dumping physical memory to disk может быть и сам винчестер, на котором могут быть ошибки, или сам он начал «сыпаться».

Проверить диск можно командой chkdsk, дополнив ее атрибутами вроде «/x /f /r» (без кавычек) при безопасном старте, но лучше для верности использовать установочный или восстановительный диск с вызовом командной консоли из меню восстановления (Shift + F10).

А если проблема состоит именно в физическом износе, тут только два пути: либо заменить жесткий диск, либо попытаться его восстановить программой HDD Regenerator, но только при условии, что операционная система хоть как-то загружается.

Несколько слов напоследок

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

Создание ядра или полного аварийного дампа - Windows Client Management

  • 3 минуты на чтение

В этой статье

Сбой системы (также известный как «проверка ошибок» или «стоп-ошибка») происходит, когда Windows не может работать правильно. Файл дампа, созданный в результате этого события, называется аварийным дампом системы.

Ручной файл ядра или полный дамп памяти полезен при устранении нескольких проблем, потому что процесс фиксирует запись о системной памяти во время сбоя.

Настроить файлы подкачки

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

Включить настройку дампа памяти

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

Чтобы включить настройку дампа памяти, выполните следующие действия:

  1. В панели управления выберите Система и безопасность > Система .

  2. Выберите Расширенные настройки системы , а затем выберите вкладку Расширенный .

  3. В области Startup and Recovery выберите Settings .

  4. Убедитесь, что Дамп памяти ядра или Полный дамп памяти выбран в Запись отладочной информации .

  5. Перезагрузите компьютер.

Примечание

Вы можете изменить путь к файлу дампа, отредактировав поле Файл дампа .Другими словами, вы можете изменить путь с% SystemRoot% \ Memory.dmp на локальный диск, на котором достаточно места, например E: \ Memory.dmp.

Советы по созданию дампов памяти

Когда компьютер выходит из строя и перезагружается, содержимое физической ОЗУ записывается в файл подкачки, расположенный в разделе, на котором установлена ​​операционная система.

В зависимости от скорости жесткого диска, на котором установлена ​​Windows, выгрузка более 2 гигабайт (ГБ) памяти может занять много времени.Даже в лучшем случае, если файл дампа настроен для размещения на другом локальном жестком диске, значительный объем данных будет считан и записан на жесткие диски. Это может вызвать длительный сбой сервера.

Примечание

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

Создание файла дампа памяти вручную

Используйте инструмент NotMyFault

Если вы можете войти в систему во время возникновения проблемы, вы можете использовать инструмент Microsoft Sysinternals NotMyFault. Для этого выполните следующие действия:

  1. Загрузите инструмент NotMyFault.

  2. Выберите Start , а затем выберите Command Prompt .

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

      notMyfault.exe / сбой  

Примечание

Эта операция создает файл дампа памяти и ошибку остановки D1.

Используйте NMI

На некоторых компьютерах нельзя использовать клавиатуру для создания файла аварийного дампа. Например, серверы Hewlett-Packard (HP) BladeSystem от Hewlett-Packard Development Company управляются через графический интерфейс пользователя (GUI) на основе браузера. Клавиатура не подключена к серверу HP BladeSystem.

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

Для этого выполните следующие действия:

Важно

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

  1. В редакторе реестра найдите следующий подраздел реестра:

    HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ CrashControl

  2. Щелкните правой кнопкой мыши CrashControl , выберите New , а затем щелкните DWORD Value .

  3. Введите NMICrashDump и нажмите Enter.

  4. Щелкните правой кнопкой мыши NMICrashDump , а затем выберите Изменить .

  5. В поле Value data введите 1 , а затем выберите OK .

  6. Перезагрузите компьютер.

  7. Поставщики оборудования, такие как HP, IBM и Dell, могут предоставлять функцию автоматического восстановления системы (ASR). Вы должны отключить эту функцию во время устранения неполадок.Например, если в BIOS включена функция HP и Compaq ASR, отключите эту функцию во время устранения неполадок для создания полного файла Memory.dmp. Для получения точных инструкций обратитесь к поставщику оборудования.

  8. Включите переключатель NMI в BIOS или с помощью веб-интерфейса Integrated Lights Out (iLO).

    Примечание

    Точные шаги см. В справочном руководстве по BIOS или у поставщика оборудования.

  9. Протестируйте этот метод на сервере, используя переключатель NMI для создания файла дампа.Вы увидите аппаратную неисправность STOP 0x00000080.

Если вы хотите запустить NMI в Microsoft Azure с помощью последовательной консоли, см. Использование последовательной консоли для вызовов SysRq и NMI.

Используйте клавиатуру

Принудительный сбой системы с клавиатуры

Использовать отладчик

Принудительный сбой системы из отладчика

.

Windows 7: Анализ аварийного дампа приложения - статьи TechNet - США (английский)


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

В современном мире .NET инструменты, которые нам предоставляют, намного превосходят все, что мы могли представить 15 лет назад. Хотя доктор Ватсон мог создавать аварийные дампы, большинство разработчиков в то время не знали, что с ними делать после того, как они были созданы. особенно такого старого разработчика Visual Basic 6, как я.

Crash dumps - ценный ресурс для нас, разработчиков, и Windows 7 предоставляет нам несколько отличных функций для создания аварийных дампов через Windows Error Reporting (WER).Это место в реестре, где находится WER, и это будет нашей отправной точкой в ​​этой статье, показано в Рисунок 1 .

Рисунок 1 : Расположение WER в реестре.

Ключ реестра (LocalDumps) по умолчанию не создается для нас в реестре, поэтому вам придется засучить рукава и делать всю грязную работу самостоятельно. Описание значений в разделе реестра LocalDumps показано в Таблица 1 .

Реестровое значение Описание
CustomDumpFlags Будет использоваться только в том случае, если для DumpType установлено значение 0.В таблице 2 показаны все возможные перечисления.
DumpCount Предел количества дампов, хранимых в DumpFolder
DumpFolder Папка, в которой будут храниться дампы
Тип дампа Есть три возможных значения

1.0 - кастомный дамп

2. 1 - Мини-отвал

3. 2 - Полный дамп

Таблица 1 : Описание раздела реестра LocalDumps

Если мини-дамп слишком мал или полный дамп слишком велик, у нас есть возможность создать собственный дамп.Когда для параметра DumpType установлено значение 0, мы указываем WER, что хотим сгенерировать дамп, используя значение в CustomDumpFlags. В таблице 2 показаны все возможные значения CustomDumpFlags

.

Тип минидамп

Значение
MiniDump Нормальный

MiniDumpWithDataSegs

Минидамп с полной памятью

MiniDumpWithHandleData

MiniDumpFilterMemory

MiniDumpScanMemory

MiniDumpWithUnloadedModules

MiniDumpWithIndirectlyReferenced

ПамятьMiniDumpFilterModulePaths

MiniDumpWithProcessThreadData

MiniDumpWithPrivateReadWriteMemory

MiniDump без дополнительных данных

MiniDumpWithFullMemoryInfo

MiniDumpWithThreadInfo

MiniDumpWithCodeSegs

Минидамп без вспомогательного состояния

MiniDumpWithFullAuxiliaryState

MiniDumpWithPrivateWriteCopyMemory

MiniDump - игнорировать недоступную память

MiniDumpWithTokenInformation

0x00000000

0x00000001

0x00000002

0x00000004

0x00000008

0x00000010

0x00000020

0x00000040

0x00000080

0x00000100

0x00000200

0x00000400

0x00000800

0x00001000

0x00002000

0x00004000

0x00008000

0x00010000

0x00020000

0x00040000

Таблица <2 : Перечисления типов минидампа

Каждый раз, когда вы компилируете приложение, используя конфигурацию Debug или Release, вместе с Portable Executable создается файл PDB.Большинство разработчиков выбрасывают эти файлы, даже не задумываясь о том, что они содержат. Фактически, файлы PDB так же важен, как и Portable Executable. Файлы PDB в целом содержат указатель на исходный код и все символы, необходимые для отладки переносимого исполняемого файла. Целью данной статьи не является углубленное изучение файлов PDB. Если бы вы узнайте больше о файлах PDB, а затем просмотрите следующие ссылки.

Теперь, когда у нас есть справочная информация о аварийных дампах и файлах PDB, пора создать приложение, которое выйдет из строя и сгенерирует для нас аварийный дамп.Для этого мы создадим консольное приложение, которое генерирует исключение NullReferenceException. Конечно, кто-то Вы, как и вы, никогда не позволите приложению упасть таким образом, поскольку вы полностью уважаете обработку исключений. Именно так поступил бы один из тех разработчиков, у которых распущенная мораль и вопиющее пренебрежение стандартами разработки.

  1. Откройте Visual Studio 2010
  2. Файл-> Новый проект и выберите Консольное приложение из шаблонов Visual Studio.
  3. Назовите приложение CrashDumpTest и нажмите OK
  4. Переключите конфигурацию с Debug на Release с помощью Configuration Manager

Здесь мы создадим объект общего типа List (Of String).Мы не будем использовать ключевое слово New, и в результате наш список будет содержать пустую ссылку. Затем мы попытаемся добавить элемент в список. Перейдите к методу Main консольного приложения. и добавьте следующий код.

Разм. л как Список (из Строка )

л.добавить ( "струна" )

Хорошо, теперь осталось только построить консольное приложение.После сборки приложения выполните следующие действия:

  1. 1. Перейдите в папку выпуска, которая была местом назначения для вашей сборки
  2. 2. Откройте проводник Windows и создайте на диске C папку с именем Temp
  3. 3. Скопируйте CrashDumpTest.exe и CrashDumpTest.pdb в папку Temp

ПРИМЕЧАНИЕ: Причина, по которой я прошу вас сделать это, заключается в том, чтобы вы могли легко перейти к файлу PDB позже в этой статье.

Пришло время выполнить CrashDumpTest.exe и создайте аварийный дамп. Мой аварийный дамп будет создан в папке C \\ Drives \ Temp, которая является значением параметра реестра DumpFolder, описанного ранее в этой статье. Вы можете указать любую понравившуюся папку. После запуска CrashDumpTest.exe появится диалоговое окно , показанное на рис. 2 .

Рисунок 2 : Диалог отчета об ошибках Windows после сбоя приложения

Вместо того, чтобы отлаживать программу отсюда, мы выберем Close Program.Мы пытаемся смоделировать сценарий, когда пользователь вашего приложения отправил вам файл дампа, и мы откроем файл дампа непосредственно из файловой системы в Visual Studio 2010.

Рисунок 3 показывает файл аварийного дампа в проводнике Windows

.

Рисунок 3 : Файл аварийного дампа, созданный отчетом об ошибках окна

В более ранних версиях Visual Studio у вас была возможность создать проект дампа.Это изменилось в Visual Studio 2010. Чтобы открыть файл дампа в Visual Studio 2010, выполните следующие действия.

  1. Откройте Visual Studio 2010
  2. Файл-> Открыть файл, перейдите в папку дампа и выберите файл дампа CrashDumpTest, показанный на Рисунок 3

После открытия аварийного дампа в Visual Studio 2010 вам будет представлена ​​следующая информация.

Рисунок 4 : Проиллюстрируйте файл дампа Crush, открытый в Visual Studio 2010

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

Используя расширитель Действия справа от Рисунок 4 , щелкните Отладка со смешанным режимом. Это позволит нам проанализировать наш .NET-код.

Первое диалоговое окно, которое появится, показано на рисунке 5

Рисунок 5 : Диалоговое окно Visual Studio, когда мы начинаем отладку аварийного дампа

Выберите «Разрыв» в диалоговом окне, показанном на рис. 5 . Снимок экрана Visual Studio в Рисунок 6 Появится .Не расстраивайтесь от того, что вы видите изначально. Мы еще не указали расположение для нашего файла PDB. Также обратите внимание, что окно стека вызовов показано на Рисунок 6 . Чтобы отобразить окно стека вызовов, выберите в меню Отладка-> Windows-> Стек вызовов

.

Рисунок 6 : Visual Studio показывает, что источник недоступен, когда файл PDB не указан.

Чтобы указать расположение файла PDB, в меню выберите «Отладка» -> «Параметры и настройки».Диалог в Рисунок 7 Появится .

Рисунок 7 : Диалоговое окно настроек и параметров отладки

Выберите элемент дерева символов, который находится под элементом дерева отладки. Вы можете добавить папку в расположение файлов символов (.pdb), нажав желтую кнопку папки в правом верхнем углу экрана, показанного в Рисунок 7 . Помните, что в разделе Создание приложения для сбоя этой статьи я просил вас скопировать ваш PDB-файл в папку C: \ Temp.Ну, вот почему. Добавьте C: \ Temp к месту расположения символа. Как только у вас есть добавил папку нажмите кнопку Загрузить все символы. Это загрузит наши символы в текущий процесс. Щелкните ОК, чтобы закрыть диалоговое окно.

Рисунок 8 теперь показывает результаты нашей предыдущей операции. Собственно то, что показано в Рисунок 8 появляется не сразу. В окне стека вызовов теперь отображается наш CrashDumpTest.exe, которого не было в Рисунок 6 . Чтобы отобразить наш код, вам нужно дважды щелкнуть наш CrashDumpTest.exe в окне стека вызовов.

Рисунок 8 : Дамп сбоя с окном кода и загруженными символами

Это подводит нас к заключению данной статьи. После сегодняшнего дня у вас должны быть навыки настройки отчетов об ошибках Windows для создания файлов дампа, понимание важности файлов PDB, а также знание того, как открывать и анализировать аварийный дамп в Visual Studio 2010.


.

Сбор дампов пользовательского режима - приложения Win32

  • 2 минуты на чтение

В этой статье

Начиная с Windows Server 2008 и Windows Vista с пакетом обновления 1 (SP1), отчет об ошибках Windows (WER) можно настроить таким образом, чтобы полные дампы пользовательского режима собирались и сохранялись локально после сбоя приложения пользовательского режима.Приложения, которые создают собственные настраиваемые отчеты о сбоях, включая приложения .NET, не поддерживаются этой функцией.

По умолчанию эта функция отключена. Для включения этой функции требуются права администратора. Чтобы включить и настроить эту функцию, используйте следующие значения реестра в разделе HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ Windows Error Reporting \ LocalDumps .

Значение Описание Тип Значение по умолчанию
Папка для дампа Путь, по которому должны храниться файлы дампа.Если вы не используете путь по умолчанию, убедитесь, что папка содержит списки управления доступом, которые позволяют процессу сбоя для записи данных в папку. При сбоях службы дамп записывается в папки профиля службы, в зависимости от используемой учетной записи службы. Например, папка профиля для системных служб -% WINDIR% \ System32 \ Config \ SystemProfile. Для сетевых и локальных служб это папка% WINDIR% \ ServiceProfiles.
REG_EXPAND_SZ % LOCALAPPDATA% \ CrashDumps
DumpCount Максимальное количество файлов дампа в папке.При превышении максимального значения самый старый файл дампа в папке будет заменен новым файлом дампа. REG_DWORD 10
Тип дампа Укажите один из следующих типов дампа:
  • 0: Пользовательский дамп
  • 1: Мини-свалка
  • 2: Полный дамп
REG_DWORD 1
CustomDumpFlags Используемые настраиваемые параметры дампа.Это значение используется только в том случае, если для DumpType установлено значение 0.
Параметры представляют собой поразрядную комбинацию значений перечисления MINIDUMP_TYPE .
REG_DWORD MiniDumpWithDataSegs | MiniDumpWithUnloadedModules | MiniDumpWithProcessThreadData.

Эти значения реестра представляют глобальные параметры. Вы также можете указать настройки для каждого приложения, которые переопределяют глобальные настройки. Чтобы создать настройку для каждого приложения, создайте новый ключ для своего приложения в HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ Windows Error Reporting \ LocalDumps (например, HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ Windows Error Reporting \ LocalDumps \ Мое приложение.exe ). Добавьте настройки дампа под ключ MyApplication.exe . Если ваше приложение дает сбой, WER сначала считывает глобальные настройки, а затем заменяет любые настройки настройками вашего приложения.

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

Эти дампы настраиваются и управляются независимо от остальной инфраструктуры WER. Вы можете использовать локальную коллекцию дампа, даже если WER отключен или если пользователь отменяет создание отчетов WER. Локальный дамп может отличаться от дампа, отправленного в Microsoft.

.

Чтение небольших файлов дампа памяти - Windows Client

  • 6 минут на чтение

В этой статье

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

Исходная версия продукта: Windows 10 - все выпуски, Windows Server 2012 R2
Оригинальный номер базы знаний: 315263

Файлы малого дампа памяти

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

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

Чтобы создать файл дампа памяти, Windows требуется файл подкачки на загрузочном томе размером не менее 2 мегабайт (МБ).На компьютерах под управлением Microsoft Windows 2000 или более поздней версии Windows новый файл дампа памяти создается каждый раз, когда может произойти сбой компьютера. История этих файлов хранится в папке. Если возникает вторая проблема и Windows создает второй небольшой файл дампа памяти, Windows сохраняет предыдущий файл. Windows дает каждому файлу отдельное имя с кодировкой даты. Например, Mini022900-01.dmp - это первый файл дампа памяти, созданный 29 февраля 2000 года. Windows хранит список всех файлов малого дампа памяти в папке % SystemRoot% \ Minidump .

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

Настроить тип дампа

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

Примечание

Поскольку существует несколько версий Microsoft Windows, следующие действия могут отличаться на вашем компьютере.Если это так, см. Документацию по продукту, чтобы выполнить эти шаги.

  1. Щелкните Пуск , а затем щелкните Панель управления .

  2. Дважды щелкните Система , а затем щелкните Дополнительные параметры системы .

  3. Щелкните вкладку Advanced , а затем щелкните Settings в разделе Startup and Recovery .

  4. В списке Записать отладочную информацию щелкните Малый дамп памяти (64 КБ) .

Чтобы изменить расположение папки для файлов малого дампа памяти, введите новый путь в поле Файл дампа или в поле Каталог малого дампа , в зависимости от вашей версии Windows).

Используйте служебную программу проверки дампов (Dumpchk.exe), чтобы прочитать файл дампа памяти или убедиться, что файл был создан правильно.

Примечание

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

Для получения дополнительной информации о том, как использовать утилиту проверки дампа в Windows NT, Windows 2000, Windows Server 2003 или Windows Server 2008, см. Статью 156280 базы знаний Майкрософт: Как использовать Dumpchk.exe для проверки файла дампа памяти.

Дополнительные сведения об использовании утилиты проверки дампа в Windows XP, Windows Vista или Windows 7 см. В статье 315271 базы знаний Майкрософт: «Как использовать Dumpchk.exe для проверки файла дампа памяти».

Или вы можете использовать отладчик Windows (WinDbg.exe) или Kernel Debugger (KD.exe) для чтения небольших файлов дампа памяти. WinDbg и KD.exe включены в последнюю версию пакета Debugging Tools for Windows.

Чтобы установить средства отладки, см. Веб-страницу «Загрузка и установка средств отладки для Windows». Выберите Обычную установку. По умолчанию программа установки устанавливает инструменты отладки в следующую папку:

C: \ Program Files \ Инструменты отладки для Windows

Эта веб-страница также предоставляет доступ к загружаемым пакетам символов для Windows.Дополнительные сведения о символах Windows см. В разделах «Отладка с использованием символов» и на веб-странице «Загрузка пакетов символов Windows».

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

Открыть файл дампа

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

  1. Щелкните Start , щелкните Run , введите cmd , а затем щелкните OK .

  2. Перейдите в папку «Инструменты отладки для Windows». Для этого введите в командной строке следующее и нажмите клавишу ВВОД:

      cd c: \ program files \ инструменты отладки для windows  
  3. Чтобы загрузить файл дампа в отладчик, введите одну из следующих команд и нажмите клавишу ВВОД:

      windbg -y SymbolPath -i ImagePath -z DumpFilePath  

    или

      kd -y SymbolPath -i ImagePat -z * DumpFilePath  

В следующей таблице объясняется использование заполнителей, используемых в этих командах.

Заполнитель Пояснение
SymbolPath Либо локальный путь, по которому были загружены файлы символов, либо путь к серверу символов, включая папку кэша. Поскольку небольшой файл дампа памяти содержит ограниченную информацию, фактические двоичные файлы должны быть загружены вместе с символами для правильного чтения файла дампа.
ImagePath Путь к этим файлам.Файлы находятся в папке I386 на компакт-диске Windows XP. Например, путь может быть C: \ Windows \ I386 .
Путь файла дампа Путь и имя файла дампа, который вы исследуете.

Примеры команд

Для открытия файла дампа можно использовать следующие примеры команд. Эти команды предполагают следующее:

  • Содержимое папки I386 на компакт-диске Windows копируется в папку C: \ Windows \ I386 .
  • Ваш файл дампа называется C: \ Windows \ Minidump \ Minidump.dmp .

Образец 1:

  kd -y srv * c: \ symbols * http: //msdl.microsoft.com/download/symbols -i c: \ windows \ i386 -z c: \ windows \ minidump \ minidump.dmp  

Пример 2. Если вы предпочитаете графическую версию отладчика вместо версии для командной строки, введите вместо нее следующую команду:

  windbg -y srv * c: \ symbols * http: //msdl.microsoft.com/download/symbols -i c: \ windows \ i386 -z c: \ windows \ minidump \ minidump.dmp  

Изучите файл дампа

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

  • Команда ! Analysis -show отображает код ошибки Stop и ее параметры. Код ошибки Stop также известен как код проверки ошибки.
  • Команда ! Analysis -v выводит подробный вывод.
  • Команда lm N T выводит список указанных загруженных модулей.Вывод включает статус и путь модуля.

Примечание

Команда расширения! Drivers отображает список всех драйверов, загруженных на конечный компьютер, вместе со сводной информацией об использовании ими памяти. Расширение! Drivers устарело в Windows XP и более поздних версиях. Чтобы отобразить информацию о загруженных драйверах и других модулях, используйте команду lm . Команда lm N T отображает информацию в формате, аналогичном старому расширению драйверов!.

Для получения справки по другим командам и полного синтаксиса команд см. Справочную документацию средств отладки. Справочную документацию по средствам отладки можно найти по следующему адресу:

C: \ Program Files \ Инструменты отладки для Windows \ Debugger.chm

Примечание

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

Упростите команды с помощью командного файла

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

  cd "c: \ program files \ debugging tools for windows" kd -y srv * c: \ symbols * http: //msdl.microsoft.com/download/symbols -i c: \ windows \ i386 -z% 1  

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

  дамп c: \ windows \ minidump \ minidump.dmp  
.

Расширенное устранение неполадок для Stop-ошибки или ошибки синего экрана - Windows Client Management

  • Читать 19 минут

В этой статье

Примечание

Если вы не являетесь агентом службы поддержки или ИТ-специалистом, дополнительную полезную информацию о сообщениях об ошибке Stop («синий экран») можно найти в разделе «Устранение неполадок с ошибками синего экрана».

Что вызывает Stop-ошибки?

Stop-ошибка отображается в виде синего экрана, содержащего имя неисправного драйвера, например любого из следующих драйверов в качестве примера:

  • atikmpag.sys
  • igdkmd64.sys
  • nvlddmkm.sys

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

Наш анализ первопричин сбоев показывает следующее:

  • 70 процентов вызваны кодом стороннего драйвера
  • 10 процентов вызваны проблемами оборудования
  • 5 процентов вызваны кодом Microsoft
  • 15 процентов имеют неизвестные причины (поскольку память слишком повреждена для анализа)

Общие шаги по устранению неполадок

Чтобы устранить сообщения об ошибках Stop, выполните следующие общие действия:

  1. Просмотрите код ошибки Stop, который вы найдете в журналах событий.Найдите в Интернете конкретные коды Stop-ошибок, чтобы узнать, есть ли какие-либо известные проблемы, способы их решения или обходные пути.

  2. В качестве наилучшей практики мы рекомендуем сделать следующее:

    а. Убедитесь, что вы устанавливаете последние обновления Windows, накопительные обновления и накопительные обновления. Чтобы проверить статус обновления, обратитесь к соответствующей истории обновлений для вашей системы:

  3. Запустите диагностический пакет Windows сборщика дампа памяти машины.Этот диагностический инструмент используется для сбора файлов дампа памяти машины и поиска известных решений.

  4. Запустите Microsoft Safety Scanner или любую другую программу обнаружения вирусов, которая включает проверку главной загрузочной записи на наличие заражений.

  5. Убедитесь, что на жестком диске достаточно свободного места. Точные требования варьируются, но мы рекомендуем 10–15 процентов свободного дискового пространства.

  6. Обратитесь к поставщику соответствующего оборудования или программного обеспечения для обновления драйверов и приложений в следующих случаях:

    • Сообщение об ошибке указывает на то, что конкретный драйвер вызывает проблему.

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

    • Вы внесли изменения в программное или аппаратное обеспечение.

Сборник дампа памяти

Чтобы настроить систему для файлов дампа памяти, выполните следующие действия:

  1. Загрузите инструмент DumpConfigurator.
  2. Распакуйте файл .zip и перейдите в папку Source Code .
  3. Запустите инструмент DumpConfigurator.hta и выберите Повысить уровень HTA .
  4. Выберите Auto Config Kernel .
  5. Перезагрузите компьютер, чтобы настройки вступили в силу.
  6. Остановите и отключите службы автоматического перезапуска системы (ASR), чтобы предотвратить запись файлов дампа.
  7. Если сервер виртуализирован, отключите автоматическую перезагрузку после создания файла дампа памяти.Это позволяет вам сделать снимок текущего состояния сервера, а также в случае повторения проблемы.

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

Тип файла дампа Расположение
(нет) % SystemRoot% \ MEMORY.DMP (неактивен или выделен серым цветом)
Файл малого дампа памяти (256 кб) % SystemRoot% \ Minidump
Файл дампа памяти ядра % SystemRoot% \ MEMORY.DMP
Файл полного дампа памяти % SystemRoot% \ MEMORY.DMP
Файл автоматического дампа памяти % SystemRoot% \ MEMORY.DMP
Файл активного дампа памяти % SystemRoot% \ MEMORY.DMP

Вы можете использовать средство Microsoft DumpChk (средство проверки файлов аварийного дампа), чтобы убедиться, что файлы дампа памяти не повреждены и не являются недопустимыми. Дополнительную информацию смотрите в следующем видео:

Дополнительная информация о том, как использовать Dumpchk.exe, чтобы проверить файлы дампа:

Настройки файла подкачки

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

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

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

Вы можете использовать такие инструменты, как Windows Software Development KIT (SDK) и Symbols, для диагностики журналов дампа. В следующем разделе обсуждается, как использовать этот инструмент.

Расширенные действия по устранению неполадок

Примечание

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

Ссылки на расширенную отладку

Расширенная отладка Windows
Инструменты отладки для Windows (WinDbg, KD, CDB, NTSD)

Этапы отладки

  1. Убедитесь, что компьютер настроен на создание файла полного дампа памяти при сбое. См. Шаги здесь для получения дополнительной информации.
  2. Найдите память.dmp в каталоге Windows на компьютере, на котором происходит сбой, и скопируйте этот файл на другой компьютер.
  3. На другом компьютере загрузите Windows 10 SDK.
  4. Запустите установку и выберите Debugging Tools for Windows . Устанавливается инструмент WinDbg.
  5. Откройте инструмент WinDbg и установите путь к символу, щелкнув Файл , а затем щелкнув Путь к файлу символа .
    а. Если компьютер подключен к Интернету, введите общедоступный сервер символов Microsoft (https: // msdl.microsoft.com/download/symbols) и нажмите ОК . Это рекомендуемый метод.
    г. Если компьютер не подключен к Интернету, необходимо указать путь к локальному символу.
  6. Щелкните Open Crash Dump , а затем откройте файл memory.dmp, который вы скопировали. См. Пример ниже.
  7. В разделе Bugcheck Analysis должна быть ссылка ! Analysis -v . Щелкните эту ссылку. В командной строке внизу страницы будет введена команда! Анализировать -v.
  8. Появится подробный анализ ошибок. См. Пример ниже.
  9. Прокрутите вниз до раздела, где написано STACK_TEXT . Там будут строки чисел, каждая строка которых сопровождается двоеточием и некоторым текстом. Этот текст должен сообщить вам, какая DLL вызывает сбой и, если применимо, какая служба вызывает сбой библиотеки DLL.
  10. Подробнее о том, как интерпретировать вывод STACK_TEXT, см. В разделе Использование расширения! Analysis.

Существует множество возможных причин проверки ошибок, и каждый случай уникален.В приведенном выше примере важными строками, которые можно определить по STACK_TEXT, являются 20, 21 и 22:

(здесь данные HEX удалены, а строки для ясности пронумерованы)

  1: NT! KeBugCheckEx 2: nt! PspCatchCriticalBreak + 0xff 3: nt! PspTerminateAllThreads + 0x1134cf 4: nt! PspTerminateProcess + 0xe0 5: nt! NtTerminateProcess + 0xa9 6: nt! KiSystemServiceCopyEnd + 0x13 7. nt! KiServiceLinkage 8: nt! KiDispatchException + 0x1107fe 9: nt! KiFastFailDispatch + 0xe4 10: nt! KiRaiseSecurityCheckFailure + 0x3d3 11: ntdll! RtlpHpFreeWithExceptionProtection $ filter $ 0 + 0x44 12: ntdll! _C_specific_handler + 0x96 13: ntdll! RtlpExecuteHandlerForException + 0xd 14: ntdll! RtlDispatchException + 0x358 15: ntdll! KiUserExceptionDispatch + 0x2e 16: ntdll! RtlpHpVsContextFree + 0x11e 17: ntdll! RtlpHpFreeHeap + 0x48c 18: ntdll! RtlpHpFreeWithExceptionProtection + 0xda 19: ntdll! RtlFreeHeap + 0x24a 20: FWPolicyIOMgr! FwBinariesFree + 0xa7c2 21: mpssvc! FwMoneisDiagEdpPolicyUpdate + 0x1584f 22: mpssvc! FwEdpMonUpdate + 0x6c 23: ntdll! RtlpWnfWalkUserSubscriptionList + 0x29b 24: ntdll! RtlpWnfProcessCurrentDescriptor + 0x105 25: ntdll! RtlpWnfNotificationThread + 0x80 26: ntdll! TppExecuteWaitCallback + 0xe1 27: ntdll! TppWorkerThread + 0x8d0 28: KERNEL32! BaseThreadInitThunk + 0x14 29: ntdll! RtlUserThreadStart + 0x21  

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

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

Видеоресурсы

Следующие видеоролики иллюстрируют различные методы устранения неполадок при анализе файлов дампа.

Расширенное устранение неполадок с помощью Driver Verifier

По нашим оценкам, около 75% всех Stop-ошибок вызваны неисправными драйверами.Средство проверки драйверов предоставляет несколько методов для устранения неполадок. К ним относятся запуск драйверов в изолированном пуле памяти (без совместного использования памяти с другими компонентами), создание чрезмерной нагрузки на память и проверка параметров. Если инструмент обнаруживает ошибки при выполнении кода драйвера, он заранее создает исключение, чтобы эта часть кода могла быть исследована дальше.

Предупреждение

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

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

Используйте следующие рекомендации при использовании Driver Verifier:

  • Проверьте все «подозрительные» драйверы (драйверы, которые были недавно обновлены или заведомо проблемные).
  • Если вы по-прежнему испытываете не поддающиеся анализу сбои, попробуйте включить проверку для всех сторонних и неподписанных драйверов.
  • Включить одновременную проверку для групп из 10–20 драйверов.
  • Кроме того, если компьютер не может загрузиться на рабочий стол из-за средства проверки драйверов, вы можете отключить этот инструмент, запустив его в безопасном режиме. Это связано с тем, что инструмент не может работать в безопасном режиме.

Для получения дополнительной информации см. Средство проверки драйверов.

Распространенные ошибки Windows Stop

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

В следующей таблице перечислены общие процедуры поиска и устранения распространенных кодов ошибок Stop.

Сообщение об ошибке Stop и код Смягчение
VIDEO_ENGINE_TIMEOUT_DETECTED или VIDEO_TDR_TIMEOUT_DETECTED
Stop error code 0x00000141, or 0x00000117
Обратитесь к поставщику указанного драйвера дисплея, чтобы получить соответствующее обновление для этого драйвера.
DRIVER_IRQL_NOT_LESS_OR_EQUAL
Код ошибки Stop 0x0000000D1
Примените последние обновления для драйвера, применив последние накопительные обновления для системы через веб-сайт каталога Центра обновления Майкрософт.Обновите устаревший драйвер сетевой карты. Виртуализированные системы VMware часто используют «Сетевое соединение Intel (R) PRO / 1000 MT» (e1g6032e.sys). Этот драйвер доступен по адресу http://downloadcenter.intel.com. Обратитесь к поставщику оборудования, чтобы обновить драйвер сетевой карты для разрешения проблемы. Для систем VMware используйте встроенный драйвер сетевой карты VMware (можно использовать типы VMXNET или VMXNET2, VMXNET3) вместо Intel e1g6032e.sys.
PAGE_FAULT_IN_NONPAGED_AREA
Код ошибки Stop 0x000000050
Если драйвер указан в сообщении об ошибке Stop, обратитесь к производителю за обновлением.Если обновления недоступны, отключите драйвер и следите за стабильностью системы. Запустите Chkdsk / f / r, чтобы обнаружить и исправить ошибки диска. Перед сканированием диска системного раздела необходимо перезагрузить систему. Обратитесь к производителю за любыми диагностическими инструментами, которые они могут предоставить для подсистемы жесткого диска. Попробуйте переустановить любое приложение или службу, которые были недавно установлены или обновлены. Возможно, что сбой был вызван, когда система запускала приложения и считывала реестр для настроек предпочтений.Переустановка приложения может исправить поврежденные разделы реестра. Если проблема не исчезнет и вы запустили последнюю резервную копию состояния системы, попробуйте восстановить кусты реестра из резервной копии.
SYSTEM_SERVICE_EXCEPTION
Код ошибки остановки c000021a {Неустранимая системная ошибка} Системный процесс подсистемы Windows неожиданно завершился со статусом 0xc0000005. Система была закрыта.
Воспользуйтесь средством проверки системных файлов для восстановления отсутствующих или поврежденных системных файлов.Средство проверки системных файлов позволяет пользователям сканировать системные файлы Windows на наличие повреждений и восстанавливать поврежденные файлы. Дополнительные сведения см. В разделе Использование средства проверки системных файлов.
NTFS_FILE_SYSTEM
Код ошибки Stop 0x000000024
Эта Stop-ошибка обычно вызвана повреждением файловой системы NTFS или поврежденными блоками (секторами) на жестком диске. Поврежденные драйверы для жестких дисков (SATA или IDE) также могут отрицательно повлиять на способность системы читать и писать на диск. Запустите любую диагностику оборудования, предоставленную производителем подсистемы хранения.Используйте инструмент сканирования диска, чтобы убедиться, что в файловой системе нет ошибок. Для этого щелкните правой кнопкой мыши диск, который вы хотите сканировать, выберите «Свойства», выберите «Инструменты», а затем нажмите кнопку «Проверить сейчас». Мы также предлагаем обновить драйвер файловой системы NTFS (Ntfs.sys) и применить последнюю версию. накопительные обновления для текущей операционной системы, в которой возникла проблема.
KMODE_EXCEPTION_NOT_HANDLED
Код ошибки Stop 0x0000001E
Если драйвер указан в сообщении об ошибке Stop, отключите или удалите этот драйвер.Отключите или удалите все драйверы или службы, которые были недавно добавлены.

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

Перейдите в Настройки > Обновление и безопасность> Восстановление . В разделе Расширенный запуск выберите Перезагрузить сейчас . После перезагрузки ПК на экране выберите параметр , выберите «Устранение неполадок »> «Дополнительные параметры»> «Параметры запуска»> «Перезагрузить ».После перезагрузки компьютера вы увидите список параметров. Нажмите 4 или F4 , чтобы запустить компьютер в безопасном режиме. Или, если вы собираетесь использовать Интернет в безопасном режиме, нажмите 5 или F5 для выбора безопасного режима с подключением к сети.

DPC_WATCHDOG_VIOLATION
Код ошибки Stop 0x00000133
Этот код Stop-ошибки вызван неисправным драйвером, который не завершает свою работу в течение отведенного периода времени при определенных условиях.Чтобы помочь нам уменьшить эту ошибку, соберите файл дампа памяти из системы, а затем используйте отладчик Windows для поиска неисправного драйвера. Если драйвер указан в сообщении об ошибке Stop, отключите драйвер, чтобы локализовать проблему. Обратитесь к производителю за обновлениями драйверов. Проверьте системный журнал в средстве просмотра событий на наличие дополнительных сообщений об ошибках, которые могут помочь идентифицировать устройство или драйвер, вызывающие Stop-ошибку 0x133. Убедитесь, что все новое установленное оборудование совместимо с установленной версией Windows.Например, вы можете получить информацию о необходимом оборудовании в разделе «Технические характеристики Windows 10». Если отладчик Windows установлен и у вас есть доступ к общедоступным символам, вы можете загрузить файл c: \ windows \ memory.dmp в отладчик, а затем обратиться к разделу Определение источника ошибок проверки ошибок 0x133 (DPC_WATCHDOG_VIOLATION) в Windows Server 2012 найти проблемный драйвер из дампа памяти.
USER_MODE_HEALTH_MONITOR
Код ошибки Stop 0x0000009E
Эта Stop-ошибка указывает на то, что проверка работоспособности в пользовательском режиме завершилась неудачно, что препятствует постепенному завершению работы.Следовательно, Windows восстанавливает критически важные службы путем перезапуска или включения переключения приложений на другие серверы. Служба кластеризации включает механизм обнаружения, который может обнаруживать отсутствие ответа в компонентах пользовательского режима.
Эта Stop-ошибка обычно возникает в кластерной среде, и указанным неисправным драйвером является RHS.exe. Проверьте журналы событий на наличие сбоев хранилища, чтобы определить сбойный процесс. Попробуйте обновить компонент или процесс, указанный в журналах событий. Вы должны увидеть следующее записанное событие:
Идентификатор события: 4870
Источник: Microsoft-Windows-FailoverClustering
Описание. Мониторинг состояния в пользовательском режиме обнаружил, что система не отвечает.Виртуальный адаптер отказоустойчивого кластера потерял связь с процессом сервера кластера с идентификатором процесса «% 1» на «% 2» секунд. Выполняется действие по восстановлению. Просмотрите журналы кластера, чтобы определить процесс и выяснить, какие элементы могут привести к зависанию процесса.
Для получения дополнительной информации см. «Почему мой узел отказоустойчивой кластеризации показывает синий экран со значением Stop 0x0000009E?» Также см. Следующее видео Microsoft «Что делать в случае возникновения ошибки 9E».

Примеры отладки

Пример 1

Эта проверка ошибок вызвана зависанием драйвера во время обновления, что привело к проверке ошибок D1 в NDIS.sys (драйвер Microsoft). IMAGE_NAME сообщает вам неисправный драйвер, но, поскольку это драйвер Microsoft, его нельзя заменить или удалить. Метод разрешения - отключить сетевое устройство в диспетчере устройств и повторить попытку обновления.

  2: kd>! Анализировать -v ************************************************* ***************************** * * * Анализ ошибок * * * ************************************************* ***************************** DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) Была сделана попытка получить доступ к выгружаемому (или полностью недействительному) адресу на уровень запроса прерывания (IRQL) слишком высок.Обычно это вызвано драйверами, использующими неправильные адреса. Если доступен отладчик ядра, получить трассировку стека. Аргументы: Arg1: 000000000011092a, ссылка на память Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, значение 0 = операция чтения, 1 = операция записи Arg4: fffff807aa74f4c4, адрес, который ссылается на память Детали отладки: ------------------ KEY_VALUES_STRING: 1 STACKHASH_ANALYSIS: 1 TIMELINE_ANALYSIS: 1 DUMP_CLASS: 1 DUMP_QUALIFIER: 400 SIMULTANEOUS_TELSVC_INSTANCES: 0 SIMULTANEOUS_TELWP_INSTANCES: 0 BUILD_VERSION_STRING: 16299.15.amd64fre.rs3_release.170928-1534 SYSTEM_MANUFACTURER: Alienware SYSTEM_PRODUCT_NAME: Alienware 15 R2 SYSTEM_SKU: Alienware 15 R2 SYSTEM_VERSION: 1.2.8 BIOS_VENDOR: Alienware BIOS_VERSION: 1.2.8 BIOS_DATE: 29.01.2016 BASEBOARD_MANUFACTURER: Alienware BASEBOARD_PRODUCT: Alienware 15 R2 BASEBOARD_VERSION: A00 DUMP_TYPE: 2 BUGCHECK_P1: 11092a BUGCHECK_P2: 2 BUGCHECK_P3: 1 BUGCHECK_P4: fffff807aa74f4c4 WRITE_ADDRESS: fffff80060602380: невозможно получить MiVisibleState Невозможно получить NonPagedPoolStart Невозможно получить NonPagedPoolEnd Невозможно получить PagedPoolStart Невозможно получить PagedPoolEnd 000000000011092a CURRENT_IRQL: 2 FAULTING_IP: NDIS! NdisQueueIoWorkItem + 4 [minio \ ndis \ sys \ miniport.c @ 9708] fffff807`aa74f4c4 48895120 mov qword ptr [rcx + 20h], rdx CPU_COUNT: 8 CPU_MHZ: a20 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 5e CPU_STEPPING: 3 CPU_MICROCODE: 6,5e, 3,0 (F, M, S, R) SIG: BA'00000000 (кеш) BA'00000000 (инициализация) BLACKBOXPNP: 1 (! Blackboxpnp) DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: Система ANALYSIS_SESSION_HOST: SHENDRIX-DEV0 ANALYSIS_SESSION_TIME: 01-17-2019 11: 06: 05.0653 АНАЛИЗ_ВЕРСИЯ: 10.0.18248.1001 amd64fre TRAP_FRAME: ffffa884c0c3f6b0 - (.ловушка 0xffffa884c0c3f6b0) ПРИМЕЧАНИЕ: кадр прерывания не содержит всех регистров. Некоторые значения регистров могут быть обнулены или неверны. rax = fffff807ad018bf0 rbx = 0000000000000000 rcx = 000000000011090a rdx = fffff807ad018c10 rsi = 0000000000000000 rdi = 0000000000000000 rip = fffff807aa74f4c4 rsp = ffffa884c0c3f840 rbp = 000000002408fd00 r8 = ffffb30e0e99ea30 r9 = 0000000001d371c1 r10 = 0000000020000080 r11 = 0000000000000000 r12 = 0000000000000000 r13 = 0000000000000000 r14 = 0000000000000000 r15 = 0000000000000000 iopl = 0 nv up ei ng nz na pe nc NDIS! NdisQueueIoWorkItem + 0x4: fffff807`aa74f4c4 48895120 mov qword ptr [rcx + 20h], rdx ds: 00000000`0011092a = ???????????????? Сброс объема по умолчанию LAST_CONTROL_TRANSFER: с fffff800603799e9 на fffff8006036e0e0 STACK_TEXT: ffffa884`c0c3f568 fffff800`603799e9: 00000000`0000000a 00000000`0011092a 00000000`00000002 00000000`00000001: nt! KeBugCheckEx [minkernel \ ntos \ ke \ amd64 \ procstat.asm @ 134] ffffa884`c0c3f570 fffff800`60377d7d: fffff78a`4000a150 ffffb30e`03fba001 ffff8180`f0b5d180 00000000`000000ff: nt! KiBugCheckDispatch + 0x69 [minkernel amdas \ kep ffffa884`c0c3f6b0 fffff807`aa74f4c4: 00000000`00000002 ffff8180`f0754180 00000000`00269fb1 ffff8180`f0754180: nt! KiPageFault + 0x23d [minkernel \ ntos \ ke \ amd64 \ trap] ffffa884`c0c3f840 fffff800`60256b63: ffffb30e`0e18f710 ffff8180`f0754180 ffffa884`c0c3fa18 00000000`00000002: NDIS! NdisQueueIoWorkItem + 0x4 [minio \ ndiport \ sys.c @ 9708] ffffa884`c0c3f870 fffff800`60257bfd: 00000000`00000008 00000000`00000000 00000000`00269fb1 ffff8180`f0754180: nt! KiProcessExpiredTimerList + 0x153 [minkernel \ ntos \ ke \ dpcsup.c @ 2078] ffffa884`c0c3f960 fffff800`6037123a: 00000000`00000000 ffff8180`f0754180 00000000`00000000 ffff8180`f0760cc0: nt! KiRetireDpcList + 0x43d [minkernel \ ntos \ ke \ dpcsup.c @ 1512] ffffa884`c0c3fb60 00000000`00000000: ffffa884`c0c40000 ffffa884`c0c39000 00000000`00000000 00000000`00000000: nt! KiIdleLoop + 0x5a [minkernel \ ntos \ ke \ amd64 \ idle.asm @ 166] RETRACER_ANALYSIS_TAG_STATUS: не удалось получить KPCR для ядра 2 THREAD_SHA1_HASH_MOD_FUNC: 5b59a784f22d4b5cbd5a8452fe39914b8fd7961d THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 5643383f9cae3ca39073f7721b53f0c633bfb948 THREAD_SHA1_HASH_MOD: 20edda059578820e64b723e466deea47f59bd675 FOLLOWUP_IP: NDIS! NdisQueueIoWorkItem + 4 [minio \ ndis \ sys \ miniport.c @ 9708] fffff807`aa74f4c4 48895120 mov qword ptr [rcx + 20h], rdx FAULT_INSTR_CODE: 20518948 FAULTING_SOURCE_LINE: minio \ ndis \ sys \ miniport.c FAULTING_SOURCE_FILE: minio \ ndis \ sys \ miniport.c FAULTING_SOURCE_LINE_NUMBER: 9708 FAULTING_SOURCE_CODE: 9704: _In_ _Points_to_data_ PVOID WorkItemContext 9705:) 9706: { 9707: > 9708: ((PNDIS_IO_WORK_ITEM) NdisIoWorkItemHandle) -> Routine = Routine; 9709: ((PNDIS_IO_WORK_ITEM) NdisIoWorkItemHandle) -> WorkItemContext = WorkItemContext; 9710: 9711: IoQueueWorkItem (((PNDIS_IO_WORK_ITEM) NdisIoWorkItemHandle) -> IoWorkItem, 9712: ndisDispatchIoWorkItem, 9713: CriticalWorkQueue, SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: NDIS! NdisQueueIoWorkItem + 4 FOLLOWUP_NAME: ndiscore MODULE_NAME: NDIS IMAGE_NAME: NDIS.SYS DEBUG_FLR_IMAGE_TIMESTAMP: 0 IMAGE_VERSION: 10.0.16299.99 DXGANALYZE_ANALYSIS_TAG_PORT_GLOBAL_INFO_STR: гибридный_FALSE DXGANALYZE_ANALYSIS_TAG_ADAPTER_INFO_STR: GPU0_VenId0x1414_DevId0x8d_WDDM1.3_Active; STACK_COMMAND: .thread; .cxr; kb BUCKET_ID_FUNC_OFFSET: 4 FAILURE_BUCKET_ID: AV_NDIS! NdisQueueIoWorkItem BUCKET_ID: AV_NDIS! NdisQueueIoWorkItem PRIMARY_PROBLEM_CLASS: AV_NDIS! NdisQueueIoWorkItem TARGET_TIME: 2017-12-10T14: 16: 08.000Z OSBUILD: 16299 ОССЕРВИСУПАК: 98 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 ЛЮКС_МАСКА: 784 PRODUCT_TYPE: 1 OSPLATFORM_TYPE: x64 ИМЯ ОС: Windows 10 ИЗДАНИЕ: Windows 10 WinNt TerminalServer SingleUserTS Personal OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2017-11-26 03:49:20 BUILDDATESTAMP_STR: 170928-1534 BUILDLAB_STR: rs3_release BUILDOSVER_STR: 10.0.16299.15.amd64fre.rs3_release.170928-1534 ANALYSIS_SESSION_ELAPSED_TIME: 8377 АНАЛИЗ_ИСТОЧНИК: КМ FAILURE_ID_HASH_STRING: км: av_ndis! Ndisqueueioworkitem FAILURE_ID_HASH: {10686423-afa1-4852-ad1b-9324ac44ac96} FAILURE_ID_REPORT_LINK: https://go.microsoft.com/fwlink/?LinkID=397724&FailureHash=10686423-afa1-4852-ad1b-9324ac44ac96 Продолжение: ndiscore ---------  

Пример 2

В этом примере драйвер стороннего производителя вызвал ошибку страницы, поэтому у нас нет символов для этого драйвера.Однако если посмотреть на IMAGE_NAME и / или MODULE_NAME , это указывает на то, что причиной проблемы является WwanUsbMP.sys . Возможным решением является отключение устройства и повторная попытка обновления.

  1: kd>! Анализировать -v ************************************************* ***************************** * * * Анализ ошибок * * * ************************************************* ***************************** PAGE_FAULT_IN_NONPAGED_AREA (50) Обращение к недопустимой системной памяти.Это не может быть защищено с помощью try-except. Обычно адрес просто плохой или указывает на освобожденную память. Аргументы: Arg1: 8ba10000, ссылка на память. Arg2: 00000000, значение 0 = операция чтения, 1 = операция записи. Arg3: 82154573, если ненулевое значение, адрес инструкции, которая ссылается на плохую память. адрес. Arg4: 00000000, (зарезервировано) Детали отладки: ------------------ *** ВНИМАНИЕ: невозможно проверить отметку времени для WwanUsbMp.sys *** ОШИБКА: загрузка модуля завершена, но символы для WwanUsbMp не могут быть загружены.sys KEY_VALUES_STRING: 1 STACKHASH_ANALYSIS: 1 TIMELINE_ANALYSIS: 1 DUMP_CLASS: 1 DUMP_QUALIFIER: 400 BUILD_VERSION_STRING: 16299.15.x86fre.rs3_release.170928-1534 MARKER_MODULE_NAME: IBM_ibmpmdrv SYSTEM_MANUFACTURER: LENOVO SYSTEM_PRODUCT_NAME: 20AWS07H00 SYSTEM_SKU: LENOVO_MT_20AW_BU_Think_FM_ThinkPad T440p СИСТЕМА_ВЕРСИЯ: ThinkPad T440p BIOS_VENDOR: LENOVO BIOS_VERSION: GLET85WW (2.39) BIOS_DATE: 29.09.2016 BASEBOARD_MANUFACTURER: LENOVO BASEBOARD_PRODUCT: 20AWS07H00 BASEBOARD_VERSION: не определено DUMP_TYPE: 2 BUGCHECK_P1: ffffffff8ba10000 BUGCHECK_P2: 0 BUGCHECK_P3: ffffffff82154573 BUGCHECK_P4: 0 READ_ADDRESS: 822821d0: невозможно получить MiVisibleState 8ba10000 FAULTING_IP: nt! memcpy + 33 [minkernel \ crts \ crtw32 \ string \ i386 \ memcpy.asm @ 213 82154573 f3a5 rep movs dword ptr es: [edi], dword ptr [esi] MM_INTERNAL_CODE: 0 CPU_COUNT: 4 CPU_MHZ: 95a CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 3c CPU_STEPPING: 3 CPU_MICROCODE: 6,3c, 3,0 (F, M, S, R) SIG: 21'00000000 (кеш) 21'00000000 (инициализация) BLACKBOXBSD: 1 (! Blackboxbsd) BLACKBOXPNP: 1 (! Blackboxpnp) DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: Система CURRENT_IRQL: 2 ANALYSIS_SESSION_HOST: SHENDRIX-DEV0 ВРЕМЯ СЕССИИ АНАЛИЗА: 17.01.2019 10:54:53.0780 АНАЛИЗ_ВЕРСИЯ: 10.0.18248.1001 amd64fre TRAP_FRAME: 8ba0efa8 - (.trap 0xffffffff8ba0efa8) ErrCode = 00000000 eax = 8ba1759e ebx = a2bfd314 ecx = 00001d67 edx = 00000002 esi = 8ba10000 edi = a2bfe280 eip = 82154573 esp = 8ba0f01c ebp = 8ba0f024 iopl = 0 nv up ei pl nz ac pe nc cs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00010216 nt! memcpy + 0x33: 82154573 f3a5 rep movs dword ptr es: [edi], dword ptr [esi] Сброс объема по умолчанию LOCK_ADDRESS: 8226c6e0 - (! Блокирует 8226c6e0) Не удается получить тип _ERESOURCE Ресурс @ nt! PiEngineLock (0x8226c6e0) доступен Всего замков: 1 PNP_TRIAGE_DATA: Адрес блокировки: 0x8226c6e0 Количество потоков: 0 Адрес темы: 0x00000000 Ожидание потока: 0x0 LAST_CONTROL_TRANSFER: с 82076708 на 821507e8 STACK_TEXT: 8ba0ede4 82076708 00000050 8ba10000 00000000 nt! KeBugCheckEx [minkernel \ ntos \ ke \ i386 \ procstat.asm @ 114] 8ba0ee40 8207771e 8ba0efa8 8ba10000 8ba0eea0 nt! MiSystemFault + 0x13c8 [minkernel \ ntos \ mm \ mmfault.c @ 4755] 8ba0ef08 821652ac 00000000 8ba10000 00000000 nt! MmAccessFault + 0x83e [minkernel \ ntos \ mm \ mmfault.c @ 6868] 8ba0ef08 82154573 00000000 8ba10000 00000000 nt! _KiTrap0E + 0xec [minkernel \ ntos \ ke \ i386 \ trap.asm @ 5153] 8ba0f024 86692866 a2bfd314 8ba0f094 0000850a nt! Memcpy + 0x33 [minkernel \ crts \ crtw32 \ string \ i386 \ memcpy.asm @ 213] 8ba0f040 866961bc 8ba0f19c a2bfd0e8 00000000 NDIS! NdisMSetPowerManagementCapabilities + 0x8a [minio \ ndis \ sys \ miniport.c @ 7969] 8ba0f060 866e1f66 866e1caf adfb9000 00000000 NDIS! NdisMSetGeneralAttributes + 0x23d [minio \ ndis \ sys \ miniport.c @ 8198] 8ba0f078 ac50c15f a2bfd0e8 0000009f 00000001 NDIS! NdisMSetMiniportAttributes + 0x2b7 [minio \ ndis \ sys \ miniport.c @ 7184] ВНИМАНИЕ! Информация о размотке стека недоступна. Следующие кадры могут быть неправильными. 8ba0f270 ac526f96 adfb9000 a2bfd0e8 8269b9b0 WwanUsbMp + 0x1c15f 8ba0f3cc 866e368a a2bfd0e8 00000000 8ba0f4c0 WwanUsbMp + 0x36f96 8ba0f410 867004b0 a2bfd0e8 a2bfd0e8 a2be2a70 NDIS! NdisMInvokeInitialize + 0x60 [minio \ ndis \ sys \ miniport.c @ 13834] 8ba0f7ac 866dbc8e a2acf730 866b807c 00000000 NDIS! NdisMInitializeAdapter + 0xa23 [minio \ ndis \ sys \ miniport.c @ 601] 8ba0f7d8 866e687d a2bfd0e8 00000000 00000000 NDIS! NdisInitializeAdapter + 0x4c [minio \ ndis \ sys \ initpnp.c @ 931] 8ba0f800 866e90bb adfb64d8 00000000 a2bfd0e8 NDIS! NdisPnPStartDevice + 0x118 [minio \ ndis \ sys \ configm.c @ 4235] 8ba0f820 866e8a58 adfb64d8 a2bfd0e8 00000000 NDIS! NdisStartDeviceSynchronous + 0xbd [minio \ ndis \ sys \ ndispnp.c @ 3096] 8ba0f838 866e81df adfb64d8 8ba0f85e 8ba0f85f NDIS! NdisPnPIrpStartDevice + 0xb4 [minio \ ndis \ sys \ ndispnp.c @ 1067] 8ba0f860 820a7e98 a2bfd030 adfb64d8 8ba0f910 NDIS! NdisPnPDispatch + 0x108 [minio \ ndis \ sys \ ndispnp.c @ 2429] 8ba0f878 8231f07e 8ba0f8ec adf5d4c8 872e2eb8 nt! IofCallDriver + 0x48 [minkernel \ ntos \ io \ iomgr \ iosubs.c @ 3149] 8ba0f898 820b8569 820c92b8 872e2eb8 8ba0f910 nt! PnpAsynchronousCall + 0x9e [minkernel \ ntos \ io \ pnpmgr \ irp.c @ 3005] 8ba0f8cc 820c9a76 00000000 820c92b8 872e2eb8 nt! PnpSendIrp + 0x67 [minkernel \ ntos \ io \ pnpmgr \ irp.h @ 286] 8ba0f914 8234577b 872e2eb8 adf638b0 adf638b0 nt! PnpStartDevice + 0x60 [minkernel \ ntos \ io \ pnpmgr \ irp.c @ 3187] 8ba0f94c 82346cc7 872e2eb8 adf638b0 adf638b0 nt! PnpStartDeviceNode + 0xc3 [minkernel \ ntos \ io \ pnpmgr \ start.c @ 1712] 8ba0f96c 82343c68 00000000 a2bdb3d8 adf638b0 nt! PipProcessStartPhase1 + 0x4d [minkernel \ ntos \ io \ pnpmgr \ start.c @ 114] 8ba0fb5c 824db885 8ba0fb80 00000000 00000000 nt! PipProcessDevNodeTree + 0x386 [minkernel \ ntos \ io \ pnpmgr \ enum.c @ 6129] 8ba0fb88 8219571b 85852520 8c601040 8226ba90 nt! PiRestartDevice + 0x91 [minkernel \ ntos \ io \ pnpmgr \ enum.c @ 4743] 8ba0fbe8 820804af 00000000 00000000 8c601040 nt! PnpDeviceActionWorker + 0xdb4b7 [minkernel \ ntos \ io \ pnpmgr \ action.c @ 674] 8ba0fc38 8211485c 85852520 421de295 00000000 nt! ExpWorkerThread + 0xcf [minkernel \ ntos \ ex \ worker.c @ 4270] 8ba0fc70 82166785 820803e0 85852520 00000000 nt! PspSystemThreadStartup + 0x4a [minkernel \ ntos \ ps \ psexec.c @ 7756] 8ba0fc88 82051e07 85943940 8ba0fcd8 82051bb9 nt! KiThreadStartup + 0x15 [minkernel \ ntos \ ke \ i386 \ threadbg.asm @ 82] 8ba0fc94 82051bb9 8b9cc600 8ba10000 8ba0d000 nt! KiProcessDeferredReadyList + 0x17 [minkernel \ ntos \ ke \ thredsup.c @ 5309] 8ba0fcd8 00000000 00000000 00000000 00000000 nt! KeSetPriorityThread + 0x249 [minkernel \ ntos \ ke \ thredobj.c @ 3881] RETRACER_ANALYSIS_TAG_STATUS: не удалось получить KPCR для ядра 1 THREAD_SHA1_HASH_MOD_FUNC: e029276c66aea80ba36903e89947127118d31128 THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 012389f065d31c8eedd6204846a560146a38099b THREAD_SHA1_HASH_MOD: 44dc639eb162a28d47eaeeae4afe6f9eeccced3d FOLLOWUP_IP: WwanUsbMp + 1c15f ac50c15f 8bf0 mov esi, eax FAULT_INSTR_CODE: f33bf08b SYMBOL_STACK_INDEX: 8 SYMBOL_NAME: WwanUsbMp + 1c15f FOLLOWUP_NAME: MachineOwner MODULE_NAME: WwanUsbMp IMAGE_NAME: WwanUsbMp.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5211bb0c DXGANALYZE_ANALYSIS_TAG_PORT_GLOBAL_INFO_STR: гибридный_FALSE DXGANALYZE_ANALYSIS_TAG_ADAPTER_INFO_STR: GPU0_VenId0x1414_DevId0x8d_WDDM1.3_NotActive; GPU1_VenId0x8086_DevId0x416_WDDM1.3_Active_Post; STACK_COMMAND: .thread; .cxr; kb BUCKET_ID_FUNC_OFFSET: 1c15f FAILURE_BUCKET_ID: AV_R_INVALID_WwanUsbMp! Unknown_function BUCKET_ID: AV_R_INVALID_WwanUsbMp! Unknown_function PRIMARY_PROBLEM_CLASS: AV_R_INVALID_WwanUsbMp! Unknown_function TARGET_TIME: 2018-02-12T11: 33: 51.000Z OSBUILD: 16299 ОССЕРВИСУПАК: 15 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 ЛЮКС_МАСКА: 272 PRODUCT_TYPE: 1 OSPLATFORM_TYPE: x86 ИМЯ ОС: Windows 10 ИЗДАНИЕ: Windows 10 WinNt TerminalServer SingleUserTS OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2017-09-28 18:32:28 BUILDDATESTAMP_STR: 170928-1534 BUILDLAB_STR: rs3_release BUILDOSVER_STR: 10.0.16299.15.x86fre.rs3_release.170928-1534 ANALYSIS_SESSION_ELAPSED_TIME: 162bd АНАЛИЗ_ИСТОЧНИК: КМ FAILURE_ID_HASH_STRING: km: av_r_invalid_wwanusbmp! Unknown_function FAILURE_ID_HASH: {31e4d053-0758-e43a-06a7-55f69b072cb3} FAILURE_ID_REPORT_LINK: https: // go.microsoft.com/fwlink/?LinkID=397724&FailureHash=31e4d053-0758-e43a-06a7-55f69b072cb3 Продолжение: MachineOwner --------- ReadVirtual: 812d1248 неправильно подписать расширенный  

Список литературы

Ссылка на код проверки ошибки

.

Файлы дампа пользовательского режима - драйверы Windows

  • 6 минут на чтение

В этой статье

В этот раздел входят:

Для получения информации об анализе файла дампа см. Анализ файла дампа пользовательского режима.

Разновидности файлов дампа пользовательского режима

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

Полные дампы пользовательского режима

Минидампы

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

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

Полные дампы пользовательского режима

Полный дамп пользовательского режима - это базовый файл дампа пользовательского режима.

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

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

Примечание Несмотря на их названия, самый большой файл «минидампа» на самом деле содержит больше информации, чем полный дамп пользовательского режима. Например, .dump / mf или .dump / ma создаст более крупный и полный файл, чем .дамп / ф .

В пользовательском режиме . Дамп / м [ MiniOptions ] - лучший выбор. Файлы дампа, созданные с помощью этого переключателя, могут различаться по размеру от очень маленьких до очень больших. Указав правильный MiniOptions , вы можете точно контролировать, какая информация будет включена.

Минидампы

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

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

Название «минидамп» вводит в заблуждение, потому что самые большие файлы минидампа фактически содержат больше информации, чем «полный» дамп пользовательского режима. Например, .dump / mf или .dump / ma создаст более крупный и полный файл, чем .дамп / ф . По этой причине .dump / m [ MiniOptions ] рекомендовал более .dump / f для создания всех файлов дампа пользовательского режима.

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

.вариант дамп Влияние на файл дампа

/ ma

Создает минидамп со всеми необязательными дополнениями. Опция / ma эквивалентна / mfFhut - она ​​добавляет данные полной памяти, данные обработки, информацию о выгруженных модулях, основную информацию о памяти и информацию о времени потока в минидамп.

/ мф

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

/ мФ

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

/ мч

Добавляет данные о дескрипторах, связанных с целевым приложением, в минидамп.

/ мю

Добавляет информацию о выгруженном модуле в минидамп. Это доступно только в Windows Server 2003 и более поздних версиях Windows.

/ м

Добавляет дополнительную информацию о потоке в минидамп. Это включает время потоков, которое может быть отображено с помощью .ttime (Display Thread Times) при отладке минидампа.

/ ми

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

/ mp

Добавляет данные блока среды процесса (PEB) и блока среды потока (TEB) в минидамп. Это может быть полезно, если вам нужен доступ к системной информации Windows, касающейся процессов и потоков приложения.

/ mw

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

/ мкр

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

/ MC

Добавляет разделы кода в изображения.

/ mr

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

/ mR

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

/ mk " Имя файла "

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

Эти опции можно комбинировать. Например, команда .dump / mfiu может использоваться для создания довольно большого минидампа, или команда .dump / mrR может использоваться для создания минидампа, сохраняющего конфиденциальность пользователя. Для получения полной информации о синтаксисе см. .dump (создание файла дампа) .

Создание файла дампа пользовательского режима

Существует несколько различных инструментов, которые можно использовать для создания файла дампа пользовательского режима: CDB, WinDbg и Procdump.

ProcDump

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

Для получения информации о создании файла дампа пользовательского режима с помощью утилиты Sysinternals ProcDump см. ProcDump.

CDB и WinDbg

CDB и WinDbg могут создавать файлы дампа пользовательского режима различными способами.

Автоматическое создание файла дампа

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

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

Когда CDB или WinDbg отлаживают приложение в пользовательском режиме, вы также можете использовать команду .dump (Создать файл дампа) для создания файла дампа.

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

Уменьшение существующего файла дампа

CDB и WinDbg также можно использовать для сжатия файла дампа. Для этого начните отладку существующего файла дампа, а затем используйте команду .dump для создания файла дампа меньшего размера.

Отладка путешествия во времени (TTD)

Помимо CDB, WinDbg и Procdump, еще одним вариантом отладки приложений в пользовательском режиме является отладка во времени (TTD). Time Travel Debugging - это инструмент, который позволяет вам записывать выполнение вашего процесса, а затем воспроизводить его позже как вперед, так и назад.Отладка с перемещением во времени (TTD) может помочь вам упростить отладку проблем, позволяя вам «перематывать» сеанс отладчика вместо того, чтобы воспроизводить проблему, пока вы не найдете ошибку.

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

TTD может иметь преимущества перед файлами аварийного дампа, в которых часто отсутствует выполнение кода, что привело к окончательному сбою.

Для получения дополнительной информации об отладке с перемещением во времени (TTD) см. Отладка с перемещением во времени - Обзор.

.

Смотрите также