Раньше я не знал, что такое предмет и не умел им пользоваться.
Теперь я знаю немного и впечатлен.
Расскажу о своем опыте общения с ним, может кому-то будет полезно.
Эти инструменты содержат мощные отладчики (WinDbg, Cdb) и позволяют делать всевозможные полезные вещи, такие как создание symservers (symstore.exe), создание дампа процесса (cdb,windbg), отладка образов памяти (umdh.exe).
) и другие ошибки памяти (gflags — позволяет включить множество «скрытых» проверок системы как для конкретного exe-файла, так и для всей системы в целом).
Также включено множество других полезных инструментов, таких как средство просмотра отладочной информации.
Вы можете получить его здесь: микросайт Например, как получить образы памяти для любой программы: Нам понадобятся umdh.exe, tlist.exe и gflags.exe. Все они должны быть запущены с правами администратора.
Запустите gflags.exe и установите флажок «Создать базу данных стека пользовательского режима».
Перезагружаемся – теперь эта база данных будет создана для всех запущенных программ.
Можно настроить отдельно для каждого приложения.
Далее запускаем нужную программу, ждем пока все загрузится и получаем PID программы с помощью tlist.exe (или как вам еще нравится).
Например, ПИД == 111. Затем запустите umdh.exe -p:111 -f:c:\temp\log1.log. Эта строка сохранит информацию обо всех текущих выделениях памяти в процессе 111 в файл log1.log. Далее работаем в программе, ждем некоторое время и пишем еще раз: 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 будут все выделенные и не освобожденные куски памяти со стеками вызовов! Чтобы стеки калибровок были корректными, вам необходимо настроить переменную среды _NT_SYMBOL_PATH. В справке написано, как настроить его для Microsoft exe и dll. Лучше всего сохранять вашу pdb на символьном сервере, который можно будет пополнять после сборки с помощью symstore.exe — тогда у отладчика всегда будет правильная pdb. Если сервера нет, можно просто поставить pdb рядом с exe - он должен подхватиться.
Если не получится, то добавьте путь к pdb в _NT_SYMBOL_PATH. Если у вас есть файл дампа и вам необходимо его проверить, то проще всего опять же использовать WinDbg. Он использует ту же переменную _NT_SYMBOL_PATH и, в отличие от VisualStudio, не требует исходных кодов или соответствующих двоичных файлов для отладки.
Просто дамп и подходящий pdb! Запускаешь WinDbg.exe, Файл\открыть аварийный дамп.
, открываешь дамп, пишешь !analyze -v, потом !uniqstack и обычно в простых случаях этого достаточно.
Вы видите какие pdbs были найдены, а какие нет и получаете анализ дампа.
Вы можете открывать окна со стеком вызовов, процессами и потоками и выполнять отладку.
Если вам нужно посмотреть код - File\Source File Path. - укажите путь к исходникам и вы сможете посмотреть то место в коде, где что произошло (лучше сразу прописать эти пути в переменной окружения _NT_SOURCE_PATH так чтобы не вводить их каждый раз).
Короче, опять же все просто и удобно, если у вас есть правильный pdb :) Проблемы с зависанием чего-либо можно легко решить, создав дамп зависшего процесса.
Для этого можно использовать тот же WinDbg или специальные программы или стандартную функцию системы в Висте в диспетчере задач - создать дамп :) Более того, DebuggingTools можно установить после зависания — перезагрузка не требуется.
Установил и удалил дамп.
Чтобы снять дамп, пользователю не нужен никакой pdb. Затем вы анализируете и исправляете этот дамп (в Windbg есть специальные команды для поиска взаимоблокировок и т.п.
— команда !locks и другие).
Заключение: Чтобы не было проблем с отладкой, нужно позаботиться о системе хранения файлов pdb для КАЖДОГО билда или хотя бы для официальных билдов.
А также изучить инструменты отладки и написать простые рекомендации для тестировщиков и программистов - что делать в случае ошибки или зависания, как создать дамп, куда его положить и с какими комментариями.
А некоторые тестировщики могут даже запустить WinDBG и скопировать оттуда необходимые данные, например стек вызовов с ошибкой, в отчет об ошибке — это очень помогает при предварительном анализе.
Кроме того, пара полезных ссылок для новичков о WinDBG: WinDbg. От А до Я! Общие команды WinDbg (тематически сгруппированные) Теги: #программирование #отладка #Чулан
-
Что Не Любить?
19 Oct, 24 -
Внешний Жесткий Диск Iomega Ego
19 Oct, 24 -
Microsoft Должна Открыть Sql Server
19 Oct, 24
