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

У момент критичного збою операційна система 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 може потенційно дозволити малий користувач для забезпечення контролю цього застосування.

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

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.

Для виявлення причин виникнення синіх екранів (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.

Debugging Tools for Windows- Інструменти налагодження коду операційних систем Windows. Є набір програм, що вільно розповсюджуються від Microsoft, призначених для налагодження коду користувальницького режиму і режиму ядра: додатків, драйверів, служб, модулів ядра. До складу інструментарію входять відладчики консольного та GUI-режимів, утиліти для роботи з символами, файлами, процесами, утиліти для забезпечення віддаленого налагодження. Інструментарій містить утиліти, за допомогою яких можна знаходити причини збоїв у різних компонентах системи. Debugging Tools for Windowsз певного моменту недоступні для завантаження у формі автономного дистрибутива і входять до складу Windows SDK (Windows Software Development Kit). Набір інструментальних засобів Windows SDK, у свою чергу, доступний у вигляді частини програми підписки MSDN або може бути вільно завантажений в якості окремого дистрибутива з сайту msdn.microsoft.com. За заявою розробників, остання та найактуальніша версія Debugging Tools for Windows міститься саме у Windows SDK.

Debugging Tools for Windows оновлюються і викладаються в публічний доступ досить часто і процес ніяк не залежить від випуску операційних систем. Тому періодично перевіряйте наявність нових версій.

Давайте тепер подивимося, що, зокрема, дозволяють нам кошти Debugging Tools for Microsoft Windows:

• Налагоджувати локальні програми, служби (сервіси), драйвера та ядро;
• Налагоджувати по мережі віддалені програми, служби (сервіси), драйвера та ядро;
• Налагоджувати працюючі програми у режимі реального часу;
• Аналізувати файли дампів пам'яті додатків, ядра та системи в цілому;
• Працювати із системами на базі архітектур x86/x64/Itanium;
• Налагоджувати програми користувальницького режиму та режиму ядра;

Доступні такі версії Windows Debugging Tools: 32-bit x86, Intel Itanium, 64-bit x64. Нам будуть потрібні дві з них: x86 або x64.

Доступні кілька способів встановлення Debugging Tools for Windows, у цій статті ми будемо розглядати лише основні з них:

• Установка за допомогою web-інсталятора.
• Встановлення Debugging Tools for Windows з ISO-образу Windows SDK.
• Інсталяція Debugging Tools for Windows безпосередньо з пакетів dbg_amd64.msi /dbg_x86.msi .

Залишається неясний ще коли, навіщо мені встановлювати налагоджувальний інструментарій на комп'ютер? Адже найчастіше стикаєшся з ситуацією, коли втручання в робоче середовище вкрай небажане! І тим більше, що інсталяція нового продукту, тобто внесення змін до реєстру/файлу системи, може бути абсолютно неприпустима. Прикладами можуть бути критично-важливі сервера. Чому б розробникам не продумати варіант із портабельними (portable) версіями додатків, що не потребують встановлення?
Від версії до версії процес інсталяції пакета Debugging Tools for Windows зазнає деяких змін. Давайте тепер перейдемо безпосередньо до процесу встановлення та розглянемо способи, якими можна встановити інструментарій.

Встановлення Debugging Tools for Windows за допомогою web-інсталятора

Переходимо на сторінку Архів Windows SDK і знаходимо розділ під назвою Windows 10 та нижче пункт "Windows 10 SDK (10586) та емулятор пристрою з Windows 10 Mobile (Майкрософт) (версія 10586.11)".

Клацаємо по пункту ВСТАНОВИТИ ПАКЕТ SDK. Після клацання завантажуємо та запускаємо файл sdksetup.exe, який і ініціює процес онлайн-налаштування Windows SDK. На початковому етапі інсталятор перевірить наявність у системі інстальованого пакета.NET Framework останньої версії (в даний момент це 4.5). Якщо пакет відсутній, буде запропоновано установку та по закінченні виконано перезавантаження станції. Відразу після перезавантаження, на етапі авторизації користувача, стартує процес інсталяції безпосередньо Windows SDK.

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

Після завершення інсталяції Debugging Tools for Windows розташування файлів налагодження при даному методі інсталяції у нас буде наступним:

• 64-бітові версії: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
• 32-бітові версії: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86

* де x.x – певна версія комплекту розробки;
Помітили, що версії 8 і вище шляхи інсталяції помітно відрізняються від класичних для всіх попередніх версій засобів налагодження?

Величезним плюсом цього способу установки Debigging Tools for Windows є встановлення версій налагоджувальних засобів одночасно всіх архітектур.

Встановлення Windows Debugging Tools з ISO-образу Windows SDK

Цей метод передбачає встановлення Debugging Tools for Windows з використанням повного інсталяційного образу Windows SDK (Software Developers Kit). До певного часу скачати образ ISO для відповідної системи можна було на сторінці Архів Windows SDK . Однак, в даний момент отримати ISO-образ SDK можна через запуск web-інсталятора sdksetup.exe і вибору пункту Download the Windows Software Development Kitу стартовому вікні інсталятора:

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

Відповідно, на сторінці необхідно підібрати необхідний дистрибутив, для мене (та й думаю для багатьох) в даний момент це "Пакет Windows SDK для Windows 7 та .NET Framework 4" і трохи нижче натиснути на посилання "Отримати ISO-образ DVD-диска" .

Працюючи з сайтом msdn.microsoft.com раджу скористатися браузером Internet Explorer, оскільки були помічені випадки непрацездатності конкуруючих продуктів!

Відповідно, необхідно вибрати виключно за потребою. Зазвичай, розрядність Debugging Tools for Windows збігається з розрядністю системи. У мене досліджувані системи в основному 64-бітові, тому я в більшості випадків завантажую образ для 64-бітної системи GRMSDKX_EN_DVD.iso .
Потім, після завантаження образу, нам необхідно з наявним ISO-образом якось працювати. Традиційним способом є, звичайно ж, запис компакт-диска, але це досить довгий і іноді витратний метод. Пропоную скористатися безкоштовними утилітами для створення в системі віртуальних дискових пристроїв. Особисто я для цієї мети волію користуватися програмою DEAMON Tools Lite. У когось можуть бути й інші уподобання, більш прямі або легковажні утиліти, на смак і колір, як кажуть. компакт диск:

Вже потім подвійним клацанням активую автозавантаження і запускаю інсталяцію Windows SDK:

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

Все саме так, на скріншоті зазначено дві опції: "Windows Performance Toolkit" та "Debugging Tools for Windows". Вибирайте обидві, тому що Windows Performance Toolkit Вам неодмінно стане в нагоді в роботі! Далі, після натискання кнопки "Next" інсталяція продовжується у звичайному режимі. І наприкінці ви побачите напис "Installation Complete".
Після закінчення інсталяції робочі директорії комплекту Debugging Tools for Windows будуть такими:

• Для версії x86:
• Для версії x64:

На цьому установку Debugging Tools for Windows можна вважати завершеною.

Установка Debugging Tools for Windows через .msi файл

У разі виникнення проблем при інсталяції Debugging Tools for Windows двома попередніми способами, у нас в запасі залишається ще один, найнадійніший і перевірений часом, що виручав, так би мовити, неодноразово. Колись, до інтеграції в Windows SDK, Debugging Tools for Windows були доступні у вигляді окремого інсталятора. Оскільки у нас на руках є вже ISO-образ Windows SDK, то ми можемо не монтувати його в систему, а просто відкрити за допомогою всім добре знайомого архіватора WinRAR, ну або будь-якого іншого продукту, що працює з вмістом ISO-дисків.

Після відкриття образу нам необхідно пройти до каталогу "Setup", що знаходиться в корені і далі вибрати одну з директорій:

• Для встановлення 64-бітної версії: \Setup\WinSDKDebuggingTools_amd64і розпакувати з цього каталогу файл dbg_amd64.msi.
• Для встановлення 32-бітної версії: \Setup\WinSDKDebuggingTools і розпакувати з цього каталогу файл dbg_x86.msi .

Після закінчення інсталяції робочі директорії комплекту Debugging Tools for Windows будуть такими:

• Для версії x86: C:\Program Files (x86)\Debugging Tools для Windows (x86)
• Для версії x64: C:\Program Files\Debugging Tools для Windows (x64)

На цьому установку Debugging Tools for Windows можна вважати виконаною.

додаткові відомості

Не знаю з чим це пов'язано, можливо з моєю неуважністю, але після інсталяції Відлагоджувальних засобів для Windows, інсталятор не прописує в системну змінну шляху Path шлях до каталогу з відладчиком. Це накладає певні обмеження на запуск різних завдань налагодження безпосередньо з консолі. Тому, у разі відсутності шляху, я самостійно прописую у вікні Змінні середовищашлях до налагоджувальних засобів:

• C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
• C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

* У вашому випадку шляхи можуть відрізнятися як через використання ОС іншої розрядності, так і через використання SDK іншої версії.

Утиліти пакету Debugging Tools for Windows можуть працювати як переносні програми, досить просто скопіювати з робочої системи каталог Microsoft Windows Performance Toolkitі використовувати його як портабельну версію на робочому сервері. Але не забувайте враховувати розрядність системи! Якщо Ви навіть здійснили повну інсталяцію пакета на критично важливу систему, то працювати можна починати прямо після інсталяції, перезавантаження не потрібно.

Склад Debugging Tools for Windows

І тепер наостанок наведемо склад Debugging Tools for Windows: