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

ГЛАВА 2 Приступаем к отладке	61

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

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

Тестирование качества должно проводиться с отладочными компоновками

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

Есть одно очень важное условие: запретить вывод информации макросами ASSERT, чтобы они не мешали работе автоматизированных тестов отдела контроля каче$ ства. В главе 3 я расскажу о применении макросов ASSERT для управляемого и не$ управляемого кода. И управляемый код, и мой макрос SUPERASSERT для неуправля$ емого кода поддерживают отключение всплывающих информационных окон и вывода других данных, вызывающих неудачу автоматизированных тестов.

На начальных стадиях цикла разработки программы сотрудники группы кон$ троля качества должны тестировать и отладочные, и заключительные компонов$ ки. По мере развития проекта им следует все большее внимание уделять заклю$ чительным компоновкам. Пока вы не достигнете точки альфа$версии, когда в программе будет реализовано достаточно функций, чтобы ее можно было пока$ зать клиентам, группа контроля качества должна тестировать отладочные компо$ новки два$три дня в неделю. При приближении к контрольной точке бета$1 вре$ мя тестирования отладочных компоновок нужно снизить до двух дней в неделю. По достижении точки бета$2, когда все функции программы реализованы и ос$ новные ошибки исправлены, это время надо уменьшить до одного дня в неделю.

62 ЧАСТЬ I Сущность отладки

Миновав контрольную точку предварительной версии (release candidate), следует перейти на тестирование только заключительных компоновок.

Устанавливайте символы ОС и создайте хранилище символов

Как известно любому человеку, который провел более 5 минут над разработкой программ для Windows, секрет эффективной отладки состоит в согласованном использовании корректных символов. Если вы пишете управляемый код, то без символов отладка вообще может оказаться невозможной. Работая без символов над неуправляемым кодом, вы, возможно, не получите чистые стеки вызовов из$ за «плавающих стеков» — для этого нужны данные FPO, содержащиеся в PDB$файле.

Если вы думаете, что заставить всех членов группы и сотрудников компании применять корректные символы очень сложно, представьте, насколько хуже об$ стоит дело в группе разработчиков ОС Microsoft. Они работают над крупнейшим коммерческим приложением в мире, имеющем более 40 миллионов строк кода. Они выполняют сборку каждый день, и в каждый конкретный момент времени во многих странах мира выполняются тысячи различных компоновок ОС. Не прав$ да ли, с этой точки зрения, ваши проблемы с символами — сущая чепуха: даже если вы думаете, что работаете над большим проектом, ваши неудобства ни в ка$ кое сравнение не идут с такой огромной символьной болью!

Кроме проблемы с символами перед программистами Microsoft также стояла проблема получения нужных двоичных файлов. Одна из разработанных в Microsoft технологий, призванных помочь отлаживать ошибки, называется минидамп, или аварийный дамп. Минидамп представляет собой файлы, содержащие сведения о состоянии приложения на момент аварийного завершения. Если вы имеете опыт работы с другими ОС, можете называть его дампом ядра. Привлекательность ми$ нидампа объясняется тем, что, имея файлы, характеризующие состояние прило$ жения, вы сможете загрузить его в отладчик, и все данные будут такими, как если бы крах приложения произошел на ваших глазах. О создании собственных ми$ нидампов, а также о работе с ними в отладчиках я расскажу в следующих главах. Большая проблема минидампов заключается в загрузке правильных двоичных файлов. Даже если вы создаете программу на платформе Windows Server 2003 или более новой, минидамп клиента может быть создан в системе Windows 2000 только с первым пакетом обновления. В этом случае справедливо то же утверждение, что и в ситуации с символами: если вы не можете загрузить точные двоичные файлы, находившиеся в памяти во время создания минидампа, вы полностью заблуждае$ тесь, если думаете, что он позволит вам легко справиться с проблемой.

Разработчики Microsoft понимали, что им просто необходимо сделать что$то, чтобы облегчить свою жизнь. Мы, программисты, не работающие в Microsoft, также жаловались, что из$за отсутствия символов и двоичных файлов ОС, соответству$ ющих многочисленным обновлениям и исправлениям, установленным на конк$ ретном компьютере, отладка превращается в пытку. Концепция сервера символов проста: хранить все символы и двоичные файлы публичных компоновок в извес$ тном месте и наделить отладчики необходимым интеллектом, чтобы они могли использовать корректные символы и двоичные файлы для каждого загружаемого в процесс модуля — независимо от того, загружается ли он вашей программой или

ГЛАВА 2 Приступаем к отладке	63

ОС — без взаимодействия с пользователем. Вся прелесть в том, что реальность почти столь же проста! С серверами символов связано несколько проблем, которые я опишу чуть ниже, но, если сервер символов создан и настроен как надо, никто в вашей группе или компании никогда не будет страдать от отсутствия корректных символов или двоичных файлов независимо от того, разрабатывает ли он управ$ ляемый, неуправляеымй или смешанный код и использует ли отладчик Visual Studio

.NET или WinDBG. И еще одна приятная новость: к этой книге я прилагаю несколько файлов, которые возьмут на себя всю работу по получению отличных символов

идвоичных файлов для ОС и ваших программ.

Вдокументации к Visual Studio .NET упоминается один метод создания серве$ ра символов для отладки, но он требует выполнения нескольких одинаковых дей$ ствий для каждой загружаемой программы, что очень неудобно. Кроме того, там не обсуждается самое важное: как заполнить сервер символами и двоичными файлами. Так как именно в этом огромное преимущество применения сервера символов, то для достижения символьной нирваны вам понадобится сделать сле$ дующее.

Получить физический сервер, к которому сможет получать доступ любой со$ трудник, работающий над вашими проектами, довольно просто. Вы, вероятно, захотите назвать этот сервер \\SYMBOLS, чтобы сразу было ясно, какую функцию он выполняет. В оставшейся части я буду использовать именно это имя сервера. Он не обязательно должен быть очень мощным, так как будет выполнять функ$ цию обычного файлового сервера. Однако я очень рекомендую, чтобы сервер имел довольно большой объем дискового пространства. Для начала вполне хватит от 40 до 80 Гб. Установив все серверное ПО, создайте два каталога с общим досту$ пом под названием OSSYMBOLS и PRODUCTSYMBOLS, разрешив запись и чтение всем разработчикам и сотрудникам отдела контроля качества. Вы, наверное, уже догадались по названиям, что в одном каталоге будут храниться символы и дво$ ичные файлы ОС, а во втором — аналогичные файлы ваших программ. Для про$ стоты администрирования их следует хранить отдельно. Я полагаю, вы сможете получить в свое распоряжение этот сервер. Все сражения за него я оставляю вам в качестве упражнения.

Следующий шаг к достижению символьной нирваны — установка пакета Debug$ ging Tools for Windows. Его можно или загрузить с сайта Microsoft по адресу www.mic$ rosoft.com/ddk/debugging, или установить с CD, прилагаемого к книге. Обратите внимание: двоичные файлы для сервера символов созданы группой разработчи$ ков Windows, а не Visual Studio .NET. Проверьте, существует ли обновленная вер$ сия Debugging Tools for Windows; похоже, группа разработчиков обновляет этот пакет довольно часто. После установки Debugging Tools for Windows укажите ус$ тановочный каталог в системной переменной среды PATH. Разрешите запись ин$ формации в сервер символов и ее чтение для четырех важнейших двоичных фай$ лов: SYMSRV.DLL, DBGHELP.DLL, SYMCHK.EXE и SYMSTORE.EXE.

Если вы работаете с прокси$сервером, требующим регистрации при каждом подключении к Интернету, я вам сочувствую. К счастью, группа разработчиков Windows не осталась безучастной к вашей боли. В пакет Debugging Tools for Windows версии 6.1.0017 входит новая версия библиотеки SYMSRV.DLL, удовлетворяющая требованиям компаний, следящих за каждым Интернет$пакетом. Изучите в доку$

64 ЧАСТЬ I Сущность отладки

ментации к Debugging Tools for Windows раздел «Using Symbol Servers and Symbol Stores» (Использование серверов и хранилищ символов), в котором обсуждается работа с прокси$серверами и межсетевыми экранами. Там сказано, как задать переменную среды _NT_SYMBOL_PROXY, чтобы избежать ввода имени пользователя и пароля при каждом запросе на загрузку символов. Следите за появлением новых версий Debugging Tools for Windows на сайте www.microsoft.com/ddk/debugging. Группа разработчиков Windows постоянно работает над улучшением серверов сим$ волов, поэтому я рекомендую следить за появлением новых версий этого пакета.

Как только вы установите Debugging Tools for Windows, вам останется только создать системную среду для Visual Studio и отладчика WinDBG. Лучше всего за$ дать переменную среды в системных параметрах (т. е. параметрах для всего ком$ пьютера). Для получения доступа к этой области в Windows XP/Server 2003 нуж$ но щелкнуть правой кнопкой значок My Computer (Мой компьютер) и выбрать в контекстном меню пункт Properties (Свойства). Выберите вкладку Advance (Допол$ нительно) и нажмите кнопку Environment Variables (Переменные среды) в ниж$ ней части страницы. Диалоговое окно Environment Variables показано на рис. 2$ 10. Если переменной среды _NT_SYMBOL_PATH нет, создайте ее и присвойте ей следу$ ющее значение (обратите внимание, что указанное выражение должно быть вве$ дено в одной строке):

SRV*\\Symbols\OSSymbols*http://msdl.microsoft.com/download/symbols;

SRV*\\Symbols\ProductSymbols

Рис. 2 10. Диалоговое окно Environment Variables

Переменная _NT_SYMBOL_PATH будет указывать Visual Studio .NET и WinDBG, где искать ваши серверы символов. В указанной строке заданы два отдельных серве$ ра символов, отделенные точкой с запятой: один для символов ОС, а другой для символов ваших программ. Буквы SRV в начале обеих частей строки приказыва$ ют отладчикам загрузить библиотеку SYMSRV.DLL и передать ей значения, распо$

ГЛАВА 2 Приступаем к отладке	65

ложенные после SRV. В случае первого сервера символов вы сообщаете SYMSRV.DLL, что символы ОС будут храниться в каталоге \\Symbols\OSSymbols; вторая звездочка является HTTP$адресом, который SYMSRV.DLL будет использовать для загрузки любых символов (но не двоичных файлов), отсутствующих в сервере символов. Этот раздел переменной _NT_SYMBOL_PATH обеспечит обновление символов ОС. Вторая часть переменной _NT_SYMBOL_PATH говорит библиотеке SYMSRV.DLL о том, что спе$ цифические символы ваших программ следует искать только в общем каталоге \\Symbols\ProductSymbols. Если вы хотите задать другие пути поиска, можете до$ бавить их к строке переменной _NT_SYMBOL_PATH, разделив их точками с запятой. Так, в следующей строке указано, чтобы поиск символов ваших программ осуще$ ствлялся и в корневом системном каталоге System32, потому что именно в этот каталог Visual Studio .NET помещает PDB$файлы стандартной библиотеки C и MFC при установке:

SRV*\\Symbols\OSSymbols*http://msdl.microsoft.com/download/symbols;

SRV*\\Symbols\ProductSymbols;c:\windows\system32

Вполной степени достоинства сервера символов обнаруживаются при его заполнении символами ОС, загруженными с сайта Microsoft. Если вы опытный «охотник на насекомых», то, вероятно, уже установили символы ОС. Однако это всегда немного разочаровывает, так как почти на всех компьютерах установлены те или иные пакеты исправлений, а определенные символы ОС никогда не вклю$ чают символы этих пакетов. К счастью, серверы символов гарантируют, что вы всегда сможете получить абсолютно правильные символы ОС без всякого труда! Это огромное благо, которое здорово облегчит вашу жизнь. Оно стало возмож$ ным благодаря тому, что Microsoft открыла доступ к символам для всех ОС от Microsoft Windows NT 4 до последних версий Windows XP/.NET Server 2003, включая все пакеты обновлений и исправления.

Вначале следующего сеанса отладки отладчик автоматически увидит, что пе$ ременная _NT_SYMBOL_PATH задана и, если нужного ему файла символов не найдет$ ся, начнет загрузку символов ОС с Web$сайта Microsoft и поместит их в ваше хра$ нилище символов. Внесем ясность: сервер символов загрузит с сайта только нуж$ ные ему символы, а не все символы ОС. Размещение хранилища символов в об$ щем каталоге сэкономит вам много времени: если один из членов группы уже загрузил нужный вам символ, вам не понадобится загружать его повторно.

Всамом по себе хранилище символов нет ничего удивительного. Это обыч$ ная база данных, которая для нахождения файлов использует файловую систему. На рис. 2$11 показано, как выглядит часть дерева моего сервера символов в окне Windows Explorer. Корневой каталог называется OSSymbols, и все файлы симво$ лов, такие как ADVAPI32.PDB, находятся на первом уровне. Под именем каждого файла символов находится каталог, название которого соответствует дате/времени, сигнатуре и прочей информации, необходимой для полного определения конк$ ретной версии файла символов. Помните: при наличии нескольких вариантов файла (например, ADVAPI32.PDB) для различных версий ОС, у вас будет и несколько каталогов, соответствующих каждому варианту. В каталоге сигнатур скорее всего будет находиться конкретный файл символов для данного варианта. Есть меры предосторожности, которые нужно соблюдать, создавая при помощи специаль$

66 ЧАСТЬ I Сущность отладки

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

Рис. 2 11. Пример базы данных сервера символов

Загрузка символов во время отладки очень полезна, однако она не способствует получению двоичных файлов ОС. Кроме того, лучше было бы не возлагать ответ$ ственность за получение символов на разработчиков, а изначально наполнить серверы символов всеми двоичными файлами и символами всех поддерживаемых вами ОС. Это позволило бы вам работать с любыми минидампами клиентов и любыми отладочными проблемами, с которыми вы столкнетесь в своем отделе.

Пакет Debugging Tools for Windows (в состав которого входит WinDBG) вклю$ чает два очень полезных инструмента: Symbol Checker (SYMCHK.EXE), предназна$ ченный для загрузки в ваш символьный сервер символов Microsoft, и Symbol Store (SYMSTORE.EXE), который заботится о загрузке в хранилище символов двоичных файлов. Я понимал, что для наполнения своего сервера символами и двоичными файлами для всех версий ОС, которые я хочу поддерживать, мне придется рабо$ тать с обоими инструментами, поэтому я решил автоматизировать этот процесс. Я хотел, чтобы создание сервера символов ОС было простым и легким, чтобы он постоянно был заполнен последними двоичными файлами и символами и чтобы это практически не требовало работы.

Создавая первый сервер символов ОС, установите первую версию ОС без вся$ ких пакетов обновлений и исправлений. Установите пакет Debugging Tools for Windows и укажите его установочный каталог в переменной PATH. Для получения двоичных файлов и символов ОС запустите мой файл OSSYMS.JS, про который я расскажу чуть ниже. Когда OSSYMS.JS завершит свою работу, установите первый пакет обновлений и выполните OSSYMS.JS повторно. Установив все пакеты обнов$ лений и скопировав все их двоичные файлы и символы, установите все обновле$ ния, рекомендованные функцией Windows Update ОС Windows 2000/XP/.NET Server 2003, и запустите OSSYMS.JS в последний раз. Повторите этот процесс для всех ОС, которые вам нужно поддерживать. Теперь, чтобы ваш сервер символов посто$ янно находился в отличном состоянии, нужно будет только запускать OSSYMS.JS каждый раз, когда вы установите исправление или новый пакет обновлений. Ради

ГЛАВА 2 Приступаем к отладке	67

целей планирования я подсчитал, что это требует чуть менее 1 Гб для каждой версии ОС и примерно такого же объема для каждого пакета обновлений.

Возможно, вы думаете, что OSSYMS.JS (и вспомогательный файл WRITEHOT$ FIXES.VBS, который нужно скопировать в тот же каталог, что и OSSYMS.JS) пред$ ставляет собой простую оболочку для вызова программ SYMCHK.EXE и SYMSTO$ RE.EXE, но это не так. На самом деле это очень полезная оболочка. Если вы изу$ чите ключи командной строки обеих программ, вам непременно захочется авто$ матизировать их работу, потому что в ключах очень легко запутаться. Запустив программу OSSYMS.JS без параметров командной строки, вы увидите текст, опи$ сывающий все ее функции:

OSsyms Version 1.0 Copyright 2002 2003 by John Robbins Debugging Applications for Microsoft .NET and Microsoft Windows

Fills your symbol server with the OS binaries and symbols.

Run this each time you apply a service pack/hot fix to get the perfect

symbols while debugging and		for mini dumps.
SYMSTORE.EXE and SYMCHK.EXE		must be in the	path.
Usage: OSsyms <symbol server>		[ e| v| b| s| d]
<symbol server> The symbol server in \\server\share.
e	Do EXEs as well as DLLs.
v	Do verbose output.
d	Debug the	script. (Shows	what would execute.)
b	Don't add	the binaries to the symbol store.
s	Don't add	the symbols to	the symbol store.

(Not recommended)

Единственный необходимый параметр — путь к серверу символов в формате \\сервер\общий_каталог. Когда вы запускаете программу OSSYMS.JS, она сначала определяет версию ОС и уровень установленного пакета обновлений и находит все исправления. Это позволяет приложению SYMSTORE.EXE правильно заполнить информацию о программе, ее версии и поле комментария, чтобы вы могли точ$ но определить, какие символы и двоичные файлы хранятся в сервере символов. Про специфические ключи командной строки SYMSTORE.EXE и то, как узнать, что находится в вашей базе данных, я расскажу ниже. Огромная важность информа$ ции об установленных пакетах обновлений и исправлений объясняется тем, что при получении минидампа она позволяет быстро определить, есть ли в сервере символов двоичные файлы и символы для этого конкретного случая.

После сбора нужной системной информации программа OSSYMS.JS выполня$ ет рекурсивный поиск всех двоичных файлов DLL в каталоге ОС (%SYSTEMROOT%) и копирует их в сервер символов. Выполнив копирование, OSSYMS.JS вызывает про$ грамму SYMCHK.EXE для автоматической загрузки из Интернета всех имеющихся символов для этих DLL. Если вы хотите сохранить в сервере символов все EXE$ файлы и их символы, укажите в командной строке OSSYMS.JS после пути к серве$ ру символов ключ–e.

Чтобы узнать, какие двоичные файлы и символы были сохранены в сервере символов, а какие были проигнорированы (с указанием причин), прочитайте

68 ЧАСТЬ I Сущность отладки

информацию, содержащуюся в текстовых файлах DllBinLog.TXT и DllSymLog.TXT,

вкоторых описаны результаты добавления в сервер двоичных файлов и симво$ лов DLL соответственно. В случае EXE$файлов соответствующие файлы называ$ ются ExeBinLog.TXT и ExeSymLog.TXT.

Выполнение OSSYMS.JS может потребовать времени. Копирование двоичных файлов в сервер символов выполняется быстро, однако загрузка символов из сети Интернет может затянуться. При загрузке символов ОС для DLL и EXE$файлов нужно будет загрузить скорее всего около 400 Мб данных. Следует избегать добавления двоичных файлов в сервер символов несколькими комьютерами одновременно. Это объясняется тем, что SYMSTORE.EXE использует в качестве базы данных фай$ ловую систему и текстовый файл, поэтому она не поддерживает транзакций. Про$ грамма SYMCHK.EXE не использует текстовую базу данных SYMSTORE.EXE, поэтому сохранение символов несколькими разработчиками одновременно вполне допу$ стимо.

Microsoft постоянно размещает на своем сайте все большее число символов для своей продукции. Программа OSSYMS.JS достаточно гибка, чтобы можно было легко указывать серверу символов дополнительные каталоги хранения двоичных фай$ лов и соответствующих символов. Чтобы добавить в сервер символов новые дво$ ичные файлы, найдите глобальную переменную g_AdditionalWork, расположенную

вначале файла OSSYMS.JS. Этой переменной присвоено значение null, поэтому в функции main она не обрабатывается. Чтобы сохранить в сервере символов но$ вый набор файлов, создайте Array и добавьте в него в качестве элемента класс SymbolsToProcess. Ниже показано, как включить сохранение в сервере символов всех DLL, которые находятся в каталоге Program Files. Заметьте: первый элемент не обязан быть переменной среды — он может быть названием конкретного каталога, ска$ жем, «e:\ Program Files». Однако использование общей системной переменной среды позволяет избежать жесткого задания названий дисков.

var g_AdditionalWork = new	Array
(
new SymbolsToProcess (	"%ProgramFiles%"	,	// Начальный каталог.
	"*.dll"	,	// Ищем все DLL.
	"PFDllBinLog.TXT"	,	// Журнал для двоичных файлов.
	"PFDllSymLog.TXT"	)	// Журнал для символов.
) ;

Я объяснил, как сохранить в сервере символов двоичные файлы и символы ОС. Давайте теперь рассмотрим, как с помощью программы SYMSTORE.EXE сделать то же самое для ваших программ. SYMSTORE.EXE имеет много ключей командной строки (табл. 2$2).

Табл. 2-2. Важные ключи командной строки программы SYMSTORE

Ключ	Описание
add	Добавляет файлы в хранилище символов.
del	Удаляет из хранилища символов конкретный набор файлов.
/f File	Добавляет в хранилище символов конкретный файл или каталог.
/r	Рекурсивно добавляет в хранилище символов файлы или каталоги.
/s Store	Корневой каталог хранилища символов.

	ГЛАВА 2	Приступаем к отладке	69
Табл. 2-2.	Важные ключи командной строки …	(продолжение)
Ключ	Описание
/t Product	Название программы.
/v Version	Версия программы.
/c	Дополнительные комментарии.
/o	Подробный вывод, полезный для отладки.
/i ID	Идентификатор транзакции из файла history.txt, используемый
	при удалении файлов.
/?	Справка.

Наилучший способ использования SYMSTORE.EXE состоит в автоматическом сохранении EXE$, DLL$ и PDB$файлов дерева проекта после его ежедневной сборки (если дымовой тест покажет, что программа работает), после каждой контрольной точки и при передаче компоновки за пределы группы. Если вы не обладаете дис$ ковым пространством огромного объема, то разработчикам не следует сохранять в сервере символов свои локальные компоновки. Например, следующая команда сохраняет в хранилище символов все PDB$ и двоичные файлы, которые будут обнаружены во всех каталогах, дочерних по отношению к каталогу D:\BUILD (вклю$ чая и его).

symstore add /r /f d:\build\*.* /s \\Symbols\ProductSymbols

/t "MyApp" /v "Build 632" /c "01/22/03 Daily Build"

При добавлении файлов ключ /t (название программы) требуется всегда, но для ключей /v (версия) и /c (комментарии) это, увы, не так. Советую всегда ис$ пользовать ключи /v и /c, потому что информация о том, какие файлы хранятся в сервере символов вашей программы, никогда не может оказаться лишней. По мере заполнения сервера символов вашей программы это приобретает особую важность. Символы, хранящиеся в сервере символов ОС, имеют меньший объем из$за того, что они не включают всех частных символов и типов, однако символы вашей про$ граммы могут достигать огромных размеров, что может приводить к заметному уменьшению дискового пространства при работе над полугодовым проектом.

Непременно сохраняйте в сервере символов все компоновки, соответствую$ щие достижению контрольных точек, и компоновки, отсылаемые за пределы груп$ пы. Однако мне нравится держать в хранилище символов двоичные файлы и сим$ волы ежедневных компоновок не более чем за последние четыре недели. Как видно из табл. 2$2, SYMSTORE.EXE поддерживает и удаление файлов.

Для гарантии того, что вы удаляете те файлы, которые действительно собира$ лись удалить, нужно посмотреть специальный каталог 000admin, находящийся в общем каталоге сервера символов. В этом каталоге есть файл HISTORY.TXT, со$ держащий историю всех транзакций сервера символов и, если вы добавляли файлы в сервер символов, набор пронумерованных файлов, включающих списки фай$ лов, которые на самом деле были добавлены в сервер символов в результате тран$ закций.

HISTORY.TXT является файлом со значениями, разделенными запятыми (Comma separated value, CSV), поля которого приведены в табл. 2$3 (для добавления фай$ лов) и в табл. 2$4 (для удаления файлов).

70	ЧАСТЬ I	Сущность отладки
Табл. 2-3. Поля CSV файла HISTORY.TXT для добавления файлов
Поле		Описание
ID		Номер транзакции. Это число имеет 10 разрядов, поэтому в об$
		щей сложности сервер символов может выполнить
		9,999,999,999 транзакций.
Add		При добавлении файлов это поле всегда имеет значение add.
File или Ptr		Показывает, что было добавлено: файл (file) или указатель
		(ptr) на файл, находящийся в другом месте.
Date		Дата транзакции.
Time		Время начала транзакции.
Product		Название программы, указанное после ключа /t.
Version		Версия программы, указанная после ключа /v (необязательный
		параметр) .
Comment		Текст комментария, указанный после ключа /c (необязательный
		параметр) .
Unused		Неиспользуемое поле, зарезервированное на будущее.
Табл. 2-4. Поля CSV файла HISTORY.TXT для удаления файлов
Поле		Описание
ID		Номер транзакции.
Del		При удалении файлов это поле всегда имеет значение del.
Deleted Transaction		10$разрядный номер удаленной транзакции.

Как только вы определили номер транзакции, которую желаете удалить, сде$ лать это при помощи SYMSTORE.EXE очень просто:

symstore del /i 0000000009 /s \\Symbols\ProductSymbols

При удалении файлов из сервера символов я заметил одну странную вещь: не выводится абсолютно никакой информации, подтверждающей, что удаление увен$ чалось успехом. Если вы забудете указать какой$то важный ключ командной строки, например, само название сервера символов, вы не получите никаких предупреж$ дений и, возможно, будете ошибочно думать, что файлы были удалены. Поэтому после удаления я всегда проверяю файл HISTORY.TXT, чтобы убедиться, что уда$ ление действительно имело место.

Исходные тексты и серверы символов

После упорядочения символов и двоичных файлов следующий элемент голово$ ломки — упорядочение исходных файлов. Правильные стеки вызовов — прекрасное достижение, но пошаговое изучение комментариев к исходному коду не нравит$ ся никому. К сожалению, пока Microsoft не интегрирует компиляторы с системой управления версиями, чтобы по мере создания компоновок компиляторы могли извлекать и помечать исходные тексты программы, вам придется кое$что делать вручную.

Возможно, вы не заметили, но все компиляторы из состава Visual Studio .NET уже включают в PDB$файлы полный путь к исходным файлам программы. В пре$