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

которые советы, которые помогут вам узнать, на что вы смотрите: на исполняе мый код или на что то другое.

Я обнаружил, что эту задачу можно облегчить, выбрав в контекстном меню окна Disassembly пункт Code Bytes (байт коды), включающий отображение иденти фикаторов операций. Знание некоторых идентификаторов очень часто помо гает выяснить, что же вы видите в окне Disassembly.

Если вы видите последовательность одинаковых команд ADD BYTE PTR [EAX], AL, это не исполняемый код. Это просто ряд нулей.

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

Если вы видите ряд команд, которые я в этой главе не описывал, вероятно, вы смотрите на данные.

Если дизассемблер Visual Studio .NET не может дизассемблировать команду, вместо идентификатора операции он выводит «???».

Если команда некорректна, дизассемблер выведет «db», после чего будет сле довать число. Аббревиатура «db» означает «байт данных» (data byte) и не явля ется корректной командой. Это значит, что согласно картам процессоров Intel идентификатор(ы) операции по этому адресу не соответствует никаким командам.

Регистры и окно Watch

Окно Watch отладчика Visual Studio .NET умеет преобразовывать все регистры в значения. Это позволяет ввести в окне Watch интересующий регистр и привести его к нужному вам типу. Например, если вы изучаете команду работы со строка ми, то, введя в окне Watch выражение (char*)@EDI или (wchar_t*)@EDI, вы увидите данные в формате, более легком для понимания.

Изучение файлов ASM

Если вы хотите лучше изучить параллели между ассемблером и исходным кодом, можете приказать Visual Studio .NET генерировать ассемблерные листинги для исходных файлов. Откройте страницу Property Pages, папку C/C++, страницу Output Files и выберите в поле Assembler Output пункт Assembly With Source Code (/FAs) (ассемблерный и исходный код). После этого компилятор будет генерировать для каждого вашего исходного файла соответствующий файл ASM. Возможно, вам не захочется создавать ASM файлы для каждой компоновки, но они очень наглядно иллюстрируют работу компилятора. Файлы ASM избавят вас от необходимости загружать приложение при каждом приступе интереса к ассемблеру.

Генерируемые файлы почти готовы к компиляции при помощи Microsoft Macro Assembler (MASM), поэтому в них иногда очень сложно разбираться. Большую часть файлов занимают директивы MASM, однако в основных разделах вы увидите код C соответствующими ассемблерными командами под каждой конструкцией. После прочтения этой главы у вас не должно возникать никаких проблем с понимани ем файлов ASM.

322 ЧАСТЬ II Производительная отладка

Резюме

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

Усложненные точки прерывания для неуправляемого кода помогут вам избе жать нудной работы путем указания точного места и условий срабатывания точ ки прерывания. Для указания отладчику точной области видимости и расположе ния точек прерывания используется контекстная часть усложненного синтакси са точек прерывания. Псевдорегистры, особенно $TIB и $ERR, наделяют условные выражения еще большей силой. Глобальные точки прерывания по данным под держивают установку прерывания на доступ к памяти; когда интересующие вас данные изменятся, программа остановится. Написанный Майком Мориарти класс аппаратных точек прерывания позволяет устанавливать в своем коде точки пре рывания на чтение и запись данных.

Удивительно гибкое окно Watch предоставляет прекрасные возможности, уско ряющие отладку: оно не только разрешает изменять значения переменных, но и поддерживает функции форматирования, чтобы вы могли просматривать данные в наиболее удобном виде. Окно Watch также позволяет вызывать из отладчика функции вашей программы. Благодаря этому можно создавать и использовать спе циальные отладочные функции, автоматизирующие большинство утомительных отладочных задач. Кроме того, сэкономить время можно, применив быстрое раз вертывание собственных типов и отображение значений HRESULT. Наконец, новая модель EEAddIn, позволяющая вам использовать собственные правила отображе ния информации путем вызова ваших DLL окном Watch, открывает новый мир воз можностей отображения данных.

Высокой эффективности отладки неуправляемых приложений можно достичь путем удаленной отладки DCOM, а также при помощи Pipes, решения, поддержи вающего отладку только неуправляемого кода. Удаленная отладка через Pipes по зволяет запускать в отладчике процессы на удаленных машинах, что может оказаться очень полезным разработчикам крупных клиентских приложений. Кроме того, Pipes позволяет подключаться и отлаживать несколько процессов на удален ном компьютере.

Вторая половина этой главы была посвящена тем аспектам языка ассемблера процессоров Intel, которые необходимы для выживания в окне Disassembly. Я на чал с основ архитектуры процессоров Intel, таких как регистры и флаги статуса, после чего рассмотрел команды работы со стеком, данными, указателями и стро ками; команды сравнения и проверки операндов; безусловного и условного пе реходов и циклов. Я также привел некоторые советы и хитрости, которые помо гут сделать отладку на уровне ассемблера максимально эффективной.

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

Г Л А В А

8

Улучшенные приемы для неуправляемого кода

с использованием WinDBG

Хоть я и потратил время, как мне кажется, на миллион страниц документации к отладчику Microsoft Visual Studio .NET, все же есть и другой отладчик от Microsoft, о котором надо поговорить, — Microsoft WinDBG. Я часто удивляюсь, почему в Microsoft две разные команды работают над отладчиками, но я доволен, что они приложили столько усилий, так как WinDBG имеет некоторые сверхмощные воз можности для усмирения ошибок. Когда я спрашивал людей из Microsoft, почему у них два отладчика, они приводили разумные аргументы. Visual Studio .NET пре красна для разработки приложений, но тем, кто работает над ОС, нужно что то более наращиваемое для автоматизации задач поиска трудных ошибок, для отсле живания проблем, встречающихся в более чем 40 миллионах строк кода.

WinDBG — мощнейшая вещь. Если Visual Studio .NET предлагает прекрасные расширяемые средства для управления средой (как вы увидите в главе 9), WinDBG — это мускулы, необходимые для пинков и толчков в отлаживаемой программе. Конечно, этой силе можно противопоставить и альтернативные варианты, кото рые мы обсудим чуть позже.

Многие думают, что WinDBG нужен только разработчикам драйверов, но его сила распространяется и на неуправляемые приложения пользовательского режима. WinDBG может предоставить столько информации о процессах, что в Visual Studio

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

324 ЧАСТЬ II Производительная отладка

Моя цель в этой главе — помочь вам преодолеть кое какие препятствия, с ко торыми вы столкнетесь, когда начнете применять WinDBG. Кроме того, я хочу показать некоторые мощные команды и объяснить, как их использовать. Я также помогу вам обойти проблемы, ошибки и прочие странности, с которыми вы встре титесь в WinDBG. Наконец, как я обещал в главе 6, я освещу отладчик Son of Strike (SOS) для работы с управляемыми приложениями и файлами дампов.

На CD, прилагаемом к книге, вы найдете пакет Debugging Tools for Windows (средства отладки для Windows), включающий в себя WinDBG. CD содержит по следнюю версию на момент выхода книги в свет. Вам также следует проверить стра ничку http://www.microsoft.com/ddk/debugging, где Microsoft выкладывает после дние версии и наиболее важную информацию о Debugging Tools for Windows. Команда разработчиков постоянно обновляет WinDBG, обеспечивая поддержку все большего набора функций и новейших ОС. Для материала этой главы я исполь зовал последнюю версию WinDBG, доступную мне на момент написания книги, — 6.1.0017.0.

Прежде чем начать

Прежде чем нырнуть с головой в WinDBG, я хочу кратко осветить некоторые клю чевые моменты. Первое: если у вас появится намек на то, чтобы написать расши рение WinDBG, проверьте, что у вас установлен SDK из состава Debugging Tools for Windows. Этот SDK включает заголовочные файлы и примеры, демонстриру ющие идеи, заложенные в расширения. При установке укажите выборочную (Cus tom) установку на соответствующем экране. Экран выборочной установки (рис. 8 1) по умолчанию имеет только один элемент, помеченный как «не устанавливать», — собственно SDK. Щелкните узел SDK и выберите Entire Feature Will Be Installed On Local Hard Drive (все функции будут установлены на локальный диск). Установоч ный каталог SDK называется также SDK и размещен в основном каталоге Debugging Tools for Windows.

Что делает WinDBG немного странным, так это то, что вы и я полагаем, что UI находится совсем не там, где выполняется основная работа. Этот UI просто явля ется внешним представлением собственно механизма отладки, именуемого DBGENG.DLL. Многие в командах разработчиков ОС Microsoft привыкли к отлад чику NTSD (Microsoft NT Symbolic Debugger, символический отладчик Microsoft NT). NTSD — это консольное приложение, являющееся в Debugging Tools for Windows консольным уровнем над механизмом отладки, входит в состав установочного комплекта Debugging Tools for Windows. Это значит, что, зная, как работать с WinDBG, вы легко привыкнете и к NTSD. Кроме того, я предпочитаю простоту гра фического интерфейса, а вы, возможно, захотите присмотреться к NTSD, так как он будет отпугивать некоторых блуждающих руководителей, любящих сидеть в вашем офисе и заглядывать вам через плечо, наблюдая, как вы работаете. В табл. 8 1 перечислены наиболее интересные программы для разработчиков пользова тельского режима, которые устанавливаются в составе Debugging Tools for Windows.

Рис. 8 1. Выбрана установка SDK в составе Debugging Tools for Windows

Табл. 8-1. Дополнительные средства, устанавливаемые в составе Debugging Tools for Windows

Самый большой плюс WinDBG даже не в том, что он делает больше, автомати чески выслеживая непокорные ошибки, а в том, что к нему прилагается действи тельно хорошая документация. Перед первым запуском WinDBG надо открыть файл DEBUGGER.CHM и почитать его. Имейте при этом в виду, что большая часть силь ных сторон WinDBG относится к отладке в режиме ядра, поэтому вы можете спо койно пропустить эти разделы, пока не займетесь разработкой драйверов. Озна комившись с разделом «Installation and Setup» (установка и настройка) и всем, что относится к пользовательскому режиму в разделе «Debugger Operation» (процесс отладки), как я уже говорил в главе 2, нужно полностью прочитать раздел «Symbols» (символы). В разделе «Debugging Techniques» (приемы отладки) обязательно про

326 ЧАСТЬ II Производительная отладка

чтите «Elementary Debugging Techniques» (элементарные приемы отладки), «Stack Traces» (трассировка стека) и «Processor Architecture» (архитектура процессора). Так как окно Command (команды) является в WinDBG всем, потратьте время на чтение содержимого раздела «Reference» (ссылки), в особенности «Debugger Com mands» (команды отладчика) и «Debugger Extension Commands» (команды расши рения отладчика).

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

Основы

Самые большие проблемы WinDBG — его настройка и огромный объем выход ных данных. Я помогу вам преодолеть кое какие преграды, чтобы изучение WinDBG не было слишком болезненным. В заключение я освещу некоторые странности, чтобы они вас не удивляли.

Первым делом запомните, что WinDBG — это разновидность ретро отладчи ка. Черт, консольный NTSD должен вызывать слезы на глазах старых программи стов! Но это немного вам поможет. Visual Studio .NET поможет вам при поиске символов и работе с исходным кодом, тогда как для WinDBG вы должны точно сообщить, куда смотреть, чтобы найти то, что нужно. При отладке программы, собранной на той же машине, компилятор и компоновщик Microsoft Visual C++

.NET «знают» размещение символов, а внутри PDB «прописаны» пути ко всем ис ходным файлам, в результате чего у вас не будет никаких проблем. Однако для сбора информации о символах и строках текста, если программа собиралась не на той машине, где производится отладка, потребуются усилия.

В главе 2 я представлял технологию сервера символов, являющуюся одним из важнейших достижений в отладке для Windows за все время. К этому моменту у вас должен быть настроен собственный сервер символов и установлена переменная среды _NT_SYMBOL_PATH, чтобы Visual Studio .NET использовал сервер символов. WinDBG будет автоматически вызывать переменную _NT_SYMBOL_PATH в качестве базового пути символов. WinDBG использует рабочие пространства для сохране ния нужной информации о каждом отлаживаемом процессе, такой как точки прерывания, размещение окон и пути символов. Сразу после запуска, еще до от крытия процесса, WinDBG позволяет изменить параметры базового рабочего пространства, откуда все остальные будут наследовать свои параметры. Вы узна ете, что находитесь в базовом рабочем пространстве по тому, что дочерние окна MDI открыты во фрейме WinDBG. Используя параметры базового рабочего про странства с общими данными, необходимыми для всех процессов, вы избавите себя от огромного количества препятствий.

Настроив переменную среды _NT_SYMBOL_PATH, надо сообщить WinDBG, где ис кать общие исходные файлы. Хоть и можно задать пути к исходным файлам в переменной среды _NT_SYMBOL_PATH (детали см. в файле DEBUGGER.CHM), есть способ попроще. Откройте базовое рабочее пространство в WinDBG, щелкните в меню File (файл), Source File Path (путь к исходным файлам), чтобы открылось диало говое окно Source File Path, в котором вы введете пути к размещению общих ис ходных файлов. По минимуму вам всегда будет нужен путь к исходным файлам библиотеки времени высполнения C и исходным кодам MFC/ATL, поэтому надо ввести что то похожее на такую последовательность (заметьте: я отделил пути друг от друга, чтобы они легче воспринимались, но вводить их нужно в одной строке):

<Visual Studio .NET Installation Dir>\vc7\crt\src;

<Visual Studio .NET Installation Dir>\vc7\crt\src\intel;

<Visual Studio .NET Installation Dir>\vc7\atlmfc\include;

<Visual Studio .NET Installation Dir>\vc7\atlmfc\src\mfc;

<Visual Studio .NET Installation Dir>\vc7\atlmfc\src\atl;

<Visual Studio .NET Installation Dir>\vc7\atlmfc\src\atl\atls;

<Visual Studio .NET Installation Dir>\vc7\atlmfc\src\atl\atlmincrt;

Каталоги разделяются точкой с запятой — так же, как это делается при обыч ной записи. Если вы и впрямь горите желанием использовать NTSD, установите такое же значение переменной среды _NT_SOURCE_PATH.

Последнее, что надо настроить, — это путь к образу исполняемого файла, ко торый нужен WinDBG для поиска двоичных файлов. Если вы производите отлад ку в реальном времени, то WinDBG автоматически найдет файлы и загрузит их. Если же вы собираетесь отлаживать минидампы, в которых WinDBG превосходен, надо указать WinDBG, где искать двоичные файлы. Если вы следовали моим реко мендациям в главе 2 при настройке сервера символов, то вы уже поместили сим волы ОС, вашей разработки и двоичные файлы в ваш сервер символов. Путь к ис полняемым файлам можно задать в базовом рабочем пространстве путем выбора из меню File, Image File Path (путь к двоичным файлам) и ввода той же строки, что применяется в качестве пути к символам, или значения переменной среды _NT_SYMBOL_PATH. WinDBG достаточно умен, чтобы корректно работать, получая информацию о двоичных файлах непосредственно от вашего сервера символов.

WinDBG может работать с минидампами независимо от того, откуда они по лучены: от заказчика или с машины начальника. Так что, даже если вы настроили переменную среды _NT_EXECUTABLE_IMAGE_PATH, чтобы указать Visual Studio .NET, где искать исполняемые файлы, Visual Studio .NET их не загрузит. Так как минидампы столь важны для поиска проблем у заказчика (в промышленных условиях), WinDBG жизненно важен, чтобы убить все ошибки.

Открывая процессы для «живой» отладки или отладки минидампов, вы сможе те обновить каждое из этих рабочих пространств символами, путями к исходным текстам и двоичным файлам для каждого проекта в отдельности. Каждый раз, когда вы меняете что либо в рабочем пространстве, включающем в себя установленные точки прерывания, пути к символьным, исходным и двоичным файлам, а также расположение окон, WinDBG будет предлагать сохранить рабочее пространство, прежде чем его закрыть. Поэтому, возможно, в ваших интересах будет всегда со хранять рабочее пространство. Вы можете удалить неиспользуемые рабочие про

328 ЧАСТЬ II Производительная отладка

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

В заключение вам может понадобиться выделять в окне Command важную информацию цветом. Если вы никогда раньше не запускали WinDBG, то замети те, что он крайне разговорчив. Все происходит в окне Command, и очень легко пропустить что то важное. Просто загрузка большого процесса может в резуль тате изрыгнуть более 100 строк! К счастью, WinDBG сейчас позволяет раскрасить выходную информацию, так что вы можете отделить зерна от плевел. Цветовые параметры находятся в нижней части диалогового окна Options (настройки), вы зываемого выбором Options из меню View (вид).

Плохие новости в том, что значения цветовых элементов недостаточно доку ментированы. Некоторые из этих раскрашиваемых элементов, такие как Enabled Breakpoint Background (фон действующей точки прерывания), не требуют объяс нений, но другие, скажем, Error Level Command Window Text (текст уровня ошиб ки в окне команд), только кажутся понятными: я никогда не видел выбранного мной цвета. На самом деле главное — «подсветить» все вызовы TRACE и OutputDebugString, производимые вашей программой. Вы можете настроить вывод этих важных дан ных другим цветом, установив цвет Debuggee Level Command Window Text (текст уровня отлаживаемой программы в окне команд). Лично я всегда выбираю зеле ный, так как он показывает, что все хорошо.

Чтобы избавить вас от скачков кровяного давления, хочу отметить несколько странностей WinDBG. Первая странность относится к тому, что происходит при завершении вашего процесса. В Visual Studio .NET при завершении процесса на жатие F5 перезапустит отладку. В WinDBG случаются одна или две вещи. Если вы открываете процесс, выбрав Open Executable (открыть исполняемый файл) из меню File, нажатие F5, возможно, предложит вам сохранить рабочее пространство. После щелчка кнопки в информационном окне с запросом рабочее пространство чудес ным образом закрывается, а вы видите WinDBG, в котором нет открытого рабо чего пространства. Если вам повезет запустить WinDBG для отладки программы из командной строки, нажатие F5 по завершении процесса снова предложит вам сохранить рабочее пространство. Теперь, после подтверждения сохранения ра бочего пространства, WinDBG работает! Да, это совершенно противоестествен но, но так устроен WinDBG. Если вам надо перезапустить отладку, выберите Restart (перезапустить) из меню Debug (отладка) или нажмите Ctrl+Shift+F5.

И, наконец, WinDBG — это полный бред, что касается положения окон. Он размещает дочернее окно там, где нравится ему, а не вам! Если вы устали от вы скакивающих окон при попытке переместить дочернее окно сообщений, отклю чите пункт Auto Arrange (размещать автоматически) в меню Window (окно). Хотя WinDBG местами слегка груб, я прощаю это из за той силы, которую он привно сит в отладку.

Прежде чем заняться окном Command, я предлагаю вам день два попользоваться WinDBG как обычным графическим отладчиком. С ним можно работать, как с обычным отладчиком уровня исходного кода, поэтому вы можете открыть исход ный файл, установить курсор на строку и нажать F9 для установки точки преры вания. Так как WinDBG не загружает файлы символов, до того как они понадобят

ся, возможно, вы увидите предложение загрузить символы. Всегда щелкайте Yes, и все должно быть хорошо. О проблемах загрузки символов мы еще поговорим. В дополнение к окнам Source (исходный текст) меню View (вид) предлагает раз личные типы окон. WinDBG имеет полный комплект окон отладки, таких как Registers (регистры), Memory (память) и Locals (локальные переменные). Интересно, что он имеет также окно Scratch Pad (блокнот для заметок), если вы столь лени вы, чтобы нажимать Alt+Tab для доступа к Notepad (Блокнот) для вставки в него отладочной информации или записи заметок. Как вы увидите, начав пользовать ся WinDBG, блестящим интерфейсом Visual Studio .NET он не располагает и все же определенно полезен.

Общий вопрос отладки

Как изменить аргумент командной строки своего процесса, если он открыт в WinDBG?

Увы, никак. После того как вы открыли процесс, единственный способ за пустить отлаживаемую программу еще раз с другими параметрами коман дной строки — это закрыть рабочее пространство и либо открыть процесс заново с новыми аргументами через диалоговое окно Open Executable, либо перезапустить WinDBG с новыми параметрами.

Параметры командной строки можно задать одним из двух способов. Первый: в диалоговом окне Open Executable. На рис. 8 2 показано диалого вое окно Open Executable; выделенная область (строка ввода Arguments) — это то место, где вы вводите параметры, передаваемые в командной строке отлаживаемой программе.

Рис. 8 2. Диалоговое окно WinDBG Open Executable

Другой вариант задания параметров командной строки — ввести па раметры отлаживаемой программы после ее имени в командной строке WinDBG.

330 ЧАСТЬ II Производительная отладка

Что случается при отладке

Теперь, когда у вас есть общее представление о том, что может делать WinDBG и как избежать некоторые присущие ему проблемы, я хочу объяснить, как оседлать его с помощью окна Command. Окно Command является вершиной всего в WinDBG и, хотя его труднее познать, чем воспользоваться графическим интерфейсом, вы сможете отлаживать гораздо быстрее, познакомившись с его командами. Все опре деляется тем, сколь много усилий вы хотите приложить.

Прежде чем ринуться в чащу команд, надо выяснить парочку вопросов. Во первых, напомню, что нажатие Alt+1 в процессе отладки выводит окно Command наверх и центрирует его. Во вторых, это синтаксис вычисления адреса, так как очень многие команды базируются на нем. Главный способ указания одиночного адреса, основанного на символе, — использование формата module!symbol (мо дуль/символ), при этом module и symbol чувствительны к регистру. Так, для полу чения адреса LoadLibraryW вводим kernel32!LoadLibraryW. Для задания адреса, осно ванного на имени исходного файла и номере строки, правила ввода — '[[mo dule!]filename][:linenumber]' ('[[имя модуля!]имя файла][:номер строки]'). Об ратите особое внимание на разделители — это гравис ('). Имя модуля и имя фай ла необязательны. Если вы пропустили имя модуля ('foo.cpp:23'), WinDBG про смотрит символы во всех загруженных модулях. Пропуск имени файла (':23') предполагает использование файла, которому принадлежит текущий выполня емый оператор.

WinDBG имеет три типа команд. Стандартные команды (regular commands) управляют отлаживаемой программой. Например, трассировка (tracing), исполне ние по шагам (stepping) и просмотр памяти — это стандартные команды. Мета команды (meta commands; их также называют точка командами) в основном управ ляют отладчиком и действиями отладки. Например, создание файлов регистрации, присоединение к процессам и запись файлов дампа это мета команды. Команды расширения (extension commands) производят некоторые действия в отлаживае мой программе и производят анализ ситуаций или состояний. Примеры команд расширения включают вывод описателей, анализ критических секций и анализ аварийного завершения.

Получение помощи

Когда вы начинаете с мерцающего курсора в нижней строке окна Command, ду мая, какая же нужна команда, обратитесь к справочной системе. Если вам доста точно получить подсказку об имени стандартной команды или ее синтаксисе, введите ? (Command Help — справка по командам), и появится пара страниц со списком, где можно познакомиться с информацией о стандартных командах. Не которые стандартные команды имеют поддержку ввода ? в качестве параметра, для них вы получите быструю помощь по применению параметров. Вам придет ся использовать метод проб и ошибок для выяснения, какие из них поддержива ют ?. Чтобы увидеть список мета команд, введите .help (Meta command Help — справка по мета командам). Так как справочная система по расширенным коман дам выполнена, как будто ее писали от случая к случаю, то синтаксис этих команд