По мере роста популярности Windows NT постоянно возрастало количество приложений, создаваемых для работы в ее среде. Практически любое устройство, способное функционировать на платформе Intel, поддерживает работу под управлением NT. По оценкам Microsoft, уже известно около 12000 программ, написанных для NT, и 24000 поддерживаемых этой системой устройств.

Марк РусСинович доктор философии в области вычислительной техники Университета Карнеги-Меллон и один из соавторов многих популярных утилит для Windows NT, включая NTFSDOS, Filemon, Regmon и Recover. С ним можно связаться по электронной почте по адресу mark@sysinternals.com или через Web-узел http://www.sysinternals.com/

Повсеместное распространение таких программ и устройств привлекает внимание пользователей к этой операционной системе, которую легко использовать и развертывать, но они же доставляют разработчикам NT немало хлопот. Из-за небрежно написанных приложений и драйверов устройств NT пользуется славой нестабильной ОС. К настоящему времени Microsoft предоставила системным администраторам весьма ограниченный набор инструментов для восстановления системы после аварии и возложила тяжкое бремя разработки корректных приложений и драйверов на плечи самих разработчиков. Но, выпустив Windows 2000, Microsoft поставила перед собой цель, с одной стороны, дать возможность разработчикам превратить Windows 2000 в систему с нулевым временем незапланированного простоя и, с другой стороны, помочь администраторам самим выявить причину простоев, когда они возникают.

Каким образом Microsoft собирается этого достичь? Внедряя в Windows 2000 встроенные механизмы повышения надежности и предоставляя разработчикам инструменты, с помощью которых можно будет выявлять проблемы в приложениях и драйверах до того, как с ними столкнутся конечные пользователи. Вместе с тем в Microsoft признают, что несмотря на все усилия разработчиков время от времени систему бывает невозможно загрузить. Необходимость разбираться в подобных ситуациях лучше, чем это позволяет сделать Emergency Repair Disk (ERD), заставила Microsoft предоставить администраторам некоторые новые инструменты.

В этот раз я предлагаю вниманию читателей обзор имеющихся в Windows 2000 новых возможностей восстановления системы после сбоев, включая работу в режиме Safe Mode, Recovery Console, а также новый вариант создания аварийного дампа. В последующих двух номерах я расскажу о возможностях повышения надежности, добавленных в Windows 2000 (например, Windows File Protection), которые защитят пользователей от «взбесившихся» приложений. В заключение я рассмотрю программу Driver Verifier, которая, с одной стороны, позволит разработчикам драйверов быстро находить незамеченные ранее ошибки в своих программах, а с другой, поможет определять, какой драйвер несет ответственность за «обвал» системы.

К числу наиболее вероятных причин, по которым Windows NT перестает загружаться, следует отнести работу драйверов устройств. Это может произойти или сразу после установки нового драйвера, или, что уже не так очевидно, после того, как драйвер нормально отработал некоторое время. И в том, и в другом случае нормальная последовательность загрузки прерывается аварийным остановом системы. Программная и аппаратная конфигурация машины может время от времени изменяться, что в свою очередь приводит к проявлению в работе драйверов скрытых ошибок. Если такая ошибка обнаруживается вслед за установкой нового драйвера во время самой первой перезагрузки системы, считайте, что вам повезло. В процессе загрузки еще остается возможность «откатиться» к конфигурации Last Known Good, что приведет к восстановлению ключа реестра HKLMSYSTEMCurrentControlSet1 в состояние, предшествовавшее сбою, когда система загружалась без проблем. Если конфигурация Last Known Good не помогает, можно попробовать другой способ. Например, если система располагается в разделе FAT, то, загрузившись с помощью системной дискеты в DOS, достаточно просто удалить или переименовать файл подозрительного драйвера. Если же система располагается в разделе NTFS, остается либо использовать утилиты восстановления производства независимых компаний или же рядом с незагружаемой версией NT установить новую, загрузиться в нее и обратиться к диску NTFS.

Windows 2000 весьма чувствительна к ведению драйверов устройств, что также может препятствовать процессу загрузки, но администратору этой ОС предлагается дополнительный способ решения проблемы: загрузка в режиме безопасной работы (Safe Mode). В Windows 2000 заимствована концепция Safe Mode из Windows 9x, в которой загрузочная конфигурация системы состоит из минимального набора необходимых драйверов и служб. Полагаясь только на необходимые для загрузки драйверы и службы, Windows 2000 тем самым избегает активизации драйверов от независимых компаний и других драйверов, которые могли бы привести к ее «обвалу».

Во время загрузки Windows 2000 следует нажать F8 для входа в специальное меню, содержащее пункт Safe Mode. Как правило, выбирается один из трех вариантов работы в Safe Mode: стандартный режим (standard), сетевой (networking-enabled) и режим безопасной работы с командной строкой (safe mode with command prompt). Стандартный режим означает подключение в процессе загрузки минимального числа драйверов и служб. При выборе сетевого режима к числу драйверов и служб стандартного режима добавляются новые для поддержания работы в сети. Наконец, режим безопасной работы с командной строкой идентичен стандартному режиму, но среда работы пользователя реализуется с помощью cmd.exe, а не Windows Explorer.

Windows 2000 имеет также четвертый тип Safe Mode: режим восстановления службы каталогов (DS Repair Mode), который отличается от стандартного и сетевого режима безопасной работы. Этот режим используется при необходимости провести восстановление Active Directory (AD) на контроллере домена с архивной ленты. При использовании DS Repair Mode загружаются все драйверы и службы, следовательно, нет смысла использовать этот режим для загрузки «незагружаемых» систем.

Каким образом Windows 2000 узнает, какие драйверы и службы составляют подмножество стандартного и сетевого режима безопасной загрузки? Ответ содержится в ключе реестра HKLMSYSTEMCurrentControlSetControlSafeBoot. Как видно из Экрана 1, этот ключ содержит подключи Minimal и Network. В свою очередь последние также содержат подключи, в которых указываются имена или (1) драйверов устройств, или (2) служб, или (3) групп драйверов. Так, на Экрана 1 показан подключ vga.sys. Этот подключ определяет VGA-драйвер, который включен в загрузочную конфигурацию. В режиме Safe Mode система использует именно этот драйвер, а не тот, который, возможно, более полно учитывает характеристики адаптера, но вместе с тем может стать причиной сбоя системы в процессе загрузки. Каждый подключ под ключом SafeBoot имеет значение по умолчанию, которое определяет, что именно идентифицирует данный подключ. Так, значение по умолчанию для подключа vga.sys — Driver.

Укажем также на подключ Boot File System, для которого значение по умолчанию — Driver Group. Когда разработчик драйвера устройства пишет сценарий для его установки, он может указать, что драйвер входит в состав некоторой группы драйверов. Описание используемых системой групп драйверов находится в HKLMSYSTEMCurrentControlSetControlServiceGroupOrder. Разработчик указывает, что драйвер является членом группы, для того, чтобы Windows 2000 смогла установить, когда именно подгружать драйвер. Основная задача ServiceGroupOrder состоит в определении порядка загрузки группы. Некоторые типы драйверов должны загружаться либо до, либо после других типов. Для каждого драйвера в регистре имеется свой ключ, а принадлежность группе устанавливается в значении Group данного ключа. Ключи драйверов и служб расположены ниже HKLM SYSTEMCurrentControlSetServices. Так, если посмотреть на подключи Services, можно обнаружить среди прочих и ключ VgaSave для драйвера VGA. Любые драйверы файловой системы, которые требуются Windows 2000 для обращения к системному разделу, перечислены в ключе Boot file system, который можно рассматривать как группу драйверов. Если системный раздел Windows 2000 расположен в NTFS, то драйвер доступа к разделу NTFS входит в состав именно этой группы. В противном случае, в состав группы входит драйвер Fastfat (он поддерживает работу FAT12, FAT16 и FAT32 в Windows 2000). Драйверы, поддерживающие работу остальных файловых систем, входят в состав группы File system. Эта группа включена в состав как стандартного режима Safe Mode, так и сетевого режима.

Когда во время загрузки выбирается один из режимов Safe Mode, программа-загрузчик NT (NTLDR) передает в ядро системы (ntoskrnl.exe) соответствующий переключатель в виде параметра командной строки вместе с параметрами, заданными в файле boot.ini. При задании любого режима Safe Mode программа NTLDR передает в ядро переключатель /SAFEBOOT:. В зависимости от конкретного типа выбранного режима безопасной загрузки NTLDR добавляет к этому переключателю одну или более строк. Для стандартного режима NTLDR добавляет строку MINIMAL, для сетевого NETWORK. Для режима загрузки с командной строки добавляется MINIMAL (ALTERNATESHELL), а для режима DS-repair — DSREPAIR.

Программа ядра сканирует переданные параметры для определения переключателей Safe Mode на самом раннем этапе загрузки. В соответствии с обнаруженными переключателями внутренней переменной InitSafeBootMode присваивается определенное значение. Программа ядра записывает значение этой переменной в реестр по адресу HKLMSYSTEM CurrentControlSetControlSafeBootOptionsOptionValue с тем, чтобы в дальнейшем различные подсистемы пользовательского уровня, например, Service Control Manager (SCM), смогли «понять», в каком именно режиме Safe Mode находится система. Кроме того, если используется режим загрузки с командной строки, ядро записывает 1 в реестр по адресу HKLM SYSTEMCurrentControlSetControlSafeBootOptionsUseAlternateShell. Наконец, все переданные в ядро параметры загрузки переписываются в реестр по адресу HKLMSYSTEM CurrentControlSetControlSystemStartOptions.

Когда подсистема ядра I/O Manager готова начать процесс загрузки драйверов на основании записей в HKLMSYSTEMCurrentControlSetServices, выполняется вызов функции IopLoadDriver. Подсистема Plug and Play Manager при обнаружении нового устройства перед динамической загрузкой его драйвера выполняет иную функцию — IopCallDriverAddDevice. Обе указанные функции в свою очередь вызывают функцию IopSafeBootDriverLoad перед тем, как загружать какой-либо драйвер. IopSafeBootDriverLoad проверяет значение InitSafeBootMode и решает, стоит ли вообще пытаться загружать этот драйвер с точки зрения выбранного режима Safe Mode. Например, если загрузка происходит в стандартном режиме, IopSafeBootDriverLoad ищет группу драйверов, которой принадлежит рассматриваемый драйвер, в подключе Minimal. Если такая группа находится, то вызывающей функции передается признак, разрешающий загрузку драйвера. В противном случае IopSafeBootDriverLoad пытается обнаружить в подключе Minimal имя самого драйвера. Если это удается сделать, драйвер может загружаться. Если же в подключе Minimal ни в группе, ни по своему имени драйвер не обнаружен, загрузка драйвера не производится. Если система загружается в сетевом режиме, то функция IopSafeBootDriverLoad все поиски осуществляет в подключе Network. В случае, когда не выбран ни один из режимов Safe Boot, IopSafeBootDriverLoad позволяет загружать все драйверы.

Для драйверов, которые исключаются при загрузке в режиме Safe Mode, имеется лазейка: NTLDR до обращения к ядру загружает все драйверы, для которых значение Start в реестре установлено в 0 (так называемые boot-start драйверы). Это означает, что система всегда использует эти драйверы во время загрузки. Поскольку NTLDR не проверяет ключ реестра SafeBoot, то до запуска ядра системы NTLDR загружает все драйверы boot-start.

Компонент пользовательского режима SCM, реализованный в виде программы services.exe, на этапе инициализации проверяет значение HKLM SYSTEMCurrentControlSetControlSafeBootOptionsOptionValue чтобы установить, загружается ли система в режиме Safe Boot. Если да, то SCM повторяет все действия функции IopSafeBootDriverLoad. По мере обработки служб, перечисленных в HKLMSYSTEMCurrentControlSetServices, подсистема SCM загружает только те службы, имена которых присутствуют в реестре в соответствующем выбранному типу Safe Mode подключе.

Userinit (реализована в winnt system32userinit.exe) — это еще один компонент пользовательского режима, которой необходимо «знать», загружена ли система в режиме Safe Mode. Этот компонент инициализирует среду работы пользователя после его регистрации в системе. Userinit проверяет значение HKLMSYSTEMCurrentControlSetControlSafeBootOptionsUseAlternate. Если оно установлено, Userinit запускает программу, записанную в HKLMSYSTEMCurrentControlSetControlSafeBootOptions UseAlternateShell в качестве среды работы, а не использует привычную программу explorer.exe. Windows 2000 записывает имя программы cmd.exe в AlternateShell во время установки, тем самым пользовательской средой по умолчанию в режиме Safe Mode с командной строки становится командная строка Win32. Но даже в этом случае можно запустить программу explorer.exe с командной строки для начала работы в Windows Explorer. То же самое можно проделать и с другой программой графического интерфейса пользователя.

Приложения пользователя не проверяют значение OptionValue для того, чтобы выяснить, загрузилась система в режиме Safe Mode или нет, поскольку Microsoft официально не документировала наличие OptionValue. Вместо этого приложения используют вызов GetSystemMetrics (CLEAN_BOOT) API-интерфейса Win32 . Системные сценарии, которым необходимо выполнять ряд специальных операций, когда система загружается в Safe Mode, обращаются к переменной окружения SAFE_BOOT, поскольку эта переменная устанавливается системой только во время загрузки в Safe Mode.

При выборе режима загрузки Safe Mode, загрузчик NTLDR передает в ядро Windows 2000 в качестве параметра строку BOOTLOG, наряду с уже известными нам параметрами Safe Mode. Во время инициализации ядра проверяется параметр BOOTLOG, независимо от наличия параметров Safe Mode. Если программа ядра обнаруживает строку BOOTLOG, ядро протоколирует все свои действия, связанные с загрузкой драйверов. Например, если IopSafeBootDriverLoad дает подсистеме I/O Manager команду не загружать драйвер, то I/O Manager, в свою очередь, вызывает функцию IopBootLog, которая фиксирует этот факт. Аналогично, после того, как IopLoadDriver успешно выполнил загрузку драйвера, который входит в конфигурацию данного режима Safe Mode, вызывается IopBootLog для регистрации факта успешной загрузки драйвера. Пользователь может просмотреть записи этапа загрузки системы, чтобы установить, какие драйверы вошли в состав загрузочной конфигурации.

Поскольку ядро стремится не записывать на диск что-либо до завершения программы chkdsk, что происходит после процедуры загрузки системы, функция IopBootLog не записывает сообщения в файл. Запись производится в HKLMSYSTEMCurrentControlSetBootLog.

Как только начинает работать первый компонент пользовательского режима — Session Manager (winnt system32smss.exe), запускается программа проверки целостности дисков chkdsk, а затем функция NtInitializeRegistry выполняет инициализацию системного реестра. Ядро воспринимает это как разрешение записи на диск. Функция IopCopyBootLogRegistryToFile создает в системном каталоге Windows 2000 (winnt) файл ntbtlog.txt и копирует в него содержимое BootLog. При этом «поднимается» флажок, извещающий функцию IopBootLog о том, что запись протокола загрузки в файл произведена.

Safe Mode — это вполне удовлетворительный инструмент для устранения неисправностей в системах, которые перестают загружаться из-за ошибок в работе драйверов на этапе выполнения последовательности загрузки. Но в некоторых ситуациях Safe Mode не помогает. Если «проблемный» драйвер принадлежит конфигурации Safe Mode, загрузка по-прежнему будет невозможна. Другой пример: сбои в работе драйвера независимого разработчика, скажем, антивирусного драйвера, не дадут системе загрузиться, если этот драйвер относится к типу boot-start (драйверы этого типа грузятся независимо от того, выбран Safe Mode или нет). Наконец, если системный модуль или файл драйвера, жизненно необходимые системе в конфигурации Safe Mode оказываются по какой-либо причине испорченными, или же если повреждена запись Master Boot Record (MBR) на системном диске, то и в этом случае при загрузке системы произойдет ошибка. Выйти из положения поможет новый инструмент Windows 2000 — Recovery Console (RC). При этом загрузка выполняется или с компакт-диска Windows 2000, или с загрузочных дискет, а не с проблемной установки на жестком диске. Среда — командная строка с ограниченным набором команд.

При загрузке с компакт-диска, процесс вскоре доходит до экрана, на котором предоставляется выбор — либо восстановить существующую установку, либо произвести новую. При выборе режима восстановления, система предлагает вставить компакт-диск, после чего необходимо выбрать один из трех вариантов восстановления: стартовать RC, инициировать процесс Emergency Repair или же воспользоваться свойством Advanced System Recovery для восстановления данной установки с ленты. При нажатии F10 в состоянии экрана Setup Welcome можно в обход всех остальных меню напрямую попасть в RC.

RC предоставляет список установок NT, обнаруженных во время сканирования дисков. После того, как выбор сделан, следует ввести пароль администратора для регистрации в системе с административными полномочиями. После успешной регистрации пользователь попадает в окружение, напоминающее среду DOS. В Таблице 1 приведен список команд, доступных в этом окружении. Набор перечисленных команд достаточно гибок для того, чтобы выполнить простые операции ввода/вывода; с его помощью можно подключать и отключать службы и драйверы, а также восстанавливать загрузочный сектор и MBR. Вместе с тем, в среде RC предоставляется доступ к ограниченному набору каталогов, а именно: корневому каталогу, системному каталогу той установки, в которую вы зарегистрировались, и каталогам на сменных носителях — компактдисках и 3,5-дюймовых дискетах. Это обеспечивает защиту информации, к которой администратор в обычных условиях может и не иметь доступа.

Поскольку вам предоставляется возможность установить новую или восстановить существующую систему, с компакт-диска должна быть загружена копия ядра Windows 2000, включая все необходимые для этого драйверы (т.е. NTFS или FAT, драйверы SCSI, видеодрайвер). Для систем x86 файл setuptxt.sif в каталоге i386 на компакт-диске Windows 2000 управляет процессом загрузки драйверов с компакт-диска. Этот файл содержит директивы, которые предписывают, какие файлы следует загрузить и где именно на компакт-диске они находятся. Точно также, когда происходит загрузка Windows 2000 с жесткого диска, первой компонентой режима пользователя, запускаемой ядром, является Session Manager (smss.exe). Session Manager, который используется в программе Setup Windows 2000, несколько отличается от аналогичной программы, создаваемой в результате стандартной установки. Подкаталог system32 содержит Setup Session Manager и именно эта компонента предоставляется через меню на этапе установки/восстановления Windows 2000, а затем предлагается выбрать тип восстановления. Если Windows 2000 устанавливается заново, Session Manager будет сопровождать вас на всем пути от выбора раздела для будущей системы до копирования файлов в этот раздел.

RC реализована с помощью двух драйверов: spcmdcon.sys и setupdd.sys. Когда в меню выбирается работа с RC, Session Manager загружает и запускает эти драйверы. Setupdd.sys — это вспомогательный драйвер, который позволяет spcmdcon.sys пользоваться функциями для работы с дисковыми разделами, загружать реестр, а также работать с видеодрайвером. (Setupdd.sys взаимодействует с драйверами диска для обслуживания разделов и использует базовые функции видео, встроенные в ядро Windows 2000 для вывода сообщений на экран.

После выбора установки для восстановления и передачи в RC пароля администратора, в RC должен быть запущен механизм для проверки попытки зарегистрироваться, несмотря на то, что подсистема безопасности Windows 2000 не загружена и, соответственно, не работает. RC должна сама установить, соответствует ли введенный пароль учетной записи администратора системы или нет. На первом шаге происходит обращение к setupdd.sys и загрузка куста SAM с диска. В SAM хранится информация о паролях; SAM размещен в файле winntsystem32configsam. Затем RC определяет, использовался ли для шифрования SAM системный ключ. Если да, RC определяет местонахождение системного ключа в реестре выбранной системы. Шифрование SAM — это свойство, введенное в пакете обновления SP3 с целью защитить систему от взломщиков паролей (загружаясь в DOS с консоли системы, хакеры считывали пароли непосредственно из SAM-файла).

После этого RC определяет местонахождение пароля администратора в SAM и расшифровывает его, если в системе использовался ключ шифрования. На последнем шаге аутентификации RC применяет хеш-алгоритм MD5 (точно такой же алгоритм применяется в Windows 2000 во время процесса регистрации пользователей), хеширует пароль и сравнивает полученный код с тем, который хранится в SAM. Если RC обнаруживает соответствие кодов, считается, что регистрация произведена успешно. Если нет, то попытка воспользоваться RC будет отвергнута.

ЭКРАН 2. Конфигурирование аварийного дампа ядра

Последним усовершенствованием для восстановления системы Windows 2000 после сбоя является новый параметр при создании аварийного дампа. В NT 4.0 вы можете сконфигурировать систему так, чтобы в случае аварийного останова содержимое физической памяти записывалось в файл на диск. В случае «обвала» системы генерируется дамп, размер которого оказывается чуть-чуть больше объема емкости памяти. Однако почти вся или большая часть данных в файле дампа не рассматривается службой технической поддержки, которой предстоит произвести анализ этого дампа при поиске неисправности, вызвавшей аварийный отказ. Инициатором аварийного останова системы и в NT, и в Windows 2000 выступает программа ядра. Именно ядро содержит полезную информацию относительно состояния системы в момент «обвала», включая сведения о приложениях, которые были активны, о том, какие драйверы были загружены и какой именно код выполнялся в самый последний момент. Чаще всего, собственные данные активных приложений (данные режима пользователя), содержащиеся в физической памяти, не рассматриваются для определения причины аварии и лишь увеличивают размер дампа.

Специалисты Microsoft учли эту проблему и добавили новый параметр в окно Startup and Recovery для Windows 2000(см. Экран 2). Параметр Write kernel information only («Записывать только информацию ядра») исключает все собственные данные приложений. Когда этот параметр установлен, программы анализа дампа (Crash analysis tools), входящие в состав Windows 2000, в том числе dumpexam и WinDbg, «поймут», что дамп содержит сведения только о ядре системы, и будут соответствующим образом интерпретировать его. Место на диске, которое экономится с помощью этого параметра, от системы к системе, и даже от одной аварии к другой, будет сильно варьироваться. Однако типичный размер дампа для 128-мегабайтной системы составляет обычно около 40 Мбайт, в то время как полный дамп памяти обошелся бы в 128 Мбайт.