У момент критичного збою операційна система Windows перериває роботу і показує синій екран смерті (BSOD). Вміст оперативної пам'яті і вся інформація про виниклу помилку записується в файл підкачки. При наступному завантаженні Windows створюється аварійний дамп c налагоджування на основі збережених даних. У системному журналі подій створюється запис про критичну помилку.
Увага! Аварійний дамп не створюється, якщо відмовила дискова підсистема або критична помилка з'явилася на початковій стадії завантаження Windows.зміст:
- Типи аварійних дампів пам'яті Windows
- Як включити створення дампа пам'яті в Windows?
- Установка WinDBG в Windows
- Налаштування асоціації .dmp файлів з WinDBG
- Налаштування сервера налагоджувальних символів в WinDBG
- Аналіз аварійного дампа пам'яті в WinDBG
Типи аварійних дампів пам'яті Windows
На прикладі актуальною операційної системи Windows 10 (Windows Server 2016) розглянемо основні типи дампов пам'яті, які може створювати система:
- Міні дамп пам'яті (Small memory dump) (256 КБ). Цей тип файлу включає мінімальний обсяг інформації. Він містить тільки повідомлення про помилку BSOD, інформацію про драйвери, процесах, які були активні в момент збою, а також який процес або потік ядра викликав збій.
- Дамп пам'яті ядра (Kernel memory dump). Як правило, невеликий за розміром - одна третина обсягу фізичної пам'яті. Дамп пам'яті ядра є більш докладним, ніж міні дамп. Він містить інформацію про драйвери і програмах в режимі ядра, включає пам'ять, виділену ядру Windows і апаратного рівнем абстракції (HAL), а також пам'ять, виділену драйверам та іншим програмам в режимі ядра.
- Повний дамп пам'яті (Complete memory dump). Найбільший за обсягом і вимагає пам'яті, рівний оперативної пам'яті вашої системи плюс 1MB, необхідний Windows для створення цього файлу.
- Автоматичний дамп пам'яті (Automatic memory dump). Відповідає дампи пам'яті ядра з точки зору інформації. Відрізняється лише тим, скільки місця він використовує для створення файлу дампа. Цей тип файлів не існував в Windows 7. Він був доданий в Windows 8.
- Активний дамп пам'яті (Active memory dump). Цей тип відсіває елементи, які не можуть визначити причину збою системи. Це було додано в Windows 10 і особливо корисно, якщо ви використовуєте віртуальну машину, або якщо ваша система є хостом Hyper-V.
Як включити створення дампа пам'яті в Windows?
За допомогою Win + Pause відкрийте вікно з параметрами системи, виберіть "Додаткові параметри системи"(Advanced system settings). У вкладці«додатково"(Advanced), розділ"Завантаження і відновлення"(Startup and Recovery) натисніть кнопку"параметри"(Settings). У вікні, налаштуйте дії при відмові системи. Поставте галку в чек-боксі"Записати події в системний журнал"(Write an event to the system log), виберіть тип дампа, який повинен створюватися при збої системи. Якщо в чек-боксі"Замінювати існуючий файл дампа"(Overwrite any existing file) поставити галку, то файл буде записуватись при кожному збої. Краще цю галку зняти, тоді у вас буде більше інформації для аналізу. Вимкніть також автоматичну перезавантаження системи (Automatically restart).
У більшості випадків для аналізу причини BSOD вам буде досить малого дампа пам'яті.
Тепер при виникненні BSOD ви зможете проаналізувати файл дампа і знайти причину збоїв. Міні дамп за замовчуванням зберігається в теці% systemroot% \ minidump. Для аналізу файлу дампа рекомендую скористатися програмою WinDBG (Microsoft Kernel Debugger).
Установка WinDBG в Windows
утиліта WinDBG входить до "Пакет SDK для Windows 10"(Windows 10 SDK). Завантажити можна тут.
файл називається winsdksetup.exe, розмір 1,3 МБ.
WinDBG для Windows7 і більш ранніх систем включений в склад пакета "Microsoft Windows SDK for Windows 7 and .NET Framework 4". Завантажити можна тут.Запустіть установку і виберіть, що саме потрібно зробити - встановити пакет на цей комп'ютер або завантажити для установки на інші комп'ютери. Встановимо пакет на локальний комп'ютер.
Можете встановити весь пакет, але для установки тільки інструменту налагодження виберіть Debugging Tools for Windows.
Після установки ярлики WinDBG можна знайти в стартовому меню.
Налаштування асоціації .dmp файлів з WinDBG
Для того, щоб відкривати файли дампов простим кліком, зіставте розширення .dmp з утилітою WinDBG.
- Відкрийте командний рядок від імені адміністратора і виконайте команди для 64-розрядної системи:
cd C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x64
windbg.exe -IA
для 32-розрядної системи:C: \ Program Files (x86) \ Windows Kits \ 10 \ Debuggers \ x86
windbg.exe -IA - В результаті типи файлів: .DMP, .HDMP, .MDMP, .KDMP, .WEW - будуть співставлені з WinDBG.
Налаштування сервера налагоджувальних символів в WinDBG
Налагодження символи (debug-символи або symbol files) - це блокиданих, які генеруються в процесі компіляції програми спільно з виконуваним файлом. У таких блоках даних міститься інформація про імена змінних, що викликаються функціях, бібліотеках і т.д. Ці дані не потрібні при виконанні програми, але корисні при її налагодженні. Компоненти Microsoft компілюються з символами, що розповсюджуються через Microsoft Symbol Server.
Налаштуйте WinDBG на використання Microsoft Symbol Server:
- Відкрийте WinDBG;
- Перейдіть в меню File -> Symbol File Path;
- Пропишіть рядок, що містить URL для завантаження символів налагодження із сайту Microsoft і каталог, де зберігати кеш:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbolsУ прикладі кеш завантажується в папку E: \ Sym_WinDBG, можете вказати будь-яку. - Не забувайте зберегти зміни в меню File -> Save WorkSpace;
WinDBG зробить пошук символів в локальній папці і, якщо не виявить в ній необхідних символів, то самостійно завантажить символи з вказаного сайту. Якщо ви хочете додати власну папку з символами, то можна зробити це так:
SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols; c: \ Symbols
Якщо підключення до інтернету відсутня, то завантажте попередньо пакет символів з ресурсу Windows Symbol Packages.
Аналіз аварійного дампа пам'яті в WinDBG
Отладчик WinDBG відкриває файл дампа і завантажує необхідні символи для налагодження з локальної папки або з інтернету. Під час цього процесу ви не можете використовувати WinDBG. Внизу вікна (в командному рядку налагоджувача) з'являється напис Debugee not connected.
Команди вводяться в командний рядок, розташовану внизу вікна.
Найголовніше, на що потрібно звернути увагу - це код помилки, який завжди вказується в шістнадцятковому значенні і має вигляд 0xXXXXXXXX (Вказуються в одному з варіантів - STOP: 0x0000007B, 02.07.2019 0008F, 0x8F). У нашому прикладі код помилки 0х139.
Повний довідник помилок можна подивитися тут.Отладчик пропонує виконати команду! Analyze -v, достатньо навести курсор миші на посилання і клікнути. Для чого потрібна ця команда?
- Вона виконує попередній аналіз дампа пам'яті і надає докладну інформацію для початку аналізу.
- У цю команду відобразить STOP-код і символічне ім'я помилки.
- Вона показує стек викликів команд, які привели до аварійного завершення.
- Крім того, тут відображаються несправності IP-адреси, процесів і регістрів.
- Команда може надати готові рекомендації щодо вирішення проблеми.
Основні моменти, на які ви повинні звернути увагу при аналізі після виконання команди! Analyze -v (лістинг неповний).
1: kd> !analyze -v
************************************************** ***************************
* *
* Bugcheck Analysis *
* *
************************************************** ***************************
Символічне ім'я STOP-помилки (BugCheck)KERNEL_SECURITY_CHECK_FAILURE (139)
Опис помилки (Компонент ядра пошкодив критичну структуру даних. Це пошкодження потенційно може дозволити зловмиснику отримати контроль над цією машиною):
A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine.
Аргументи помилки:
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffd0003a20d5d0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd0003a20d528, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved
Debugging Details:
------------------
Лічильник показує скільки раз система впала з аналогічною помилкою:
CUSTOMER_CRASH_COUNT: 1
Основна категорія поточного збою:
DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY
Код STOP-помилки в скороченому форматі:
BUGCHECK_STR: 0x139
Процес, під час виконання якого стався збій (не обов'язково причина помилки, просто в момент збою в пам'яті виконувався цей процес):
PROCESS_NAME: sqlservr.exe
CURRENT_IRQL: 2
Розшифровка коду помилки: В цьому додатку система виявила переповнення буфера стека, що може дозволити зловмиснику отримати контроль над цим додатком.
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.
Останній виклик в стеці:
LAST_CONTROL_TRANSFER: from fffff8040117d6a9 to fffff8040116b0a0
Стек викликів в момент збою:
STACK_TEXT:
ffffd000'3a20d2a8 fffff804'0117d6a9: 00000000'00000139 00000000'00000003 ffffd000'3a20d5d0 ffffd000'3a20d528: nt! KeBugCheckEx
ffffd000'3a20d2b0 fffff804'0117da50: ffffe000'f3ab9080 ffffe000'fc37e001 ffffd000'3a20d5d0 fffff804'0116e2a2: nt! KiBugCheckDispatch + 0x69
ffffd000'3a20d3f0 fffff804'0117c150: 00000000'00000000 00000000'00000000 00000000'00000000 00000000'00000000: nt! KiFastFailDispatch + 0xd0
ffffd000'3a20d5d0 fffff804'01199482: ffffc000'701ba270 ffffc000'00000001 000000ea'73f68040 fffff804'000006f9: nt! KiRaiseSecurityCheckFailure + 0x3d0
ffffd000'3a20d760 fffff804'014a455d: 00000000'00000001 ffffd000'3a20d941 ffffe000'fcacb000 ffffd000'3a20d951: nt! ?? :: FNODOBFM :: 'string' + 0x17252
ffffd000'3a20d8c0 fffff804'013a34ac: 00000000'00000004 00000000'00000000 ffffd000'3a20d9d8 ffffe001'0a34c600: nt! IopSynchronousServiceTail + 0x379
ffffd000'3a20d990 fffff804'0117d313: ffffffff'fffffffe 00000000'00000000 00000000'00000000 000000eb'a0cf1380: nt! NtWriteFile + 0x694
ffffd000'3a20da90 00007ffb'475307da: 00000000'00000000 00000000'00000000 00000000'00000000 00000000'00000000: nt! KiSystemServiceCopyEnd + 0x13
000000ee'f25ed2b8 00000000'00000000: 00000000'00000000 00000000'00000000 00000000'00000000 00000000'00000000: 0x00007ffb'475307da
Ділянка коду, де виникла помилка:
FOLLOWUP_IP:
nt! KiFastFailDispatch + d0
fffff804'0117da50 c644242000 mov byte ptr [rsp + 20h], 0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt! KiFastFailDispatch + d0
FOLLOWUP_NAME: MachineOwner
Ім'я модуля в таблиці об'єктів ядра. Якщо аналізатору вдалося виявити проблемний драйвер, ім'я відображається в полях MODULE_NAME і IMAGE_NAME:
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
Якщо клацніть по посиланню модуля (nt), то побачите детальну інформацію про шляхи і інших властивостях модуля. Знаходьте вказаний файл, і вивчаєте його властивості.
1: kd> lmvm ntBrowse full module list
Loaded symbol image file: ntkrnlmp.exe
Mapped memory image file: C: \ ProgramData \ dbg \ sym \ ntoskrnl.exe \ 5A9A2147787000 \ ntoskrnl.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
OriginalFilename: ntkrnlmp.exe
ProductVersion: 6.3.9600.18946
FileVersion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)
У наведеному прикладі аналіз вказав на файл ядра ntkrnlmp.exe. Коли аналіз дампа пам'яті вказує на системний драйвер (наприклад, win32k.sys) або файл ядра (як в нашому прикладі ntkrnlmp.exe), найімовірніше даний файл не є причиною проблеми. Дуже часто виявляється, що проблема криється в драйвері пристрою, настройках BIOS або в несправності обладнання.
Якщо ви побачили, що BSOD виник через стороннього драйвера, його ім'я буде вказано в значеннях MODULE_NAME і IMAGE_NAME.
наприклад:
Image path: \ SystemRoot \ system32 \ drivers \ cmudaxp.sys
Image name: cmudaxp.sys
Відкрийте свойсва файлу драйвера і перевірте його версію. У більшості випадків проблема з драйверами вирішується їх обнвовленіем.
