Использование утилиты CrashFinder
Как видите, чтение МАР-файла не слишком затруднительно. Оно скорее утомительно, но это, конечно, не должно касаться других членов команды (инженеров по качеству, персонала технической поддержки и даже менеджеров). Чтобы облегчить и их жизнь, я решил сделать утилиту CrashFinder пригодной к употреблению всеми членами команды — от разработчиков до инженеров службы поддержки (включая, конечно, и специалистов по тестированию). Я старался, чтобы все аварийные отчеты включили по возможности максимум информации об ошибках. Если соблюдается процедура создания соответствующих отладочных символов, описанная в главе 2, то применение CrashFinder не вызовет затруднений.
При использовании программы CrashFinder в рабочих группах необходимо особенно внимательно относиться к обеспечению доступности двоичных образов1 и связанных с ними PDB-файлов, потому что CrashFinder не хранит никакой другой информации о приложении, кроме путей к двоичным образам. CrashFinder сохраняет только имена двоичных файлов, так что один и тот же проект, работающий с утилитой CrashFinder, можно применять повсюду в цикле производства. Если бы CrashFinder хранил более детальную информацию о приложении, такую, например, как таблицы символов, то, вероятно, пришлось бы создавать CrashFinder-проект для каждого построения продукта. Если следовать этой рекомендации и разрешать свободный доступ к двоичным и PDB-файлам при аварийном завершении приложения, то специалистам по тестированию или поддержке останется лишь запускать CrashFinder, чтобы добавить к отчету об ошибках соответствующую информацию. Как всем известно, чем больше информации о проблеме доступно разработчику, тем легче ему решить эту проблему.
Здесь и далее под двоичными образами (binary images) автор понимает, по-видимому, любые двоичные файлы конкретного приложения — EXE, DLL, OCX и т. д. — Пер.
Вероятно, для конкретного приложения придется создать несколько CrashFinder-проектов. Если системные DLL являются частью CrashFinder-проекта, то для каждой операционной системы, которую вы поддерживаете, нужно будет создавать отдельные проекты.
Придется также создать CrashFinder- проект для каждой версии приложения, посылаемой специалистам по тестированию, не входящим в команду разработчиков, и отдельно для каждой такой версии хранить двоичные и PDB-файлы.
На рис. 8.2 изображен пользовательский интерфейс утилиты CrashFinder, в которую загружен один из проектов. Левая часть дочернего окна содержит управляемое дерево, на котором показаны выполняемые файлы и связанные с ними DLL-библиотеки. Маркеры * указывают, что символы каждого из двоичных образов (файлов) были загружены успешно. Если бы CrashFinder не смог загрузить символы, то слева от имени файла был бы указан маркер х. В правой части отображается символическая информация о выделенном в левой панели двоичном образе.
Двоичный образ добавляется к CrashFinder-'Проекту командой Add Image меню Edit. Добавляя двоичные образы, имейте в виду, что CrashFinder воспринимает только один ЕХЕ-файл в каждом проекте. Если приложение включает несколько ЕХЕ-файлов, необходимо создать отдельный CrashFinder-проект для каждого из них. Поскольку CrashFinder является МDI-приложением, то можно открыть отдельные проекты для каждого ЕХЕ-файла (с целью определения соответствующих аварийных позиций). Когда вы добавляете DLL-файлы, CrashFinder проверяет отсутствие конфликтов в адресах загрузки с любыми другими DLL, уже находящимися в проекте. Если CrashFinder обнаруживает конфликт, то позволит изменить адрес загрузки конфликтующей DLL только для текущего экземпляра CrashFinder-проекта. Такой режим удобен, когда вы, имея CrashFinder-проект для отладочной конфигурации, забываете перебазировать свои DLL: Как указано в главе 2, нужно всегда устанавливать базовые адреса для всех DLL приложения.
MDI — Multiple-Document Interface (многодокументный интерфейс). — Пер.
Если приложение изменится через какое-то время, то можно удалить ненужные двоичные образы, выбрав команду Remove Image меню Edit. Адрес загрузки двоичного образа можно изменять с помощью команды Image Properties меню Edit.
Целесообразно также добавлять в дерево системные DLL, которые используются проектом. Это дает возможность локализовать проблему, когда программа аварийно завершается в одном из них. Как уже говорилось в главе 5, наличие установленных отладочных символов в Windows 2000 иногда очень помогает при пошаговом выполнении кода дизассемблера системного модуля. Теперь есть даже более серьезная причина для установки отладочных символов в Windows 2000 — утилита CrashFinder может их использовать для того, чтобы предоставить разработчику возможность отыскивать аварии даже в системных модулях.
RaiSon d'etre утилиты CrashFinder состоит в том, чтобы преобразовать аварийный адрес в имя функции, имя исходного файла и номер строки. Выполнение команды Find Crash меню Edit открывает диалоговое окно Find Crash, показанное на рис. 8.3. Для каждого аварийного адреса, который требуется отыскать, нужно лишь ввести шестнадцатеричный адрес в редактируемое поле Hexadecimal Address и нажать кнопку Find.
Raison d'etre — разумное основание (франц.). — Пер.
В нижней части диалогового окна Find Crash отображена информация, относящаяся к последнему найденному адресу. Большинство полей здесь самоочевидно и не требует объяснения. Поле Fn Displacement показывает смещение адреса ошибки от начала функции в байтах, а поле Source Displacement — смещение адреса ошибки от начала ближайшей исходной строки. Помните, что отдельная исходная строка может порождать несколько инструкций языка ассемблера, особенно, если вызовы функций являются частью списка параметров. Имейте в виду, что при использовании программы CrashFinder нельзя отыскивать адреса, которые не являются адресами правильных (исполняемых) инструкций. Если в программе на C++ очищается указатель this, то это может вызвать аварийный останов в адресе 0x00000001. К счастью, такие типы ошибок не столь распространены как обычные ошибки нарушения доступа к памяти, которые можно легко найти с помощью утилиты CrashFinder.
