Как открыть файл дампа памяти windows 7. Анализ аварийных дампов Windows

Синий экран погибели. Анализ и расшифровка дампа памяти при BSOD

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

На прошлой недельке чинил комп на котором вылетал голубий экран погибели с различными ошибками, почаще всего BAD_POOL_CALLER — stop 0x000000c2. Диагностируется данная ошибка достаточно трудно, на его примере и попробую поведать как выяснить причину появления по голубого экрана смерти.

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

Проверьте, включено ли на вашем компе создание файлов minidump при нарушении системы.

Анализ дампа памяти. Расшифровываем minidump.

Нам пригодится установить Debugging Tools for Windows и скачать утилиту конкретно для расшифровки файла дампа kdfe.cmd

Распаковываем скрипт kdfe.cmd и кладем его конкретно в корень диска диска C: либо создаем каталог C:dump. Здесь уж как для вас удобнее. В командной строке пишем:

c:dumpkdfe.cmd

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

C:kdfe.cmd C:WindowsMinidump61715-6208-01.dmp

На мой взор 1-ый вариант удобнее. Пример того что выдал скрипт при анализе 1-го из дампов памяти:

C:Usersалексей>C:dumpkdfe.cmd Following crash dump files found: 1. “C:WindowsMEMORY.DMP” 2. “C:WindowsMinidump21113-50887-01.dmp” 3. “C:WindowsMinidump33014-29842-01.dmp” 4. “C:WindowsMinidump50515-38610-01.dmp” 5. “C:WindowsMinidump50615-34803-01.dmp” 6. “C:WindowsMinidump51315-38672-01.dmp” 7. “C:WindowsMinidump52015-36629-01.dmp” 8. “C:WindowsMinidump52515-34538-01.dmp” 9. “C:WindowsMinidump52715-39374-01.dmp” 10. “C:WindowsMinidump52815-33119-01.dmp” 11. “C:WindowsMinidump60115-31824-01.dmp” 12. “C:WindowsMinidump60115-32385-01.dmp” 13. “C:WindowsMinidump60115-33945-01.dmp” 14. “C:WindowsMinidump60115-33977-02.dmp” 15. “C:WindowsMinidump60815-39343-01.dmp” 16. “C:WindowsMinidump61015-39062-01.dmp” 17. “C:WindowsMinidump61215-44475-01.dmp” 18. “C:WindowsMinidump61315-34991-01.dmp” 19. “C:WindowsMinidump61415-33680-01.dmp” 20. “C:WindowsMinidump61715-6208-01.dmp” 21. “C:WindowsMinidump61715-7940-01.dmp” Which one would you like to analyze?[1-21] 20 Analyzing “C:WindowsMinidump61715-6208-01.dmp”, please wait… Done. Crash date: Wed Jun 17 01:28:13.148 2015 (GMT+3) Stop error code: 0x1a_31 Process name: amigo.exe Probably caused by: ntkrnlmp.exe ( nt:NNGAKEGL::`string’+7161 ) Для продолжения нажмите всякую кнопку . . .

Читайте также  Как обрезать симку самому под микро сим. Как обрезать старую (большую) Сим-карту под размер слота Micro-SIM

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

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

Подписывайтесь на канал Яндекс.Дзен и узнавайте первыми о новейших материалах, размещенных на сайте.

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

Анализ аварийных дампов Windows

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

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

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

Читайте также  Сброс на заводские настройки cisco. Как сбросить настройки у Cisco по дефолту или возвращаем магазинный вид дорогому оборудованию

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

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

srv*C:Windowssymbols*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: SystemRootsystem32driverscmudaxp.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%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.

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

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

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

Оставьте комментарий