Раньше я не знал, что такое сабж и не умел его использовать. Теперь немного узнал и впечатлён. Расскажу про свой опыт общения с ним, может кому-то будет полезно.
Эти тулзы содержат мощные отладчики (WinDbg, Cdb) и позволяют делать всякие полезности, типа создания symservers (symstore.exe), создания дампа с процесса (cdb, windbg), отладки мемори ликов (umdh.exe) и других ошибок работы с памятью (gflags — позволяет включать многие «скрытые» системные проверки как для конкретного exe файла, так и для всей системы в целом). Также в комплекте есть много других полезных тулзов, типа просмотрщика 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..., открываешь дамп, пишешь !analyze -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)
Эти тулзы содержат мощные отладчики (WinDbg, Cdb) и позволяют делать всякие полезности, типа создания symservers (symstore.exe), создания дампа с процесса (cdb, windbg), отладки мемори ликов (umdh.exe) и других ошибок работы с памятью (gflags — позволяет включать многие «скрытые» системные проверки как для конкретного exe файла, так и для всей системы в целом). Также в комплекте есть много других полезных тулзов, типа просмотрщика 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..., открываешь дамп, пишешь !analyze -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)
