Де зберігаються дампи bsod windows 7. Аварійний дамп пам'яті. Аналіз дамп файлу за допомогою Microsoft Kernel Debugger

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

У вказану на першому екрані папку з Інтернету буде завантажено та встановлено набір утиліт.

Після закінчення установки знаходимо в меню "Пуск" або на стартовому екраніу групі ярликів Windows Kitsутиліту WinDbgі запускаємо її з правами адміністратора

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

У головному меню програми WinDbgвибираємо пункти File > Symbol File Path. У вікно, що відкрилося, вставляємо рядок визначальний нехай до локального каталогу символьного кеша і його онлайн-джерелу:

Зберігаємо налаштування, вибравши в головному меню пункти File > Save Workspace

Відкриваємо файл дампа пам'яті, вибравши меню File > Open Crash Dump...

Вибираємо файл MEMORY.DMP(за замовчуванням розташований у каталозі C:\Windows) і натискаємо Open

З'явиться інформація про те, який модуль, що виконується, став причиною зупинки роботи системи. Клацнувши за посиланням !analyze-vможна отримати більш розгорнуту інформацію про стан системи на момент виникнення стоп-помилки.

Ту ж саму інформацію можна отримати і за допомогою командного рядка, використовуючи приблизно наступну послідовність команд:

У цьому прикладі вся інформація про розбір дампа буде вивантажена в вигляді, що читається, у файл C:\Debuglog.txt

Джерела інформації:

Причиною критичних помилок Windows, що супроводжуються синіми екранами (BSOD), часто є драйвер - знову встановлений або пошкоджений. Визначивши, який саме драйвер є причиною помилки, можна приступати до усунення проблеми: оновити драйвер, відкотитися до більш ранньої версії, перевстановити або видалити програму, яка встановила драйвер і т. д. Не завжди назва драйвера відображається на синьому екрані. Однак існує дуже простий спосіб, що дозволяє за допомогою дампа пам'яті визначити проблемний драйвер за кілька хвилин.

Крок 1 — Увімкнення запису дампів пам'яті

Спочатку потрібно переконатися, що запис дампів включено. Для цього потрібно відкрити властивості системи, натиснувши комбінацію клавіш Win+Pause, [у Vista клацнути посилання Додаткові параметри системи], перейти на вкладку Додатковоі нарешті натиснути кнопку .

малихдампів пам'яті має бути достатньо для наших цілей.

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

Тепер ви можете запакувати файл до архіву, прикріпити його до повідомлення у форумі Усунення критичних помилок Windowsі почекати, поки вам хтось повідомить назву проблемного драйвера:) Але ви можете зробити це самостійно, не докладаючи великих зусиль.

Крок 2 - Аналіз дампів за допомогою утиліти MinDumper

Розповідь про утиліту ви знайдете у цій статті.

1. Завантажте та інсталюйте Debugging Tools for Windows. Вони входять до складу веб-установника Windows SDK, де після запуску потрібно вибрати Debugging Tools в розділі Common Utilities.
2. Завантажте сценарій(kdfe.cmd), який написав Олександр Суховей та опублікував на ресурсі sysadmins.ru(оскільки живе посилання мені там знайти не вдалося, пропоную своє). Розпакуйте архів у будь-яку папку.
   Примітка. У разі нестандартного розташування папки Program Files вам може знадобитися вказати в kdfe.cmd шлях до папки, в яку встановлені засоби Debugging Tools for Windows. Використовуйте змінну dbgpath у рядку 41.

Крок 3 - Аналіз дампа пам'яті

Наразі все зводиться до виконання однієї команди. Відкрийте командний рядокі перейдіть до папки, в яку ви розпакували kdfe.cmd. Запустіть файл, вказавши як параметр шлях до файлу дампа пам'яті (у прикладі нижче файл називається Mini1110307-01.dmp)

Або як його ще називають BSOD, може неабияк зіпсувати життя як комп'ютеру так і серверу, а ще з'ясувалося і віртуальній машині. Сьогодні розповім як аналізувати синій екран dump memory у Windows, тому що правильна діагностика та отримання причини через що не працює ваша система, 99 відсотків її вирішення, тим більше системний інженер, просто зобов'язаний вміти це робити, та й ще в найкоротші терміни, так Як від цього бізнес може внаслідок простою сервісу, втрачати купу грошей.

BSOD розшифровка

Давайте спочатку розберемо, що означає ця абревіатура, BSOD від англійської Blue Screen of Death або ще режим STOP помилки.

Помилки синього екранусмерті виникають з різних причин, серед яких можуть бути проблеми з драйверами, може бути якийсь збійний додаток, або збійний модуль оперативної пам'яті. Як тільки у вас з'явився синій екран у Windows, ваша система автоматично створить файл crash memory dump, який ми і будемо аналізувати.

Як налаштувати створення memory dump

за замовчуванням windowsпри синьому екрані створює аварійний дамп файл memory.dmp, зараз покажу як він налаштовується і де зберігається, я показуватиму на прикладі Windows Server 2008 R2, так як у мене нещодавно було завдання з вивчення питання синього екрану у віртуальній машині. Для того щоб дізнатися, де налаштований dump memory windows, відкриваємо пуск і клацаємо правим кліком по значку Комп'ютер і вибираємо властивості.

Як аналізувати синій екран dump memory в Windows-Властивості комп'ютера

Як аналізувати синій екран dump memory у Windows-параметри системи

Переходимо у вкладку Додатково Завантаження та відновлення. Тиснемо кнопку Параметри

Як аналізувати синій екран dump memory у Windows-Завантаження та відновлення

Де зберігається файл memory.dmp

і бачимо, що по-перше варто галка виконати автоматичне перезавантаженнядля запису налагоджувальної інформації, вибрано Дамп пам'яті ядра і нижче є нехай куди зберігається дамп пам'яті %SystemRoot%\MEMORY.DMP

Перейдемо до папки c:\windows\ і знайдемо файл MEMORY.DMP у ньому містяться коди синього екрана смерті

Як аналізувати синій екран dump memory у Windows-memory.dmp

Як налаштувати mini dump

У малий дамп пам'яті теж записуються помилки синього екрану смерті, він налаштовується там же, потрібно тільки його вибрати.

Зберігається він у папці c:\windows\minidump. Перевага в тому, що він займає менше місця і кожен синій екран створюється окремим файлом. Завжди можна переглянути історію появи синього екрана.

Тепер коли ми розібралися де шукати файл memory dump, потрібно навчитися його інтерпретувати і розуміти причину, через що відбувається синій екран смерті. У вирішенні цього завдання нам допоможе Microsoft Kernel Debugger. Завантажити Microsoft Kernel Debugger можна з офіційного сайту, головне виберіть потрібну версіюОС якщо комусь влом, то можете завантажити з яндекс диска за прямим посиланням. Також він входить до складу ADK.

Завантажуємо Microsoft Kernel Debugger, у результаті у вас буде маленький файл, який дозволить скачати з інтернету все, що вам потрібно. Запускаємо його.

приєднуватися до програми з покращення якості брати участь не будемо

тиснемо Accept і погоджуємося з ліцензією

Як встановити Microsoft Kernel Debugger - погоджуємося з ліцензією

почнеться встановлення Microsoft Kernel Debugger

Як встановити Microsoft Kernel Debugger-установка MKD

Бачимо, що Microsoft Kernel Debugger успішно встановлено

Після чого бачимо, що в пуску з'явилася папка Debugging Tools for Windows як для 32 так і 64 бітних систем.

Крім самого пакету Debugging Tools for Windows, також знадобиться набір символів налагодження - Debugging Symbols. Набір символів налагодження специфічний для кожної ОС, на якій був зафіксований BSoD. Тому доведеться завантажити набір символів для кожної ОС, аналізувати роботу якої Вам доведеться. Для 32-розрядної Windows XP знадобиться набір символів для Windows XP 32-біт, для 64-розрядної ОС знадобиться набір символів для Windows XP 64-біт. Для інших ОС сімейства Windowsнабори символів підбираються за таким же принципом. Завантажити символи налагодження можна звідси . Встановлювати їх рекомендується за адресою %systemroot%\symbolsхоча мені подобається встановлювати їх в окремі папки і не захаращувати папку Windows.

Аналіз синього екрану у Debugging Tools

Після установки Debugging Symbols під систему, на якій був синій екран смерті, запускаємо Debugging Tools

Як встановити Microsoft Kernel Debugger-Запуск

Перед аналізом вмісту дампа пам'яті потрібно провести невелике налаштування налагодження. Конкретно - повідомити програму, яким шляхом слід шукати налагоджувальні символи. Для цього вибираємо у меню File > Symbol File Path…

Натискаємо кнопку Browse…

і вказуємо папку, в яку ми встановили налагоджувальні символи для дампа пам'яті, що розглядається, можна вказати кілька папок через кому і можна запитувати інформацію про необхідні налагоджувальні символи прямо через Інтернет, з публічного сервера Microsoft. Таким чином у вас буде сама Нова версіясимволів. Зробити це можна так - в меню File > Symbol File Path… вводимо:

SRV*%systemroot%\symbols*http://msdl.microsoft.com/download/symbols

Як аналізувати синій екран смерті

Копіюємо з комп'ютера, де вискочив синій екран, файл memory.dmp або minidump, і відкриваємо його, вибираємо в меню File > Open Crash Dump… і вибираємо необхідний для розгляду файл.

Як аналізувати синій екран смерті-01

Вибираємо для прикладу minidump

Як аналізувати синій екран смерті-відкриваємо minidump

Почнеться аналіз мінідампа, бачимо з'явилося посилання на помилку, клацаємо по ній для більш детальної інформації про синій екран.

Як аналізувати синій екран смерті-03

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

Як аналізувати синій екран смерті-04

Отримайте більше детальну інформаціючерез синій екран.

Як аналізувати синій екран смерті-05

Якщо відкрити memory.dmp ви отримаєте подібну картину і бачимо чому синій екран у вас з'явився.

Як аналізувати синій екран смерті-06

Ось так просто діагностувати і усунути синій екран смерті.

Продовжу розповім про синій екран смерті, розпочатий у .

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

Справа в тому, що операційна система в момент збою зберігає вміст оперативної пам'яті в так званому дамп-файл(має розширення .dmp). Надалі файл дампа можна буде проаналізувати і отримати ту ж саму інформацію, що і на синьому екрані і навіть трохи більше.

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

Для цього потрібно зайти до розділу Система.

У Windows 10 це можна зробити через пошук, а в попередніх версіях операційної системичерез Панель управління.

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

Також тут відображається шлях до дамп - ми бачимо, що дамп зберігається в папку %SystemRoot% - це позначення папки Windows.

Також тут можна вибрати "малий дамп пам'яті", якого буде цілком достатньо для пошуку кодів помилки.

Отже, система вилетіла у синій екран смерті, після чого було створено дамп пам'яті.

Для аналізу дампів існують спеціальні програмиі однією з найпопулярніших є утиліта BlueScreenView.

Програма дуже проста у використанні і не потребує встановлення – завантажуємо з офіційного сайту та розархівуємо. При цьому з офіційного сайту можна завантажити файл, за допомогою якого можна русифікувати програму. Для цього даний файлнеобхідно буде помістити в папку з розархівованою програмою.

Якщо після запуску в програмі не відображаються дампи, хоча система зривалася в синій екран смерті, то варто зайти в налаштування програми і переконатися, що шлях до дамп пам'яті вказано правильно, тобто він повинен бути таким же, як і в налаштуваннях системи.

Після цього потрібно оновити інформацію у вікні програми, і всі створені в системі дампи відобразяться. Якщо дампів кілька, то орієнтуємося за датою збою. Вибираємо потрібний дамп, а потім з'явиться Детальна інформаціяпо ньому.

Тут виводиться назва помилки, її STOP-код із параметрами і якщо причиною став драйвер, то у відповідному полі ми виявимо його назву.

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

При цьому не обов'язково вручну вводити дані в пошукову систему. Якщо клацнути правою кнопкою миші рядком дампа, то з контекстного менюможна вибрати пункт, який дозволить знайти в Гуглі опис саме цієї проблеми.

Можна вибрати пошук у Google за кодом помилки, за кодом помилки та назвою драйвера або за кодом помилки та параметром.

Також за допомогою цієї утиліти можна швидко знайти місцезнаходження проблемного файлу на диску.

Іноді буває, що файл, що викликав проблему, належить до якоїсь програми або гри. За розташуванням файлу на диску можна швидко визначити, до якої саме програми або гри він відноситься.

Ну і варто знати, що чистильники начебто видаляють дампи пам'яті, тому якщо ви користуєтеся подібними програмами, то на час виявлення причини появи синього екрану смерті варто утриматися від їх використання.

І останнє питання, на яке я відповім у рамках цієї нотатки — що робити, якщо комп'ютер більше не запускається після появи синього екрана?Тобто комп'ютер зависає або постійно перевантажується, а отже, немає можливості проаналізувати дамп пам'яті.

Відповідь логічна і проста - потрібно створити завантажувальну флешку, за допомогою якої "витягнути" файл дампа з жорсткого диската проаналізувати його на іншому комп'ютері. Для цього завантажуємося з флешки та на жорсткому диску комп'ютера у папці Windowsабо в підпапці minidumpзнаходимо файл дампа, який копіюємо на флешку. Потім на іншому комп'ютері за допомогою утиліти BlueScreenViewаналізуємо дамп, як було розказано в цій статті.

В розділі аварійний дамп пам'яті визначається такими параметрами:

– REG_DWORD-параметр AutoRebootзі значенням 0x1(опція Виконати автоматичне перезавантаженнядопоміжного вікна вікна Властивості системи);

– REG_DWORD-параметр CrashDumpEnabledзі значенням 0x0якщо дамп пам'яті не створюється; 0x1 – Повний дамп пам'яті; 0x2 – Дамп пам'яті ядра; 0x3 – Малий дамп пам'яті (64КБ);

– REG_EXPAND_SZ-параметр DumpFileзі значенням %SystemRoot%\MEMORY.DMP(Місце зберігання файлу дампа);

– REG_DWORD-параметр LogEventзі значенням 0x1(опція Записати подію у журналвікна);

– REG_EXPAND_SZ-параметр MinidumpDirзі значенням %SystemRoot%\Minidump(Опція);

– REG_DWORD-параметр Overwriteзі значенням 0x1(опція Замінювати існуючий файлвікна);

– REG_DWORD-параметр SendAlertзі значенням 0x1(опція Надіслати адміністративне сповіщеннявікна).

Як система створює файл аварійної пам'яті

Під час завантаження операційна система перевіряє параметри створення аварійного у розділі реєстру . Якщо вказано хоча б один параметр, система генерує карту блоків диска, займаних на завантажувальному томі, і зберігає їх у пам'яті. Система також визначає, який дисковий пристрій керує завантажувальним томомобчислює контрольні суми для образу у пам'яті та структур даних, які мають бути цілими, щоб міг виконувати операції введення/виведення.

Після збою ядро ​​системи перевіряє цілісність карти сторінкового файлу, дискового та керуючих структур.. Якщо цілісність цих структур не порушена, то ядро ​​системи викликає спеціальні функції вводу/виводу дискового. призначені для збереження образу пам'яті після збою. Ці функції вводу/виводу самодостатні і не покладаються на служби ядра системи, оскільки в програмах, що відповідають за запис аварійного дампа, не можна робити жодних припущень про те, які частини ядра системи або пристроїв були пошкоджені. Ядро системи записує дані з пам'яті по карті секторів файлу підкачки (при цьому йому не доводиться використовуватифайлової системи).

Спочатку ядро ​​системи перевіряє стан кожного компонента, задіяного у процесі збереження дампа. Це робиться для того, щоб під час прямого запису в сектори диска не пошкодити дані, що лежать поза файлом. Розмір файлу має бути на 1 МБ більше розміру фізичної пам'яті, тому що при записі інформації в створюється заголовок, в якому містяться сигнатура аварійного та значення кількох найважливіших змінних ядра системи. Заголовок займає менше 1 МБ, але операційна система може збільшувати (або зменшувати) розмір файлу підкачки не менше ніж на 1 МБ.

Після завантаження системи Session Manager (Диспетчер сеансу Windows NT; дискова адреса – \WINDOWS\system32\smss.exe) ініціалізує файли системи, використовуючи для створення кожного файлу власну функцію NtCreatePagingFile. NtCreatePagingFileвизначає, чи існує файл, що ініціалізується, і якщо так, то є в ньому заголовок . Якщо заголовок є, то NtCreatePagingFileпосилає в Session Manager спеціальний код. Після цього Session Managerзапускає процес Winlogon (Програма входу до систему Windows NT; дискова адреса – \WINDOWS\system32\winlogon.exe), який повідомляється про існування аварійного . Winlogonзапускає програму SaveDump (Програма збереження копії пам'яті Windows NT; дискова адреса – \WINDOWS\system32\savedump.exe), яка аналізує заголовок та визначає подальші дії в аварійній ситуації.

Якщо заголовок свідчить про існування , то SaveDumpкопіює дані з файлу до аварійного файлу , ім'я якого задано REG_EXPAND_SZ-параметром DumpFileрозділу . Бувай SaveDumpпереписує файл , операційна система не задіяє ту частину сторінкового файлу, в якій міститься аварійний . В цей час обсяг віртуальної пам'яті, доступної для системи та додатків, зменшується на розмір (при цьому на екрані можуть з'явитися повідомлення, що вказують на нестачу віртуальної пам'яті). Потім SaveDumpінформує диспетчер пам'яті про завершення збереження , і той вивільняє ту частину файлу, в якому зберігається для загального користування.

Зберігши файл , програма SaveDumpробить запис про створення аварійного у журналі подій , наприклад: «Комп'ютер був перезавантажений після критичної помилки: 0x100000d1 (0xc84d90a6, 0x00000010, 0x00000000, 0xc84d90a6). Копію пам'яті збережено: C:\WINDOWS\Minidump\Mini060309-01.dmp» .

Повний дамп пам'ятізаписує весь вміст пам'яті при виникненні непереборної помилки. Для цього варіанта необхідно мати на завантажувальному томі файл підкачки, розмір якого дорівнює обсягу всієї фізичної оперативної пам'яті плюс 1 МБ. За замовчуванням повний пам'яті записується у файл %SystemRoot%\Memory.dmp. У разі виникнення нової помилкита створення нового файлу повногопам'яті (або пам'яті ядра) попередній файл замінюється (перезаписується). Параметр Повний дамп пам'ятінедоступний на , на яких встановлена ​​32-бітна операційна система та 2 або більше оперативної пам'яті.

У разі виникнення нової помилки та створення нового файлу повного пам'яті попередній файл замінюється.

Дамп пам'яті ядразаписує лише пам'ять ядра, завдяки чому процес запису даних до журналу при раптовій зупинці системи протікає швидше. Залежно від обсягу фізичної пам'ятіу цьому випадку для файлу підкачки потрібно від 50 до 800 МБабо третина фізичної пам'яті на завантажувальному томі. пам'яті ядра записується у файл %SystemRoot%\Memory.dmp.

Цей не включає нерозподілену пам'ять або пам'ять, виділену для програм режиму. Він включає тільки пам'ять, виділену для ядра та апаратно-залежного рівня ( HAL) у Windows 2000та пізніших версіях системи, а також пам'ять, виділену для режиму ядра та інших програм режиму ядра. У більшості випадків такий є найкращим варіантом. Він займає набагато менше місця порівняно з повним пам'яті, при цьому виключаючи лише ті сектори пам'яті, які, швидше за все, не пов'язані з помилкою.

У разі виникнення нової помилки та створення нового файлу пам'яті ядра попередній файл замінюється.

Малий дамп пам'ятізаписує найменший обсяг корисної інформації, необхідної визначення причини неполадок. Для створення малого пам'яті необхідно, щоб розмір файлу підкачки становив щонайменше 2 МБна завантажувальному томі.

Файли малого пам'яті містять такі відомості:

– повідомлення про непереборну помилку, її параметри та інші дані;

- Список завантажених;

- контекст ( PRCB), у якому стався збій;

EPROCESS) для процесу, що спричинив помилку;

– відомості про процес та контекст ядра ( ETHREAD) для потоку, що спричинив помилку;

– стек викликів у режимі ядра для потоку, що спричинив помилку.

Файл малого пам'яті використовується для обмеженого простору жорсткого диска. Однак через обмеженість відомостей, що містяться в ньому, в результаті аналізу цього файлу не завжди вдається виявити помилки, які не були безпосередньо викликані потоком, що виконувався в момент її виникнення.

При виникненні наступної помилки та створенні другого файлу малого пам'яті попередній файл зберігається. кожному додатковий файлдається унікальне ім'я. Дата закодована на ім'я файлу. Наприклад, Mini051509-01.dmp- це перший файл пам'яті, створений 15 травня 2009 р. Список всіх файлів малого пам'яті зберігається у папці %SystemRoot%\Minidump.

Операційна система , безсумнівно, значно надійніше за попередні версії, – завдяки зусиллям як розробників Microsoft, так і розробників апаратного , так і розробників прикладного програмного . Однак аварійні ситуації – усілякі збої та крахи системи – неминучі, і від того, чи володієзнаннями та навичками у їх усуненні, залежить, доведеться йому витратити кілька хвилин на пошук та усунення несправності (наприклад, на оновлення/налагодження або переустановку прикладної програми, що викликає збій), – або кілька годин на переустановку/налаштування операційної системи та прикладного програмного (що не гарантує відсутності збоїв та крахів надалі!).

Багато адміністраторів нехтують аналізом аварійних дампів Windows Вважаючи, що працювати з ними занадто важко. Важко, але можна: навіть якщо, наприклад, аналіз одного з десяти виявиться успішним, - зусилля, витрачені на освоєння найпростіших прийомів аварійних аналізу , будуть не марні!