Debugging tools для windows використання. Установка Debugging Tools for Windows

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

Крок 1 - Налаштування запису малих дампів пам'яті

Крок 2 - Встановлення WinDBG

Для аналізу дампів пам'яті вам знадобиться встановити відладчик WinDBG, який входить до складу пакета Windows SDK. На момент написання статті останні доступні версії Windows SDK:

  • Пакет SDK для Windows 10 (завантажити мережевий інсталятор)
  • Пакет SDK для Windows 8.1 (завантажити мережевий інсталятор)

Крок 3 - Зіставлення файлів.dmp з WinDBG

Для спрощення процедури читання та аналізу дампів пам'яті виконайте зіставлення файлів.dmp з WinDBG. Це дозволить відкривати файли дампів з провідника одразу у WinDBG минаючи його попередній запуск.


Крок 4 - Налаштування сервера символів для отримання файлів символів налагодження


Установка та первинне налаштування WinDBG завершено. Для того, щоб змінити його зовнішній виглядможете перейти до меню View- налаштування шрифтів ви знайдете вибравши пункт Font, а налаштування вікон консолей в Options.

Такі типи збоїв зазвичай пов'язані зі збійним драйвером, який важко обчислити. Проте, покращена система відстеження помилок у Windows Vista (і не лише у Vista!) нерідко може призвести до проблемного файлу. Внаслідок чого більшість людей перестає судомно намагатися працювати на нестабільному комп'ютері, з параноїдальною регулярністю зберігаючи документи та сподіваючись на краще.

При збоях Windows зазвичай створюється так званий дамп пам'яті. Останній можна дослідити за допомогою безкоштовного налагоджувального інструмента Windows Debugging Tools, які можуть направити вас на джерело проблеми. Тому все, що вам необхідно зробити, це:

Завантажити собі налагоджувальний інструмент

Завантажити Windows Debugging Tools можна безпосередньо із сайту Microsoft. Програма працює з багатьма операційними системами, починаючи з Windows NT 4 і закінчуючи Windows 2008, тому проблем з нею у вас виникнути не повинно. Так, не можна сказати, що вона стабільна під Windows 7 RC, проте за нашими тестами таки працює. Тому навіть спроба діагностування проблеми під Windows 7 RC може виявитися вдалою.

Налаштувати свою систему

Необхідно, щоб під час збоїв ваш комп'ютер створював дампи пам'яті, які надалі будуть джерелом інформації для відладчика. Тому важливо, щоб Windows була налаштована на створення дампів. Щоб налаштувати свою операційну систему, клацніть правою кнопкоюмиші на своєму комп'ютері (Computer) і виберіть Властивості (Properties). Потім натисніть на вкладці додаткових параметрів Додатково (Advanced System Settings), на ній знайдіть підрозділ Завантаження та Відновлення системи (Startup and Recovery Settings) і переконайтеся, що параметр Запис налагоджувальної інформації (Write debugging information) встановлений у стан Дамп пам'яті ядра (Kernel memory dump) ) або Повний дамп пам'яті (Complete memory dump).

Далі клацніть Пуск (Start), перейдіть до Програми (All Programs), виберіть Debugging Tools і запустіть WinDbg. У програмі пройдіть в меню File і виберіть Symbol File Path… Потім напишіть у вікні, що відкрилося. наступний рядок:

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

Остання визначає шлях до спеціальних даних - так званих символів (symbols), які можуть допомогти налагоджувальному інструменту в упізнанні вашого збійного файлу.

Після введення рядка, натисніть на кнопку OK. Згодом під час роботи з відладчиком цей рядок викличе завантаження символів з msdl.microsoft.com та збереження їх у папку c:\symbols.

Вирішити свою проблему

Тепер почекайте чергового збою з синім екраном, а потім перезавантаження комп'ютера. Потім ще раз запустіть WinDbg (користувачам Vista необхідно запускати програму від імені адміністратора), натисніть меню File, виберіть відкриття збійного дампа Open Crash Dump, відкрийте файл \Windows\MEMORY.DMP, і програма негайно почне його аналізувати.

На жаль, WinDbg надає дуже мало інформації про те, що вона робить, тому ви навіть можете подумати, що програма зависла. Однак зачекайте. Зрозумійте, аналіз, скажімо, 4GB пам'яті на не дуже потужному комп'ютеріможе зайняти деякий час, аж до годинника. Тому наберіться терпіння, а краще залиште аналіз на ніч.

Втім, зазвичай результат виходить уже за кілька хвилин. Про це свідчить рядок аналізатора помилки Bugcheck Analysis, що повідомляє щось на кшталт "Probably caused by: UACReplace.sys". У перекладі українською це означає, що проблема, можливо, викликана файлом UACReplace.sys. Введіть його в рядок пошуку, наприклад Google і ви дізнаєтесь його реальне походження. Зокрема, якщо він належить до однієї із встановлених вами програм або встановленому драйверуВи можете просто спробувати оновити її або його. Можливо, це вирішить проблеми, що виникли у вас.

Іноді WinDbg не може назвати імені файлу зовсім або просто вибирає одну з DLL-бібліотек Windows. Якщо це сталося і у вас, просто клікніть по командному вікну над панеллю статусу і наберіть команду:

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

Якщо ж і цього разу вам не пощастить, не засмучуйтесь. Налагодження є досить складною справою навіть експертів. Тому просто закрийте WinDbg та запустіть аналізатор знову після наступного збою. Можливо, це дасть вам декілька більше інформації. Успіхів!

on June 22, 2010

Спершу Windbg був доступний окремо до download. Але для останньої версії, Microsoft keeps it є частиною Windows SDK. Please find the download links below.

Windows 10

Найновіша версія Windbg для Windows 7 може бути зареєстрована з посиланням https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk

Windows 7

Download installers з вище links. Note that this does not download the whole SDK, it's just an installer. Once you run the file, you can select which tools you would like to be downloaded. If You areзацікавлені тільки в Windbg, ви можете виключити все, що вміє і тільки select 'Debugging tools' under 'Common Utilities'

Докладніше package installs windbg 6.12 version. Якщо ви збираєтеся налаштувати windbg, ви можете скористатися останньою версією(6.11) which can be downloaded from
link given at the end of this post.

Після того, як ви встановите, ви можете пройти програму в Start Menu -> All Programs -> Debugging Tools for Windows -> Windbg

У момент критичного збою операційна система Windows перериває роботу та показує синій екран смерті (BSOD). Вміст оперативної пам'ятіі вся інформація про помилку записується у файл підкачки. За наступної завантаженні Windowsстворюється аварійний дамп з налагоджувальною інформацією на основі збережених даних. У системному журналі подій створюється запис про критичну помилку.

Увага!Аварійний дамп не створюється, якщо відмовила дискова підсистема або критична помилкавиникла на початковій стадії завантаження Windows.

Типи аварійних дампів пам'яті 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 МБ.

Запустіть інсталяцію та виберіть, що саме потрібно зробити – встановити пакет на цей комп'ютер або завантажити для інсталяції на інші комп'ютери. Встановимо пакет на локальний комп'ютер.

Ви можете встановити весь пакет, але для встановлення лише інструмента налагодження виберіть Debugging Tools for Windows.

Після встановлення ярлики WinDBG можна знайти у стартовому меню.

Налаштування асоціації.dmp файлів з WinDBG

Щоб відкрити файли дампів простим кліком, зіставте розширення.dmp з утилітою WinDBG.

  1. Відкрийте командний рядоквід імені адміністратора та виконайте команди для 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
  2. У результаті типи файлів: .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 не підключений.

Команди вводяться у командний рядок, розташовану внизу вікна.

Найголовніше, на що потрібно звернути увагу - це код помилки, який завжди вказується в шістнадцяткове значенняі має вигляд 0xXXXXXXXX(Вказуються в одному з варіантів - STOP: , 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. Корумпування може потенційно дозволити малий користувачі, щоб керувати цим машиною.
Аргументи помилки:

Arguments:
Arg1: 0000000000000003, LIST_ENTRY має бути корумпований (і.е. double remove).
Arg2: ffffd0003a20d5d0, address of trap frame for exception that caused bugcheck
Arg3: ffffd0003a20d528, address of exception record for exception that caused 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

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

ERROR_CODE: (NTSTATUS) 0xc0000409 - Систему виявлено нескінченну версію резервуарного buffer в цій заявці. Цей overrun може потенційно дозволити malicious user до gain control of this application.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Систему виявлено нескінченну версію резервуару в цьому application. Цей overrun може потенційно дозволити malicious user до gain control of this application.

Останній виклик у стеку:

LAST_CONTROL_TRANSFER: від fffff8040117d6a9 to fffff8040116b0a0

Стек викликів у момент збою:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a2d!
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt!
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: ff
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d95: ?? ::FNODOBFM::`string”+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c60
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1306: 0
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 000000000000000000
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000000000 307da

Ділянка коду, де виникла помилка:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr ,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

1: kd> lmvm nt
Browse 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

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

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

Крок 1 - Налаштування запису малих дампів пам'яті

Крок 2 - Встановлення WinDBG

Для аналізу дампів пам'яті вам доведеться встановити відладчик WinDBG, який входить до складу пакета Windows SDK. На момент написання статті останні доступні версії Windows SDK:

  • Пакет SDK для Windows 10 (завантажити мережевий інсталятор)
  • Пакет SDK для Windows 8.1 (завантажити мережевий інсталятор)

Крок 3 - Зіставлення файлів.dmp з WinDBG

Для спрощення процедури читання та аналізу дампів пам'яті виконайте зіставлення файлів.dmp з WinDBG. Це дозволить відкривати файли дампів з провідника одразу у WinDBG минаючи його попередній запуск.


Крок 4 - Налаштування сервера символів для отримання файлів символів налагодження


Установка та первинне налаштування WinDBG завершено. Для того, щоб змінити його зовнішній вигляд, можете перейти в меню View- налаштування шрифтів ви знайдете вибравши пункт Font, а налаштування вікон консолей в Options.