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» возникает после физического вмешательства в компоненты компьютера (чистка пыли, апгрейд, замена термопасты) или после скачков напряжения и перегрева компонентов.

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

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

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

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

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

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

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

Сразу же после столкновения с ошибкой «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

• 28.08.2019
• 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 .

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

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

Таблица <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 . Обратите внимание на информацию о куче. Преимущество наличия информации о куче заключается в том, что при анализе нашего аварийного дампа у нас будут доступны подсказки с данными. Наше окно просмотра также может быть заполнено информацией о типе ссылки.

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

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

  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  

  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  

  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 ---------  

  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 неправильно подписать расширенный