Операционная система Windows 2000, несомненно, значительно надежнее предыдущих версий. Благодаря большей устойчивости ядра, тщательному тестированию и новому инструменту DriverVerifier на компьютерах, работающих под Windows 2000, редко появляются «голубые экраны». Однако во многих корпорациях по-прежнему широко используется Windows NT 4.0. И хотя драйверы устройств, поставляемые в составе Windows 2000, проходят специальную проверку, чтобы получить сертификат лаборатории качества аппаратных средств Windows Hardware Quality Labs (WHQL) компании Microsoft, в них могут оставаться скрытые ошибки. Кроме того, если установить приложения, в составе которых имеются неаппаратные драйверы: например, программы поиска вирусов, утилиты распределения квот или пакеты шифрования, то в системе Windows 2000 появятся драйверы, не прошедшие испытаний в лаборатории WHQL. Это возможно даже в том случае, когда политика использования только подписанных драйверов вроде бы запрещает использование чужих непротестированных устройств. Таким образом, «голубые экраны» будут появляться реже. Однако аварийные ситуации неизбежны, и от того, владеет ли пользователь нужной информацией, зависит, придется ему затратить несколько минут на переустановку одной прикладной программы или несколько часов на полную замену операционной системы.

Многие системные администраторы пренебрегают анализом аварийных дампов Windows 2000 и NT 4.0, полагая, что работать с ними слишком трудно. Хотя за прошедший год документация Microsoft по отладчику стала лучше, она все еще ориентирована на программистов драйверов устройств. Но даже если всего в одном дампе из пяти удастся отыскать полезную информацию, усилия, потраченные на освоение простейших приемов анализа аварийного дампа, будут не напрасны.

Далее я представлю основные методы настройки конфигурации системы для сохранения дампа памяти при системном сбое, расскажу, где найти инструменты для анализа аварийного дампа, и покажу, как выбирать из дампа информацию. Кроме того, я познакомлю читателей с автоматизированным инструментом анализа дампа - Kernel Memory Space Analyzer (Kanalyze).

Активизация аварийного дампа

Для начала нужно позаботиться о том, чтобы после системного сбоя дамп памяти был создан. Доступ к настройкам аварийного дампа NT 4.0 можно получить через закладку Startup/Shutdown приложения System в Control Panel. На Экране 1 показана закладка Startup/Shutdown, на которой нужно выбрать флажок Write debugging information to («Записывать отладочную информацию в…») и ввести имя файла, в котором следует сохранить дамп. Остальные параметры на странице определяют поведение системы в случае сбоя: запись информации о событии в системный журнал, пересылка оповещения администратору и автоматическая перезагрузка.

Экран 1. Параметры аварийного дампа NT 4.0.

Поскольку в файлах аварийных дампов NT 4.0 хранится копия данных из физической памяти компьютера, необходимо убедиться, что на диске достаточно места для записи дампа. Во-первых, следует настроить файл подкачки на загрузочном томе (на котором находится каталог winnt). Размер файла подкачки должен быть больше, чем объем системной памяти плюс 1 Мбайт. Свободное пространство тома, на котором хранится файл дампа (по умолчанию он же загрузочный том), должно быть немного больше объема физической памяти компьютера.

Эти требования вытекают из способа сохранения дампа ядром. Во время загрузки операционная система проверяет параметры создания аварийного дампа в разделе реестра HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlCrashControl. Если один или несколько параметров указаны, то система генерирует карту блоков диска, занимаемых файлом подкачки на загрузочном томе, и сохраняет ее в памяти. Система также определяет, какой драйвер дискового устройства управляет загрузочным томом, вычисляет контрольные суммы для образа драйвера в памяти и для структур данных, которые должны быть целыми, чтобы драйвер мог выполнять операции ввода/вывода. После сбоя ядро системы проверяет целостность карты страничного файла, дискового драйвера и управляющих структур дискового драйвера. Если эти структуры не испорчены, то ядро вызывает специальные функции ввода/вывода дискового драйвера, предназначенные для сохранения образа памяти после системного сбоя. Эти функции ввода/вывода самодостаточны и не полагаются на службы ядра, поскольку в программах, отвечающих за запись аварийного дампа, нельзя делать никаких предположений о том, какие части ядра или драйверы устройств при сбое были повреждены. Ядро записывает данные из памяти по карте секторов файла подкачки, и ему не приходится использовать драйверы файловой системы. Прежде чем выполнить операцию, ядро проверяет состояние каждого компонента, задействованного в процессе сохранения дампа. Это делается для того, чтобы при прямой записи в секторы диска не повредить данные, лежащие вне страничного файла. Размер страничного файла должен быть на 1 Мбайт больше размера физической памяти, потому что при записи информации в дамп создается заголовок, в котором содержатся сигнатура аварийного дампа и значения нескольких важнейших переменных ядра. Заголовок занимает меньше 1 Мбайт, но операционная система увеличивает размер файла подкачки сразу по мегабайту.

После загрузки системы процесс Session Manager (winntsystem32smss.exe) инициализирует страничные файлы системы, используя для создания каждого файла собственную функцию NtCreatePagingFile. NtCreatePagingFile определяет, существует ли инициализируемый страничный файл, и если да, то имеется ли в нем заголовок дампа. Если заголовок есть, то NtCreatePagingFile посылает в Session Manager специальный код. В результате, когда Session Manager выполняет программу регистрации (winntsystem32winlogon.exe), запуская процесс Winlogon, он извещает Winlogon о существовании аварийного дампа. Тогда Winlogon выполняет программу SaveDump (winntsystem32savedump.exe), которая анализирует заголовок дампа и определяет дальнейшие действия в аварийной ситуации. Если заголовок указывает на существование дампа, то SaveDump копирует данные из страничного файла в файл аварийного дампа, имя которого было выбрано пользователем в диалоговом окне Startup/Shutdown. Пока SaveDump переписывает файл дампа, операционная система не задействует ту часть страничного файла, в которой содержится аварийный дамп. В это время объем виртуальной памяти, доступной для системы и приложений, уменьшается на размер дампа, и на экране могут появиться сообщения, указывающие на нехватку виртуальной памяти. Затем SaveDump информирует диспетчер памяти о завершении сохранения дампа, и тот высвобождает ту часть страничного файла, в которой хранится дамп, для общего пользования. Сохранив файл дампа, SaveDump выполняет другие заданные аварийные операции: например, посылает администратору предупреждение и записывает событие в системном журнале.

Копия содержимого системной памяти в момент сбоя часто содержит информацию, которая для анализа не пригодится. Сбой вызывается ошибкой в работе приложения режима ядра, поэтому данные о выполнении приложения пользовательского режима, как правило, не имеют отношения к аварии. К памяти режима ядра относятся все структуры данных операционной системы и драйверов, а также исполняемый код драйверов устройств и ядра, поэтому в Windows 2000 реализована возможность сохранения в аварийном дампе только памяти режима ядра. Это позволяет существенно уменьшить размеры файла аварийного дампа, его можно быстрее создать и копировать, проще хранить и пересылать обслуживающему персоналу. На типичной машине емкостью памяти 128 Мбайт размер дампа памяти ядра может составлять всего 40 Мбайт. На Экране 2 показано окно параметров аварийного завершения Startup and Recovery операционной системы Windows 2000, которое можно увидеть, щелкнув на кнопке Startup and Recovery закладки Advanced приложения System.

Экран 2. Сохранение только памяти ядра.

В Windows 2000 также предусмотрен режим мини-дампов. Мини-дампы, которые в раскрывающемся списке Write Debugging Information диалогового окна Startup and Recovery называются малыми дампами памяти (Small Memory Dumps), представляют собой 64-килобайтные аварийные дампы для хранения минимума необходимых данных. Сюда входят аварийный код «голубого экрана», список загруженных драйверов, информация о процессах и потоках, которые выполнялись во время сбоя, и «моментальный снимок» стека (т. е. список недавно вызывавшихся функций). Иногда достаточно ознакомиться с данными мини-дампа, в сущности, повторяющими информацию на «голубом экране» NT 4.0, чтобы догадаться о причине сбоя. Мини-дампы малы по размеру и не уничтожают прежних мини-дампов. Имя мини-дампа имеет формат minimmddyynn.dmp, где mm, dd и yy - месяц, день и год соответственно, а nn - уникальный номер для различия мини-дампов, созданных в один день. По умолчанию, Windows 2000 сохраняет файлы мини-дампов в каталоге \%systemroot%minidump. Для анализа мини-дампов используются те же приемы, что и для анализа полных дампов и дампов ядра. Однако при наличии необходимого пространства на диске я рекомендую генерировать дампы режима ядра.

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

Бывает, что дамп сохранить невозможно из-за повреждения некорректным драйвером структур данных или программного кода, необходимого для сохранения дампа. В таких случаях программный код не выполняется или контрольные суммы свидетельствуют об изменениях в компонентах драйверов диска, и ядро не записывает дамп во избежание порчи данных на диске. Кроме того, в недописанных дисковых драйверах (не редкость для NT 4.0) не реализованы специальные подпрограммы ввода/вывода, необходимые для записи дампа. Функции вывода аварийного дампа обязательно имеются во всех драйверах с цифровой подписью от Microsoft, поэтому проблема не затронет компьютеры, работающие под Windows 2000, на которых установлены только сертифицированные драйверы.

Чтобы проверить, может ли система создать аварийный дамп, следует загрузить программу BSOD по адресу: http://www.sysinternals.com/bluesave.htm, и запустить ее после того, как машина проведет в бездействии по крайней мере минуту. Как только пользователь подтвердит свое намерение вызвать системный сбой, программа BSOD инсталлирует драйвер устройства, который занимает часть памяти ядра, освобождает ее, а затем обращается к освобожденной памяти через высокоуровневый запрос прерывания (IRQL). Обращение к освобожденной памяти и обращение к памяти через высокоуровневый IRQL - незаконные операции, поэтому в результате действий BSOD крах системы гарантирован.

Аналитические инструменты

Настроив операционную систему для генерации аварийных дампов и проверив, что она успешно справляется с этой задачей, необходимо приобрести инструменты анализа дампа и соответствующие файлы данных. Самое важное - иметь символьные файлы, по крайней мере, для файла ядра ntoskrnl.exe. В символьных файлах определены имена внутренних функций и переменных соответствующего модуля, и эта информация может пригодиться для анализа аварийного дампа. По возможности следует получить и установить все символьные файлы. Символьные файлы специфичны для конкретных пакетов исправлений, поэтому необходимо убедиться, что они соответствуют версии SP.

Символьные файлы для английской версии NT 4.0 находятся в каталоге ussyswinntwinnt-publicfixesusa t40 бесплатного ftp-сервера Microsoft по адресу: ftp://ftp.microsoft.com. Символьные файлы для других языков хранятся в соответствующих подкаталогах ussyswinntwinnt-publicfixes. Символы для исходной версии Windows 2000 размещены на компакт-диске Customer Support Diagnostic. После того как компакт-диск вставлен в накопитель, открывается Web-страница, имеющая ссылку на утилиту извлечения символьных файлов. Символы для Windows 2000 Service Pack 1 (SP1) можно загрузить с http://www.microsoft.com/windows2000/ downloads/recommended/sp1/debug/ fWindows 2000 default.asp. Для установки символьных файлов существует стандартный каталог - winntsymbols, но их можно разместить где угодно. Чтобы упростить работу с программами анализа, следует заранее определить переменную среды _NT_SYMBOL_PATH, указывающую на каталог, где размещены символьные файлы (например, если это каталог winntsymbols, нужно указать путь winntsymbols).

Затем необходимо установить инструменты аварийного анализа. Хотя отладочные программы можно найти на компакт-диске NT 4.0 и диске Windows 2000 Customer Support Diagnostic, лучше загрузить исправленную и усовершенствованную версию по адресу: http://www.microsoft.com/ ddk/debugging/ debuggingdownload.htm. Программы рекомендуется поместить в каталог, например C:debuggers, доступ к которому можно получить из командной строки.

Кроме того, требуется загрузить инструменты OEM Support Tools, описанные в статье Microsoft «OEM Support Tools Phase 3 Service Release 2 Availability» (http://support.microsoft.com/ support/kb/articles/q253/0/66.asp). К ним относятся модули расширения для базовых средств отладки. Я рекомендую загрузить Zip-файл, а извлеченные из него инструменты поместить в каталог, но не в тот, где хранятся прочие инструменты отладки. Информацию об OEM Support Tools можно найти в файле starthere.htm из каталога Install. Периодически следует обращаться к OEM Support Tools и другим страницам, посвященным отладочным инструментам, в поисках обновленных версий.

Автоматический анализ с помощью программы Kanalyze

Установив символьные файлы и утилиты, можно приступать к анализу аварийного дампа. Сначала следует загрузить и запустить программу BSOD. Всем, кто когда-либо анализировал аварийные дампы с помощью отладочных инструментов с установочного компакт-диска NT 4.0 или диска Windows 2000 Customer Support Diagnostic, вероятно, приходилось использовать утилиту DumpChk для проверки корректности файла дампа и DumpExam - для подготовки отчета. В новых наборах отладочных инструментов DumpChk и DumpExam не нужны. На смену им пришел Kanalyze, инструмент автоматизированного анализа аварийного дампа.

Kanalyze - механизм анализа дампа, к которому можно подключать дополнительные библиотеки (plug-ins) DLL. Достаточно ознакомиться с двумя типами таких модулей. Один отыскивает и идентифицирует интересующие пользователя элементы дампа; другой анализирует элементы, обнаруженные модулями первого типа (некоторые модули относятся к обоим типам). Например, некоторые модули отыскивают и идентифицируют адреса загруженных в память драйверов, выделенные блоки памяти и пакеты запросов ввода/вывода. Соответствующие аналитические сменные модули проверяют, все ли выделенные блоки памяти идентифицированы, не отличаются ли загруженные образы драйверов от их копий на диске и не нарушены ли пакеты запросов ввода/вывода. На стадии анализа с помощью этих модулей отмечаются аномалии и делаются предположения (например, о вероятных причинах сбоя). Однако еще на этапе обнаружения элементов Kanalyze отмечает все ситуации, когда область памяти, выделенная одному элементу, перекрывается областью памяти другого элемента, но не входит в нее целиком. Если программный код драйвера целиком содержится в выделенном блоке памяти, то Kanalyze рассматривает как подозрительную ситуацию, при которой код драйвера захватывает два блока или частично размещается в «чужой» области.

Вместе с Kanalyze поставляется документация (к ней можно обратиться через Help-файл Kanalyze), с помощью которой независимые программисты могут создавать свои подключаемые DLL, но в состав продукта входит и несколько динамических библиотек Microsoft. Например, memory.dll идентифицирует блоки памяти, module.dll идентифицирует области кода и данных драйвера, а kobjects.dll отыскивает в дампе объекты ядра.

Еще одна мощная функция Kanalyze позволяет генерировать сигнатурный ID-файл, содержащий важную информацию о сбое, которую можно хранить в базе данных. После завершения анализа Kanalyze отыскивает в базе данных сигнатуры, сходные с полученной в ходе анализа. Таким образом, Kanalyze обнаруживает сбои, имеющие общую причину, а пользователь может выявить закономерности и в дальнейшем применять свои знания при сбоях на других компьютерах. Чтобы хранить данные Kanalyze в базе данных, необходимо установить Microsoft SQL Server 7.0 или более позднюю версию продукта.

Поскольку OEM Support Tools загружается из архива, чтобы запустить Kanalyze, следует открыть окно командной строки, перейти в каталог, в котором установлен набор OEM Support Tools, и ввести с клавиатуры Kanalyze.

Программа потребует указать местоположение анализируемого дампа и местоположение символьных файлов. Если SQL Server не установлен и пользователь не собирается работать с базой данных Kanalyze, то на странице «What would you like to do?», показанной на Экране 3, следует выбрать второе положение переключателя.

Экран 3. Задание способа анализа дампа.

Когда пользователь укажет файл аварийного дампа, мастер отображает код остановки и параметры аварийного дампа (именуемые в Kanalyze кодами и параметрами BugCheck). Драйвер или компонент ядра, вызывающий крах системы, использует код остановки для классификации причин этого события. Сбой, вызванный с помощью программы BSOD, имеет код останова 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) в Windows 2000 и 0xA (IRQL_NOT_LESS_OR_EQUAL) в NT 4.0. Компания Microsoft постоянно обновляет базу знаний Knowledge Base с описанием различных кодов остановки и предоставляет ссылки на модули коррекции, новые версии драйверов и обходные приемы. Чтобы получить информацию о каком-либо коде остановки, нужно ввести с клавиатуры Stop и номер этого кода в поисковом окне Knowledge Base. Примером статьи, найденной в результате такого поиска, может служить «Bugcheck 0x000000D1 Caused by Dlc.sys» (http://support.microsoft.com/ support/kb/articles/q266/2/21.asp), в которой объясняется, каким образом драйвер Windows 2000 Data Link Control (DLC) может вызвать появление кода остановки 0xD1, и дается ссылка на модуль коррекции для драйвера.

Если в базе знаний Knowledge Base не удается получить информацию о причинах сбоя, нужно перейти к следующему экрану Kanalyze, который запрашивает о местоположении символьных файлов. Kanalyze загружает эти файлы для всех модулей ядра, обнаруженных в дампе. Эта страница информирует об отсутствующих символьных файлах (у драйверов производства независимых компаний обычно их нет) и файлах, не совпадающих с загруженными модулями. Предупреждения о несоответствии означают, что установленные символьные файлы, возможно, устарели в результате установки пакета исправлений или модуля коррекции.

На следующей странице мастера перечислены подключаемые модули, которые будут загружены для анализа аварийного дампа. Далее Kanalyze последовательно вызывает эти DLL для поиска элементов и анализа полученной информации. Процесс выполнения всех операций отображается на экране. На этапе [KA_START_LO-CATE_ITEMS] осуществляется поиск элементов в аварийном дампе, а на этапе [KA_PERFORM_ANALYSIS] запускаются все аналитические модули. По завершении стадии анализа Kanalyze ожидает, когда пользователь перейдет к последней странице мастера, где представлены результаты анализа.

Экран 4. Кнопка View активизирована, можно проводить анализ.

Если кнопка View в области Analysis Conclusions страницы Results доступна, значит, один или несколько подключаемых модулей определили вероятную причину сбоя. Если запустить Kanalyze для обработки дампа, созданного программой BSOD, то кнопка View активизируется, как показано на Экране 4. По щелчку на кнопке View на экран выводится окно Namespace Browser со списком обнаруженных ошибок, показанное на Экране 5. В окне содержится сообщение, что сменный модуль STOPCODE считает «виновником» сбоя драйвер crashdd.sys. В окне Namespace Browser даже показан снимок стека (на Экране 5 не виден), из которого ясно, что функция IopLoadUn-loadDriver в Ntoskrnl (ядро) вызвала функцию в crashdd.sys, а crashdd.sys затем вызвала KiTrap0E в Ntoskrnl. Если в аварийном дампе обнаружена функция, в названии которой есть слово Trap или Exception, значит, скорее всего, программный код ядра обратился к неверному указателю, что и привело к краху системы. Если сбой вызван программой BSOD, обращение crashdd.sys к неверной области памяти приводит к вызову trap-функции (реакция на исключительную ситуацию), и Kanalyze точно определяет причину сбоя.

Экран 5. Просмотр обнаруженных проблем.

Я не рекомендую просматривать область Anomalous conditions страницы Results. Модули Plug-in многие ситуации необоснованно воспринимают как подозрительные. На странице результатов имеется кнопка View для области Information from data base (информация из базы данных), с помощью которой можно сравнить полученную информацию о сбое с информацией из базы данных. Если на машине SQL Server не установлен, воспользоваться этой функцией невозможно.

Последняя кнопка на странице результатов, Advanced, обеспечивает просмотр обнаруженных элементов; ею можно воспользоваться для ручного анализа. Элементы разделены по типам, далее в иерархической структуре расположены задаваемые подключаемыми модулями подэлементы. Например, папка Module, которую создает модуль Module, имеет подпапки для областей памяти, занимаемых программным кодом драйвера и ядра, данными и заголовком изображения (содержащим информацию о структуре изображения). Может быть полезной подпапка Process папки ExecutiveObject, показанная на Экране 6. В ней перечислены все процессы, выполняемые в системе в момент сбоя, и собрана подробная информация об использовании памяти каждым процессом.

Экран 6. Процессы, выполнявшиеся в момент сбоя.

Если с помощью Kanalyze определить причину сбоя не удается, аварийный дамп можно исследовать вручную, пытаясь отыскать детали, ускользнувшие от внимания Kanalyze. Для ручного анализа предназначены два инструмента из набора OEM Support Tools: WinDbg (или Win Debug) и Kd (в ранних версиях называвшийся i386kd). Эти утилиты имеют идентичные наборы команд и функции работы с данными в дампе, только WinDbg - графическое приложение Windows, а Kd - программа, запускаемая из командной строки. Я рекомендую работать с WinDbg, в которой проще копировать значения и использовать подокна.

Чтобы задействовать WinDbg для анализа аварийного дампа, следует в ответ на командное приглашение ввести с клавиатуры:

windbg -z  -y .

Если определена переменная _NT_SYMBOL_PATH, то параметр -y можно не указывать. Вид окна WinDbg показан на Экране 7. После этого можно воспользоваться несколькими отладочными командами, которые покажут различные параметры системы в момент сбоя. Отладочная среда состоит из трех типов команд: встроенные отладочные команды, не имеющие префикса; dot-команды, имеющие префикс-точку; bang-команды с префиксом в виде восклицательного знака (!).

Экран 7. Просмотр результатов WinDbg.

Самая полезная встроенная отладочная команда - Dd, она показывает дамп области памяти. Команда dd esp формирует дамп области памяти, на которую указывает регистр указателя стека (т. е. регистр esp). Однако тем, кто не знаком с языком ассемблера x86, esp-дампы не пригодятся. Команда ? служит для доступа к оперативной подсказке по отладочным командам.

С помощью dot-команд можно загружать и выгружать подключаемые библиотеки DLL-отладчика (так называемые библиотеки расширения отладчика) и управлять отлаживаемым объектом. Объект - это исследуемая операционная система. Использование dot-команды, как и встроенных команд, требует углубленных знаний, в противном случае для анализа аварийного дампа они попросту бесполезны.

В библиотеках расширения отладчика реализованы bang-команды. WinDbg и Kd для исследования ядра kdextx86.dll автоматически загружают базовую DLL расширения, в которой содержатся команды отображения информации о различных объектах ядра Windows 2000 или NT. Сначала следует собрать основные данные, запустив команду !process pid. Эта команда извлекает из дампа информацию о процессе, исполнявшемся в момент сбоя. Чтобы получить полный список процессов, следует воспользоваться командой !process 0 0. Команда !thread tid собирает сведения об исполнявшемся потоке, в том числе состоянии его стека. Информация о том, какой процесс выполнялся в момент сбоя, может послужить ключом к пониманию причины этого события, а в стеке может быть указан драйвер, вызвавший сбой. Если выполнить команду !thread tid для аварийного дампа, созданного с помощью программы BSOD, то в стеке будет указан crashdd.sys.

Если справа от линии трассировки стека содержится такой текст, как TrapFrame @ 8013eee8, следует запустить команду .trap nnnn, где nnnn - шестнадцатеричное число после амперсанда в тексте (8013eee8 в нашем примере). Затем нужно выполнить команду Kv. WinDbg покажет трассировку стека кадра прерывания, который отражает состояние стека перед тем, как управление было передано обработчику исключительной ситуации. WinDbg не всегда точно воспроизводит трассировку стека, но, когда, это удается, в кадре прерывания можно увидеть последовательность событий, приведшую к сбою. Следует попытаться отыскать в базе знаний Knowledge Base имена всех драйверов, указанных в трассировке стека, на случай, если данная проблема документирована. Рекомендации для самостоятельного анализа стека содержатся в файле WinDbg Help.

Команда !drivers извлекает из дампа список загруженных драйверов, в котором содержатся некоторые сведения из сообщения «голубого экрана» NT 4.0. Эта команда показывает дату создания драйвера, что позволяет вовремя обратить внимание на устаревшие драйверы. Информацию об обновленных версиях драйверов можно получить у поставщиков. Чтобы определить поставщика драйвера, следует просмотреть свойства драйвера в Windows Explorer (большинство драйверов хранится в каталоге winntsystem32drivers); в информации о версии содержатся сведения об авторских правах и иногда описание драйвера.

Существует множество других bang-команд (полный список можно получить с помощью !help), но здесь я рассказал только о тех командах, для использования которых не требуется хорошо знать внутреннюю структуру Windows 2000 или NT. В файле WinDbg Help описаны различные параметры встроенных, bang- и dot-команд.

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

МАРК РУСИНОВИЧ - доктор философии и редактор Windows 2000 Magazine. С ним можно связаться по электронной почте по адресу: mark@sysinternals.com, или через Web-узел http://www.sysinternals.com