Роббинс Д. - Отладка приложений для Microsoft .NET и Microsoft Windows - 2004

Если счетчик вызовов для этой записи не равен 0.

{

Если размер этой записи > размер наилучшей записи по числу вызовов.

{

Обозначить эту запись как наилучшее соответствие по числу вызовов.

}

}

}

}

}

Если наилучшее соответствие по числу вызовов не найдено.

{

Считать наилучшей записью по числу вызовов наилучшую запись в целом.

}

Вывести имя функции, наилучшей по числу вызовов в PRF6файл. Присвоить значению оставшегося объема страницы размер всей

страницы.

}

}

Закрыть все временные файлы

}

Что после SWS?

Как я уже говорил, SWS обеспечивает довольно хорошую возможность оптимиза ции программ. Если вам хочется сделать ее еще лучше, вот несколько полезных советов.

Напишите программу начала и прекращения сбора данных. В функции _penter я выполняю проверку того, находится ли событие в сигнальном состоянии. Вы можете написать отдельную программу, которая будет генерировать событие, управляющее сбором данных утилитой SWS. Просто создайте событие с име нем SWS_Start_Stop_Event и генерируйте его, когда хотите прекратить накопле ние данных.

Реализуйте упомянутые мной возможности исключения символов, чтобы их число в ваших SWS файлах было минимальным.

Если вы по настоящему честолюбивы, создайте для просмотра данных и оп тимизации программу с графическим интерфейсом. Работать с ней будет го раздо удобней, чем с утилитой, основанной на командной строке.

684 ЧАСТЬ IV Мощные средства и методы отладки неуправляемого кода

Резюме

Чрезмерный объем кода не имеет никаких оправданий, поэтому в качестве за ключительной оптимизации приложения всегда следует выполнять упорядочение и максимальное уплотнение двоичных файлов. SWS позволяет посадить файлы на диету и уменьшить рабочий набор относительно безболезненно, особенно если использовать ее вместе с программой SettingsMaster, автоматизирующей управление конфигурацией проектов.

Ч А С Т Ь V

ПРИЛОЖЕНИЯ

П Р И Л О Ж Е Н И Е

A

Чтение журналов Dr. Watson

Я надеюсь, что для облегчения отладки приложений вы будете включать в них возможность создания минидампов (см. главу 13) и вам не придется изучать жур налы Dr. Watson. Однако, если у вас есть готовое приложение или ваши клиенты не могут высылать вам двоичные минидампы по электронной почте, Dr. Watson всегда сможет указать вам на время и место возникновения проблемы.

Пожалуй, доктора Ватсона следовало бы назвать доктором Джекилом и мисте ром Хайдом. В режиме доктора Джекила вы получаете информацию об ошибке на машине пользователя, легко находите место проблемы и быстро ее исправля ете. В режиме мистера Хайда вы получаете лишь еще один ни о чем не говоря щий набор чисел. В этом приложении я объясню работу с журналами Dr. Watson, что позволит вам реже встречаться с мистером Хайдом и чаще с доктором Дже килом.

На следующих страницах я рассмотрю полный журнал Dr. Watson, объясняя по ходу дела всю важную информацию (релевантные данные в конкретном раз деле выделены полужирным начертанием). Этот журнал был создан в результате одной из ошибок ранней версии WDBG.EXE — отладчика, написанного мной для главы 4.

После знакомства с этой книгой ничто в журнале Dr. Watson не должно быть для вас незнакомым. Что до различий между журналами Dr. Watson в Microsoft Windows 2000, Windows XP и Windows Server 2003, то их немного. Однако, как вы увидите ниже, версии Dr. Watson в двух последних ОС несколько лучше.

Для получения журналов запустите Dr. Watson (DRWTSN32.EXE). В списке Appli cation Errors (ошибки приложения) вы увидите недавние ошибки. Если этот спи сок пуст, возможно, Dr. Watson не задан в качестве отладчика по умолчанию. Что бы сделать Dr. Watson отладчиком по умолчанию, запустите его с ключом –i, т. е. введите выражение drwtsn32 –i. Для генерирования тестовой ошибки запустите

688 ЧАСТЬ V Приложения

Журналы Dr. Watson

Первый раздел журнала Dr. Watson имеет вид:

Исключение в приложении: Прил.: (pid=1796)

Время: 1/2/2003 @ 13:42:56.208

Номер: c0000005 (нарушение прав доступа)

Заголовок содержит информацию о причине ошибки: в моем примере это исклю чение в приложении. В случае некоторых ошибок номера исключений не всегда преобразуются в понятную людям форму, такую как «нарушение прав доступа» для исключения 0xC0000005. Все номера исключений вы можете узнать, отыскав в файле WINNT.H строки STATUS_. Коды ошибок указаны в документации как значе ния EXCEPTION_, возвращаемые функцией GetExceptionCode, однако реальные значе ния определяются в директивах #define STATUS_. После преобразования кода ошибки в значение EXCEPTION_ вы сможете просмотреть ее описание в документации к

GetExceptionCode.

Раздел System Information (сведения о системе) в объяснении не нуждается:

*——> Сведения о системе <——* Имя компьютера: HUME Имя пользователя: john

Число процессоров: 2

Тип процессора: x86 Family 15 Model 0 Stepping 10

Версия Windows 2000: 5.0

Текущая сборка: 2195

Пакет обновления: 3

Текущий тип: Multiprocessor Free

Зарегистрированная организация: Wintellect Зарегистрированный пользователь: John Robbins

Раздел Task List (список задач) выглядит так:

0_Total.exe

Вразделе Task List выводится список процессов, выполнявшихся в момент ошиб ки. К сожалению, в нем нет информации об их версиях, поэтому вам придется узнать у пользователя версии файлов всех процессов. В левом столбце указаны десятичные идентификаторы процессов (PID), выполнявшихся в момент ошиб ки. После ошибки они совершенно бесполезны.

Вразделе Module List (список модулей) указываются все модули, загруженные в момент ошибки в адресное пространство. Информация обо всех модулях име ет формат (адрес загрузки – максимальный адрес). В этом месте впервые появля ются различия между журналами Dr. Watson в Windows 2000, Windows XP и Windows Server 2003. В журналах Windows 2000 вы увидите только диапазоны адресов мо дулей и больше ничего. Если ваше приложение откомпилировано в Microsoft Visual Studio 6 и для него доступны символы, то после диапазона адресов будут указаны загруженные символы. Так как DBGHELP.DLL, поставляемая с Windows 2000, ни чего не знает о символах Microsoft Visual Studio .NET, вы никогда не увидите загру женные символы для двоичных файлов, откомпилированных в этой среде. Если в Windows 2000 список модулей имеет некоторые недостатки, то Dr. Watson в Win dows XP/Server 2003 достаточно умен, чтобы указывать после каждого диапазона адресов имя соответствующей DLL.

Список модулей в Windows 2000 (00400000 6 00460000) (77F80000 6 77FFB000) (63000000 6 6301B000) (77E10000 6 77E6F000) (77E80000 6 77F31000)

Список модулей в Windows XP

Если вы желаете узнать, какие модули были загружены в Windows 2000, вам остается только гадать. Однако, как я несколько раз говорил, чрезвычайно важно знать, в какие области адресного пространства процесса загружаются ваши DLL. Скорее всего вы сможете узнать свои DLL по адресам загрузки. Чтобы получить сведения о других DLL на компьютере пользователя, можно написать утилиту, которая просматривала бы их и сообщала их имена, адреса загрузки и размер.

Следующий фрагмент представляет собой начало раздела состояния потока, состоящего из трех частей (из за размеров страницы мне пришлось удалить коды

690 ЧАСТЬ V Приложения

операций, расположенные после адресов дизассемблированных команд, и пере нести строки информации о регистрах).

*——> State Dump for Thread Id 0xe14 (Копия памяти для потока 0xe14) <——*

eax=00000000 ebx=00000000 ecx=011305d8 edx=00000a30 esi=00154b40 edi=0012fae4

Dr. Watson отображает информацию о состоянии каждого потока, выполнявше гося в процессе в момент ошибки. Состояния потока содержат всю информацию, необходимую для обнаружения механизма и причин краха.

В разделе регистров указываются значения всех регистров в момент ошибки. Особое внимание следует уделить регистру EIP, указателю команд. Для моего при мера из Windows XP у меня имелись символы, поэтому вы можете видеть, какую функцию выполнял этот поток в момент ошибки, но в большинстве журналов Dr. Watson информации о символах не будет. Конечно, если Dr. Watson не сообщает вам имя функции, это не проблема. Просто загрузите в программу CrashFinder из главы 12 проект CrashFinder вашего приложения, введите адрес в поле Hexadecimal Address(es) (шестнадцатеричные адреса) и нажмите кнопку Find (найти).

Поток из нашего фрагмента оказался потоком, вызвавшим ошибку. Об этом свидетельствует только указатель FAULT > (СБОЙ >) в середине дизассемблиро ванного листинга. Пару раз я видел журналы Dr. Watson, в которых не было ука зателя FAULT >. Если вы не можете найти в журнале этот указатель, изучите со

стояние каждого потока и введите каждый адрес EIP в CrashFinder, чтобы узнать, какую команду выполнял поток в момент ошибки.

Если вы читали главу 7, дизассемблированный листинг должен быть вам по нятен. Новыми элементами будут только значения, показанные после команд. Чтобы вы могли узнать, какие значения использовались командой, дизассемблер Dr. Watson пытается просмотреть эффективный адрес ссылки на память. Адреса, начинаю щиеся с букв ss, свидетельствуют о том, что происходил доступ к сегменту стека; ds — к сегменту данных. В Windows XP/Server 2003 эффективный адрес будет указан только после строки, на которую указывал регистр EIP в момент ошибки.

Вжурналах Dr. Watson из Windows 2000 эффективные адреса будут указаны после каждой ассемблерной команды. Однако при этом гарантируется правиль ность только того адреса, что указан в строке, на которой находился указатель команд. Другие адреса могут быть неверны, так как значения, используемые коман дой, могли измениться. Допустим, первая дизассемблированная команда в состо янии потока ссылалась на память при помощи регистра EBX. Если ошибка случи лась после выполнения еще 10 команд, то одна из промежуточных команд легко могла изменить EBX. Однако, когда Dr. Watson в Windows 2000 дизассемблирует программу, для преобразования эффективного адреса он использует текущее зна чение EBX — то, которое имело место в момент ошибки. Поэтому эффективный адрес, показанный в дизассемблированном коде, может быть неверным. Итак, прежде чем поверить в значения эффективных адресов, убедитесь, что нужные регистры не были изменены никакой командой.

Благодаря недавно приобретенным навыкам работы с ассемблером, вы долж ны легко узнать, почему этот поток потерпел крах. Читая ассемблерный листинг Dr. Watson (или отладчика), большинство программистов допускает серьезную ошибку: они изучают его сверху вниз. Настоящая хитрость в том, чтобы начать исследование с места ошибки и постепенно подниматься вверх в поисках коман ды, присвоившей значения регистрам, использованным в команде, вызвавшей ошибку.

Внашем случае поток потерпел крах на команде 00410144 MOV ECX, [EAX+0x4], при которой регистр EAX имел значение 0. В Microsoft Windows все адреса, располо женные ниже 64 кб, отмечены как не имеющие доступа, поэтому попытка чтения памяти по адресу 0x00000004 — не лучшая идея. Итак, мы должны найти коман ду, заносящую 0 в EAX. Поднявшись на одну строку, вы увидите команду MOV EAX, [EBP+0xC]. Помните, что второй операнд, источник, помещается в первый операнд, приемник (иначе говоря, помните про правило «от источника к приемнику»). Это значит, что в EAX было скопировано значение, находившееся по адресу [EBP+0xC]. Следовательно, по адресу [EBP+0xC] располагался 0.

Вэтот момент вы должны вспомнить еще одну хитрость, которую я описал в главе 7: «параметры располагаются по положительным смещениям»! Параметры располагаются по положительным смещениям от регистра EBP, причем первый находится по адресу [EBP+0x8], а каждый следующий отстоит от предыдущего на 4 байта. Так как 0xC на 4 байта больше, чем 0x8, я могу предположить, что ошиб ка была вызвана тем, что второй параметр этой функции был равен NULL (наде юсь, прочитав эти два абзаца, вы поняли, как важно знать ассемблер в достаточ ном объеме для чтения журналов Dr. Watson!).

692 ЧАСТЬ V Приложения

Ниже вы можете увидеть вторую часть состояния потока: раздел Stack Back Trace (обратная трассировка стека) Заметьте: я вывожу имена функций на двух строках, чтобы они помещались на странице. При помощи двух символов подчеркивания (__) Dr. Watson отображает операцию разрешения области видимости (::).

*——> Stack Back Trace (Обратная трассировка стека) <——*