Раніше я не знав, що таке сабж і не вмів його використовувати. Тепер трохи дізнався і вражений. Розповім про свій досвід спілкування з ним, може комусь буде корисно.
Ці тулзи містять потужні зневадники (WinDbg, Cdb) і дозволяють робити всякі корисності, типу створення symservers (symstore.exe), створення дампа з процесу (cdb, windbg), зневадження меморі ліків (umdh.exe) та інших помилок роботи з пам'яттю (gflags - дозволяє включати багато «прихованих перевірок» як для всієї системи. Також у комплекті є багато інших корисних тулзів, типу переглядача debug output.
Взяти можна тут:Майкросайт
Наприклад, як отримати меморі лики для будь-якої програми:
Нам знадобиться umdh.exe, tlist.exe і gflags.exe. Всі їх треба запускати з адмінськими правами.
Запускаємо gflags.exe, виставляємо галочку Create user mode stack database. Перезавантажуємося - тепер для всіх запущених програм буде створюватися цей database. Можна окремо налаштувати для кожної програми.
Далі запускаємо потрібну програму, чекаємо, поки все завантажиться і отримуємо PID програми за допомогою tlist.exe (або як завгодно ще). Наприклад, PID = = 111.
Далі запускаємо umdh.exe -p:111 -f:c:\temp\log1.log
Цей рядок збереже в файл log1.log інфу про всі поточні виділення пам'яті в процесі 111.
Далі працюємо в програмі, чекаємо скільки-небудь часу і знову пишемо:
umdh.exe -p:111 -f:c:\temp\log2.log
Отримуємо другий лог з виділеннями пам'яті.
Тепер їх можна порівняти і отримати лики:
umdh.exe -d -v -l c:\temp\log1.log c:\temp\log2.log 1> c:\temp\log_result.log
Тепер у нас в log_result.log будуть всі виділені і не звільнені шматки пам'яті з калстеками!
Щоб калстеки були правильні, потрібно налаштувати enviroment variable _NT_SYMBOL_PATH. У хелпі написано, як його налаштувати для майкрософтівських exe і dll.
Свої pdb найкраще зберігати на symbol server, який можна поповнювати після білдів за допомогою symstore.exe - тоді завжди налагоджувач матиме правильний pdb.
Якщо сервера немає, можна просто покласти pdb поруч з єхе - повинен підчепитися. Якщо не підчепиться, додати шлях до pdb у _NT_SYMBOL_PATH.
Якщо у вас є дамп файл і треба його перевірити, то знову ж найпростіше використовувати WinDbg. Він використовує ту ж змінну _NT_SYMBOL_PATH і, на відміну від VisualStudio, він не вимагає ні вихідців ні правильних бінарників для налагодження. Просто дамп і відповідний pdb! Запускаєш WinDbg.exe, File\open crash dump..., відкриваєш дамп, пишеш! - v, потім! uniqstack і вже зазвичай цього достатньо в простих випадках. Бачиш, які pdb знайшлися, які немає і отримуєш аналіз дампа. Можна відкрити віконця з callstack, Processes and threads і налагоджуватися. Якщо треба побачити код - File\Source File Path... - вказати шлях до вихідців і можна дивитися місце в коді, де що сталося (краще відразу ці шляхи прописати в enviroment variable _NT_SOURCE_PATH, щоб не вбивати їх кожен раз). Коротше, знову все просто і зручно, якщо є правильний pdb:)
Проблеми з зависаннями чогось відмінно вирішуються за допомогою створення дампа зависшого процесу. Для цього можна використовувати той же WinDbg або спеціальні проги або стандартну системну фічу в вісті в таск менеджері - створити дамп:)
Причому DebuggingTools можна встановити вже після зависання - ніякого перезавантаження не треба. Встановив - зняв дамп. Для зняття дампа юзеру не треба ніяких pdb.
Потім цей дамп аналізуєш і виправляєш (у Windbg є спеціальні команди для пошуку дедлоків тощо - команда! locks та інші).
Вивід:
Щоб не мати проблем з налагодженням, треба перейматися системою зберігання pdb файлів для КОЖНОГО білда ну або хоча б для офіційних білдів. А також вивчити Debugging tools і написати прості рекоммендації тестерам і програмістам - що робити в разі помилки або зависання, як створювати дамп, куди його класти і з якими коментарями. А деякі тестери навіть можуть запускати WinDBG і копіпастити у звіт про бага звідти потрібні дані типу калстека з помилкою - дуже допомагає в попередньому аналізі.
На додаток пара корисних посилань для початківців про WinDBG:
WinDbg. From A to Z!
Common WinDbg Commands (Thematically Grouped)
