А вы задумывались над тем, что будете делать, если однажды ваш сервер зависнет после перезагрузки системы? И, что не менее важно, сколько времени вам потребуется на решение возникшей проблемы? Большинство администраторов Windows NT при одной мысли о возможности увидеть голубой экран с кучей цифр и надписью STOP (известный как blue screen of death) бросает в холодный пот. Впрочем, и любая другая неполадка в работе сервера компании не может вызвать улыбку.
Понятно, что остановка сервера означает, по меньшей мере, снижение производительности работы сотрудников, потерю времени и денег, а также предвещает не самую приятную беседу с руководством. Поэтому в первой части статьи мы расскажем о дополнительных средствах и процедурах, которые вы можете использовать для увеличения надежности ваших серверов, и которые, надеемся, помогут вам восстановить систему после сбоя при начальной загрузке Windows NT. Кроме того, мы покопаемся в малоизвестных методах решения проблем такого рода, и вы сможете использовать их для восстановления «упавшей» системы в будущем. Замечу, что в данной статье мы не будем касаться кластерных конфигураций. Предполагается, что система состоит из отдельного сервера, не имеющего проблем на аппаратном уровне.
Типичные неприятности
Причин, по которым система Windows NT может остановиться при загрузке, много, но результатом их действия почти всегда является ужасающий «голубой экран смерти» (см. экран 1). После того как Windows NT останавливает систему, она выводит этот экран, чтобы предотвратить дальнейшее нарушение целостности данных.
ЭКРАН 1: Содержимое «голубого экрана смерти» — blue screen of death в Windows NT
Кроме того, на голубой экран выводится важная информация о состоянии системы в момент сбоя: перечисляются код ошибки STOP, адрес памяти, по которому произошла ошибка, и набор драйверов, загруженных в память в то время, когда она произошла. Однако выявить истинную причину ошибки не всегда просто. Проблема обычно развивается по одному из следующих сценариев.
- Вы установили программное обеспечение, которое разрушило часть системного реестра HKEY_LOCAL_MACHINE — это может происходить при попытках прикладной программы установить новую службу или драйвер. Результатом будет появление голубого экрана, на котором пользователь читает о невозможности загрузить реестр или один из его файлов.
- Вы некорректно изменяете конфигурацию сетевого оборудования, что может привести к нарушению сетевых привязок и соответствующих им ключей в реестре (то есть NT разрушает или перезаписывает критически важные файлы OS несовместимыми или неверными версиями системных файлов во время работы).
- Вы установили новую службу или системный драйвер, который несовместим с аппаратным обеспечением и вызывает ошибку при перезагрузке (то есть загрузка некорректного файла приводит к разрушению исправного системного файла, который вы загрузили в память до момента сбоя).
Каждый из этих сценариев имеет различные причины и решения, поэтому дальше рассмотрим их по отдельности более подробно.
Нарушения в реестре
Системный реестр — сердце системы NT. Поэтому в зависимости, от вида и степени нарушения целостности, поврежденный реестр весьма часто вызывает сбой при загрузке операционной системы. Нарушения целостности реестра могут быть физические и логические. Физическое нарушение подразумевает, что какие-то неполадки (обычно сбои в работе дисковой подсистемы) вносят путаницу в файлы реестра (например, в файлы SOFTWARE или SYSTEM в системном каталоге \%winntroot%\system32\config). Логические нарушения означают, что приложение, пользователь или сама операционная система записали в реестр неверные данные, которые в свою очередь могут вызвать сбой при загрузке, если значение данного ключа в реестре достаточно критично.
К сожалению, не всегда можно установить, что ошибку вызвали именно нарушения в реестре. В некоторых случаях сообщение об ошибке STOP означает, что реестр имеет повреждение, препятствующее дальнейшей работе, или ссылается на поврежденный файл реестра. Однако сообщение STOP не всегда может явно информировать о таком виде нарушений в реестре.
Если имеются основания подозревать, что проблемы с загрузкой связаны именно с реестром, можно начать восстановление с использованием варианта загрузки предыдущей конфигурации (Last known good configuration). Это можно сделать несколькими путями.
Вариант Last known good configuration. Вы можете воспользоваться этой опцией при появлении соответствующей подсказки и нажатии клавиши пробела в период загрузки системы. Выбрав эту опцию, вы загрузитесь с предыдущей работоспособной конфигурацией. Это самый быстрый и легкий способ, если, конечно, он срабатывает. К сожалению, шансы на успех в реальной ситуации не так уж велики, поскольку данный способ ограничивается восстановлением только одной части реестра (а именно, ветви ControlSet00X в ключе HKEY_LOCAL_MACHINE\SYSTEM). То есть вы сможете восстановить систему данным способом, только если проблема ограничена данной ветвью реестра и вы сразу использовали вариант Last known good configuration. Однако в большинстве случаев предложенный метод не поможет.
Восстановление через процесс установки и с помощью дискеты восстановления ERD (Emergency Repair Disk). Можно воспользоваться процедурой установки NT для проверки и замены индивидуальных файлов реестра, если первый способ не сработал. После установки дискеты восстановления ERD в дисковод вы должны будете указать, какую часть существующей операционной системы требуется проверить (см. экран 2). Если вы выберете пункт Inspect registry files, появится список файлов реестра, и вы сможете указать, какие из них нужно заменить. Заменяющие файлы берутся либо с диска ERD, либо из каталога \%systemroot%\repair. Файлы на диске ERD и в каталоге \%systemroot%\ repair хранятся в сжатом виде, и каждый из них имеет расширение в виде подчерка «_» (например, SYSTEM._, SOFTWARE._).
ЭКРАН 2: Экран выбора опций при процедуре восстановления программы установки
Использование самых последних копий заменяющих файлов позволит не потерять важную информацию о конфигурации приложений и системы. Созданию диска ERD с последними копиями файлов реестра посвящена статья Майка Рейли, опубликованная в январском номере журнала за 1997 год. Добавлю, что не следует восстанавливать ветви SAM и SECURITY на контроллере домена, если только вы не запускали программу создания дискеты восстановления rdisk с ключом /s или s- (то есть Rdisk /s). В противном случае программа установки перепишет вашу базу SAM ее версией, создаваемой в процессе установки, что вызовет череду новых затруднений. Кроме того, следует убедиться в том, что файлы реестра на дискете ERD и заменяемые файлы созданы операционной системой, на которую был установлен один и тот же сервисный пакет. Важно помнить, что Service Pack 3 и последующие проводят изменения в ветвях SAM и SECURITY, связанные с усилением системы безопасности NT. Если не соблюдать это правило, то вы не сможете войти в систему после завершения процедуры восстановления. Далее заметим, что исправление файлов SAM и SECURITY вряд ли разрешит проблему нарушения целостности реестра, поскольку сбой при загрузке системы вызывают по большей части ветви SYSTEM и SOFTWARE. Поэтому начинайте с восстановления предыдущих версий именно этих файлов. Причем в первую очередь ветви SYSTEM, поскольку именно в ней содержатся записи о наиболее важных компонентах системы, такие как драйверы и службы.
Альтернативная/параллельная установка NT. Использование альтернативной/параллельной установки для восстановления реестра — на наш взгляд, оптимальное средство решения проблемы. Загрузка альтернативной системы позволяет вам получить доступ к томам с NTFS, которые в противном случае были бы недоступны. А запуск параллельной системы дает вам доступ к первоначальной версии файлов реестра, так что вы можете скорректировать или заменить их. Вы можете достичь того же результата, используя ERD Commander от Systems Internals по https://www.internals.com или NTFS-DOS от Winternals Software по https://www.winternals.com. После загрузки альтернативной системы вы имеете возможность выполнить те же действия по восстановлению, что и при использовании программы установки и выборе опции восстановления, но с большей гибкостью и избирательностью. И хотя специалисты из Microsoft не рекомендуют применять данный способ, мы считаем, что он лучше всего подходит для опытных пользователей NT. Более подробная информация об использовании параллельно установленной системы находится во врезке «Параллельное мышление».
Прежде чем начать операцию восстановления, сделайте копии своих файлов реестра. Я обычно копирую существующие файлы в подкаталог каталога, содержащего файлы реестра (например, \%systemroot%\system32\config\backup). Только после этого можно начинать эксперименты с заменой отдельных файлов реестра. Однако вы не можете просто скопировать файлы, которыми будете заменять поврежденные, поскольку на дискете ERD и в каталоге \%systemroot%\repair эти файлы хранятся в сжатом виде. Перед использованием этих файлов примените к ним команду expand.exe, чтобы разархивировать их вручную. Например, чтобы развернуть сжатую копию ветви SYSTEM с дискеты ERD или из каталога \%systemroot%\repair, наберите в командной строке NT:
Expand system._ system
Скопируйте получившийся файл в \%systemroot%\system32\config первоначальной системы и перезагрузитесь.
Если вы не хотите иметь дело со сжатыми файлами, можете использовать утилиту regback.exe из Microsoft Windows NT Server 4.0 Resource Kit для создания дополнительных копий реестра. Она создает копию, которая содержит все файлы реестра в несжатом виде. Кроме того, данная утилита копирует ветви SAM и SECURITY, так что вам не нужно будет помнить о необходимости указывать дополнительные переключатели. Однако здесь нужно учесть, что несжатые копии реестра могут не уместиться на трехдюймовую дискету. Безопасным местом для хранения копий реестра, созданных с помощью regback.exe, может служить раздел диска, отличный от загрузочного. Предпочтительно вообще хранить их на другом физическом диске. Для достижения максимальной защиты от аппаратных сбоев, которые могут сделать полученные копии файлов реестра недоступными, рекомендую хранить дополнительную копию реестра одного сервера на другом сервере и наоборот.
Переписанные или разрушенные файлы
К числу наиболее существенных недостатков операционной системы Windows 4.0 относится использование разделяемых системных файлов, которые могут быть свободно переписаны приложениями независимых компаний. Кроме того, сама система NT не слишком надежно защищает себя от замены ключевых системных файлов, таких как файлы драйверов и системных служб. В некоторых случаях это приводит только к появлению сообщений об ошибках и сбоям в работе конкретных приложений. Однако это может вызвать сбой и при загрузке самой системы NT. Следующая версия NT — Windows 2000 или Win2K — снижает вероятность такого рода сбоев посредством разделения библиотек приложений и обеспечения большей защиты от перезаписи критически важных системных файлов.
Для восстановления поврежденных или некорректных файлов на томах NTFS вы можете использовать либо параллельно установленную систему NT, либо процедуру восстановления программы установки. Для восстановления на томах FAT можно воспользоваться загрузочными дисками от DOS или Windows 9x.
Заменить файл, воспользовавшись параллельной установкой системы, очень просто, если только вы точно знаете, какой из файлов разрушен или некорректен. В качестве меры предосторожности создайте каталог на жестком диске, который послужит местом хранения файлов для установки системы NT. Можно использовать для этого и CD-ROM. В этом каталоге должны находиться копии файлов ядра NT для той версии сервисного пакета, который вы установили в системе. Если вы развернули параллельную систему с тем же сервисным пакетом, что и для первой системы, то вы можете использовать каталог второй системы как каталог для установки. Если это не так, то создайте в параллельной системе отдельный каталог с файлами первичной установки системы NT самой последний версии.
Чтобы процесс восстановления мог заменить поврежденные или конфликтующие файлы, выберите опцию Verify Windows NT System Files из списка, выводимого программой установки. Microsoft реализовала эту функцию, чтобы можно было быстро найти файлы, отличные от первоначальных установочных файлов NT. Однако после установки на систему сервисного пакета слишком много файлов будут отличаться от первоначальных, поскольку они были модифицированы. В данном случае лучше всего выбрать вариант «А», чтобы позволить программе установки заменить все неоригинальные файлы и затем, после восстановления системы и ее запуска, повторить установку сервисного пакета.
Иначе вы можете заменить системные файлы NT их первоначальными версиями, используя параметр модернизации Upgrade в программе установки. И хотя некоторые пользователи обходят описанный выше процесс восстановления и сразу приступают к модернизации, нам этот метод решения кажется неудачным по нескольким причинам. Во-первых, процесс модернизации обычно занимает намного больше времени, чем процесс восстановления. Во-вторых, он более запутан и связан с большим риском для вашей системы. И наконец, даже если процесс установки успешно разрешил ваши первоначальные проблемы, он может вызвать появление голубого экрана с ошибкой, вызванной драйвером tcpip.sys (STOP error 0x00000050). При установке NT 4.0 или NT 4.0 SP1 поверх NT4.0 SP2 или более поздней программа установки не заменяет драйвер tcpip.sys из SP2 или более поздний его ранней версией. Соответственно — этот драйвер вызывает сбой в NT 4.0 или NT 4.0 SP1. Чтобы избежать такой ситуации, нужно вначале использовать процедуру Verify Window NT System Files для замены существующих файлов их первоначальными версиями. Тогда, если процедура восстановления не привела к нормальной загрузке системы, вы сможете спокойно запускать процедуру модернизации, поскольку файл tcpip.sys SP2 или поздней версии уже был заменен первоначальным.
Осторожность не помешает
Такие средства как параллельная установка системы и дополнительные копии файлов реестра, повышают вероятность быстрого восстановления в случае сбоя в процессе загрузки системы. И вы можете быть уверены, что ваши серверы готовы к худшему.
В следующем номере обсудим причину, вызывающую добрую треть всех сбоев: стартующие в автоматическом режиме службы или драйверы прерывают процесс загрузки. Мы расскажем о некоторых «трюках», которые можно проделать при восстановлении, включая способ удаленного восстановления реестра поврежденной системы с помощью параллельной системы. Кроме того, в следующей статье пойдет речь о средствах других фирм, которые помогут вам выкарабкаться, если вдруг система откажется загружаться.
Об авторе
Шон Дейли — сертифицированный инженер Microsoft и президент iNTellinet Solutions — интеграторской и консалтинговой компании, занимающейся вопросами сетей. Дейли ведет рубрику в журнале Windows NT Magazine и является автором книг Optimazing Windows NT (IDG Books) и Migrating to Windows NT 4.0 (29th Street Press). С ним можно связаться по адресу sean@ntsol.com.
Параллельное мышление
Избыточность и устойчивость к сбоям аппаратного обеспечения — незаменимые качества для серверов с важными приложениями, но они не спасут вас от всех возможных проблем. Сбои в программном обеспечении происходят и на таком оборудовании, поэтому расширьте свой набор средств восстановления альтернативной/параллельной установкой системы.
Параллельная установка — это вторая система Windows NT, установленная на том же диске, что и первичная ОС, или на другом диске. Параллельная система — своеобразный «черный ход» в вашу систему, позволяющий вам получить доступ к томам NTFS и данным файлов реестра в случае сбоя первой системы. Она также может пригодиться, если вы не надеетесь на стандартную процедуру восстановления.
Я рекомендую устанавливать параллельную систему в каталог, имя которого объясняет его предназначение. Например, для своих клиентов на каждом сервере я создаю каталог \winntrec (то есть Windows NT recovery) и провожу инсталляцию параллельной системы в него. Для лучшей защиты располагать этот каталог следует в другом разделе диска или на другом физическом диске.
При установке альтернативной NT системы не следует повторять все опции установки первичной системы (например, сетевые службы, роль сервера). Устанавливайте минимальный набор опций для экономии дискового пространства. Лично я сбрасываю все опции в диалоговом окне NT Accessory и обычно не устанавливаю сетевые службы. Но если вам может потребоваться доступ к другим машинам по сети при загрузке альтернативной системы, то установите сетевую компоненту. Кроме того, не обязательно устанавливать последний Service Pack — установите тот, который считаете наиболее подходящим, если только у вас нет крайней потребности в полной эквивалентности двух систем.
Также имеет смысл установить программное обеспечение резервного копирования, применяемое в вашей сети, на вашу параллельную операционную систему. Таким путем вы сможете быстро восстановить файлы и данные, принадлежащие первичной системе.
Подводя итог, скажем, что параллельную систему полезно установить до того, как появятся проблемы. В противном случае затраты на установку параллельной системы, по меньшей мере, потребуют дополнительного времени в тот момент, когда его и так мало. Что хуже, проблемы, возникшие в первой системе, могут наложиться на затруднения при установке второй. Поэтому мы настоятельно рекомендуем рассматривать установку параллельной системы как неотъемлемую часть программного обеспечения для всех ваших серверов — она поможет вам, если случится непредвиденное.
Будь готов
Основная рекомендация, данная читателям в предыдущей статье, заключалась в том, что готовиться к решению проблем следует задолго до того, как они появятся. Чтобы во всеоружии встретить неприятности завтрашнего дня, нужно сделать несколько подготовительных шагов уже сегодня. В нашем случае это и наличие проверенных процедур установки программного и аппаратного обеспечения, и создание нескольких резервных копий важнейшей информации о настройках, и подготовка специальных средств для выполнения восстановления. Все это послужит спасательным кругом в пучине нежданных напастей.
Не сомневаюсь, что большинство пользователей NT осознают важность наличия последней версии системной информации на диске восстановления Emergency Repair Disk (ERD). На этом диске содержатся копия системного реестра NT и критически важная информация, необходимая для проведения процедуры восстановления программой установки NT. Во многих организациях проводится регулярное резервное копирование системной информации и обновление дисков ERD для всех серверов. Однако выполнение этих процедур требует физического присутствия администратора сети для локального запуска на каждом сервере в организации утилиты rdisk.exe. Многие считают, что этот процесс слишком утомителен и только зря отнимает время.
ЭКРАН 1. Утилита ERDisk компании Aelita Software Group помогает удаленно собирать и обновлять информацию на дисках.
Вот так и получается, что иногда информация на диске ERD не отражает актуального состояния системы. Тем, кому эта ситуация знакома, рекомендую альтернативный метод сбора информации с систем Windows NT. Утилита ERDisk компании Aelita Software Group может собирать такую информацию по сети (см. Экран 1). Кроме сохранения информации ERD в любом заданном месте — на локальном или сетевом диске — программа ERDisk способна выполнять автоматический запуск командных файлов по заданному расписанию. Она также позволяет автоматически обновлять информацию на дисках ERD для всех NT-систем сети, снимая с администратора часть забот о наличии дисков восстановления с актуальной информацией.
Резервные копии: подальше положишь…
Постоянное обновление информации на дисках восстановления ERD для каждой системы NT является несомненно обязательным, но не единственным средством предохранения от бед. В предыдущей статье я уже говорил о методах создания и хранения резервных копий системного реестра. Например, утилита regback.exe из состава Windows NT Server 4.0 Resource Kit позволяет создавать копии индивидуальных файлов ветвей реестра в несжатом виде. Такие несжатые копии файлов реестра особенно удобны при необходимости заменить какую-либо ветвь реестра (более подробно об утилите regback.exe рассказано во врезке «Причуды regback.exe»). Однако здравый смысл подсказывает, что сохранение резервных копий данных системы на локальном жестком диске этой же системы не обеспечивает защиту от сбоев, поскольку сбой может произойти и с локальным диском. Скорее имеет смысл позаботиться о создании дополнительных (избыточных) копий, т. е. сохранении важных данных о конфигурации системы, например копии системного реестра Windows NT, на жестком диске другого компьютера, и наоборот. Иными словами, если говорить о резервных копиях, то чем их больше, тем лучше, а если хранить их перекрестно на других системах, то это совсем хорошо.
Неплохо было бы не только создавать резервные копии данных системного реестра, но и делать избыточные копии другой важной информации. Например, я периодически создаю резервные копии баз данных Microsoft Exchange Server (а именно dir.edb, pub.edb, priv.edb) в автономном режиме (с остановкой служб сервера Exchange на время резервного копирования) на другом сервере сети. Используемая мною программа резервного копирования имеет специальный модуль для создания копий баз сервера Exchange во время его работы, но опытным путем я определил, что полностью восстановить Exchange Server гораздо проще с помощью его недавней копии, созданной в автономном режиме (полностью восстанавливать Exchange Server приходится после проблем с жесткими дисками). Однако следует помнить, что предложенный метод только дополняет стандартный план восстановления системы после сбоя и ни в коей мере не заменяет основные способы (например, резервное копирование данных на магнитную ленту). Если нет желания тратить дефицитное дисковое пространство на хранение таких данных, можно копировать их на другие сменные носители: диски CD-R и CD-RW, картриджи Zip и Jazz, магнито-оптические диски и т. п. Лучше выбрать один из этих вариантов, поскольку утилита создания дисков ERD поддерживает только трехдюймовые дискеты, а это далеко не самый надежный носитель.
Автоматический запуск служб и драйверов
В первой части статьи я говорил о следующих типичных причинах сбоев при загрузке NT и появления «голубого экрана смерти».
- Установка программного обеспечения, при которой разрушается ветвь системного реестра HKEY_LOCAL_MACHINE. Это может происходить при попытках прикладной программы установить новую службу или драйвер.
- Некорректное изменение конфигурации сетевого оборудования, что может привести к созданию неверных сетевых привязок и ошибочной записи соответствующих им значений ключей в реестре.
- Загрузка некорректного файла приводит к разрушению исправного системного файла, который был загружен в память до момента сбоя.
Кроме того, я рассказал о методах решения таких проблем, в том числе о полной замене файлов ветвей системного реестра.
Сейчас стоит обсудить другую возможную причину появления сообщения STOP при попытке инициализации службы или драйвера. В этом случае проблему можно решить путем редактирования системного реестра, а не полной замены файла ветви реестра или всего реестра. Данное решение предпочтительнее и в том случае, если важно не потерять какие-либо параметры установки, или точно неизвестно, какой именно драйвер либо служба вызвали сбой.
В некоторых случаях ошибка возникает при инициализации службы или драйвера, загружающегося до модуля GUI (т. е. до того момента, как NT инициализирует драйвер видеосистемы и перейдет в графический режим). Та же ошибка появляется и после перехода системы NT в графический режим — это может случиться даже во время процедуры входа в систему или еще позднее, поскольку часть служб и драйверов инициализируется в фоновом режиме, уже после выдачи окна регистрации в системе. Такая ситуация возможна при установке новой службы или драйвера либо при переустановке самой системы Windows NT. Кроме этих случаев возможны варианты, когда вновь устанавливаемые программы либо пытаются запустить свои службы или драйверы, конфликтующие с имеющимися в системе NT, либо требуют пакета исправлений более поздней версии. Причиной сбоя при загрузке могут стать и некорректно проведенные изменения параметров установки ранее успешно загружавшихся драйверов и служб. Например, физическая смена сетевой карты без предварительного удаления драйвера предыдущей карты приведет к сбою при загрузке этого драйвера.
В другом случае сообщение об ошибке STOP появляется после изменения драйвера видеоплаты в системе с установленным программным обеспечением удаленного управления (например, Symantec pcANYWHERE32). Большинство таких программ настраиваются на имеющийся драйвер видеосистемы при установке, и проблема становится очевидной только при замене драйвера видеоплаты. Поскольку первоначальный драйвер уже не запускается, после перезагрузки система выдает сообщение об ошибке. В этом случае для корректной смены драйвера видеоплаты на системе сначала требуется удалить программу удаленного управления, поменять видеодрайвер и вновь установить программу удаленного управления.
Плата за грехи: переименование, перемещение или удаление файлов
Рассмотрим некоторые способы предотвращения ошибок, связанных с неправильной загрузкой службы или драйвера. Один из них — это переименование, перемещение или удаление соответствующего данной службе файла для предотвращения ее загрузки. Если известно имя файла, вызывающего такого рода ошибку, следует загрузиться в режим DOS, если тип основной файловой системы FAT, или в параллельную NT систему, если это NTFS. Далее необходимо временно переименовать исходный файл. В большинстве случаев этот способ устраняет сообщение об ошибке, но в установках NT остаются ссылки на несуществующий файл. Если идти таким путем, дальше потребуется переустановить службу или драйвер, или же полностью удалить их из системы при условии, конечно, что система NT загрузилась. Метод переименования не работает и может вызвать проблемы в случае наличия зависимых друг от друга служб или драйверов, как было продемонстрировано в предыдущем примере с программой удаленного управления.
Редактирование системного реестра в автономном режиме
Существует еще один способ решения проблем, связанных с загрузкой служб или драйверов. Это редактирование системного реестра с целью отключения неисправного драйвера или службы. Но как можно редактировать реестр, не загрузившись в NT? Имея альтернативный путь доступа к тому с первоначальной системой, можно редактировать реестр. Для получения доступа к данным реестра со стороны используется параллельная установка системы NT на том же компьютере либо подключение диска с системным разделом NT (содержащим системный каталог NT и файлы ветвей реестра) к компьютеру с другой системой NT.
Получить доступ к системному реестру через параллельно установленную на этом же компьютере систему NT гораздо проще, чем подключать диск к другому компьютеру, так как в данном случае можно избежать проблем, возникающих при физическом перемещении диска из одной системы в другую. Однако вне зависимости от типа файловой системы (FAT или NTFS), на которой размещается системный раздел, необходимо загрузить NT. Редактирование данных реестра осуществляется через редактор реестра NT Registry Editor, а он не может быть запущен вне системы NT. К сожалению, еще никто не придумал такого редактора реестра NT, который бы работал в другой операционной системе, например в DOS.
После того как доступ к файлам системного реестра первоначальной системы получен, можно начинать редактирование в автономном режиме. И хотя многие пользователи хорошо знакомы с редактором реестра NT Registry Editor, вероятно, не все знают о возможности открывать файлы реестра других установленных на этом компьютере NT-систем или создавать дополнительные ветви реестра с помощью редактора реестра системы. Для редактирования реестра в автономном режиме запускают regedt32.exe (утилита regedit.exe не поддерживает такой способ редактирования реестра), указывают ключ HKEY_LOCAL_MACHINE, затем вариант Load Hive в меню Registry редактора реестра и выбирают файл ветви реестра, который необходимо редактировать. Требуется изменить параметры запуска драйвера/службы; эта информация хранится системой NT в ветви реестра SYSTEM. После выбора нужного файла система попросит указать имя подключа, под которым будет храниться содержимое выбранного файла (cм. Экран 2). Эти действия не изменяют имя указанного файла ветви реестра и не оказывают никакого влияния на системный реестр системы Windows NT, которая была загружена. Кроме того, не имеет никакого значения имя, присвоенное ветви, поскольку редактор реестра использует его только для временного обозначения данных, загруженных из ветви реестра первоначальной системы. После присвоения имени дополнительная ветвь появится в окне HKEY_LOCAL_MACHINE.
ЭКРАН 2. Загрузка внешнего файла куста реестра в редактор regedt32.exe.
С этого момента уже можно редактировать ветвь SYSTEM реестра первоначальной системы и, соответственно, попытаться решить проблему неудачного старта. Как и при любой другой операции с системным реестром, вначале следует сделать резервную копию. Однако содержимое нового ключа, SYSTEM2 в данном случае, будет немного отличаться от того, что обычно находится под ключом SYSTEM. Доступными подключами ключа ControlSet будут только подключи ControSetxxx, где xxx — число типа 001. На экране не будет ключа CurrentControlSet, который появляется при редактировании реестра загруженной системы. Ключ не виден, поскольку это только псевдоним того ключа, который был использован при загрузке системы Windows NT.
ЭКРАН 3. Определение значений для наборов Current, Default, Last Known Good и Failed.
Чтобы удостовериться в том, что редактируется нужный подключ, а не задаваемый по умолчанию для параллельной установки, выбирается подключ Select вновь созданного ключа. В правой панели редактора реестра будет выведено несколько значений (см. Экран 3). Система NT использует эти параметры и их значения для того, чтобы выяснить, какой именно набор данных будет задаваться по умолчанию при старте (DefaulControlSet), какой является текущим (CurrentControlSet), какой будет определять набор LastKnownGoodMenu и какой был задействован при загрузке, когда произошел сбой. На Экране 3 значение параметра Current указывает на номер той конфигурации NT, которая была загружена при последней загрузке системы. Представленное этим параметром значение используется как номер набора данных CurrentControlSet. В большинстве случаев значения данного параметра и задаваемого по умолчанию одинаковы. В данном примере значение параметра Current равно 0x2. Это означает, что необходимо редактировать набор ControlSet002. После определения правильного набора данных можно изменить состояние службы или драйвера на момент загрузки системы. ТАБЛИЦА 1: Значения параметров запуска для служб и драйверов устройств
| Тип запуска | Значение для устройства (шестнадцатеричное) | Значение для службы (шестнадцатеричное) |
|---|---|---|
| Boot (загрузка) | 0x0 | N/A |
| System (система) | 0x1 | N/A |
| Automatic (автоматически) | 0x2 | 0x2 |
| Manual (ручное) | 0x3 | 0x3 |
| Disabled (отключено) | 0x4 0x4 |
Значения параметров реестра, связанные с установленной службой или драйвером первоначальной системы, находятся в значениях ключа HKEY_LOCAL_MACHINE\SYSTEM2\ControSet00x\имя подозрительной службы или драйвера. В этом ключе SYSTEM2 ссылается на подключ в представленном примере, ControSet00x соответствует тому набору данных, который был определен по процедуре, приведенной выше, а имя подозрительной службы или драйвера — службе или драйверу, который предположительно вызывает сбой. Для каждой из перечисленных в подключе Services служб (или драйверов) хранится несколько значений. В их числе значение параметра Start (значение типа REG_DWORD). Значение этого параметра определяет текущее состояние данной службы или драйвера при старте системы. Присваивание параметру Start значения 0х4 деактивирует данную службу или драйвер, и NT не будет загружать его при старте системы. В Таблице 1 перечислены все возможные значения параметра Start для служб и драйверов устройств. После того как редактирование реестра в автономном режиме будет закончено, необходимо выгрузить импортированный ранее файл ветви реестра. Это делается указанием ветви с присвоенным ранее именем и выбором опции Unload Hive в меню Registry редактора реестра.
После деактивации старта службы или драйвера первоначальной установки системы NT можно успешно изолировать дефектный элемент системы, мешающий корректной загрузке. Определить, какая именно служба (или драйвер) вызвала сбой, можно экспериментально. Дополнительную информацию, которая поможет выявить проблемный компонент системы, можно почерпнуть из журналов регистрации событий и сообщений об ошибках.
Полезные утилиты
Рассказ о методах восстановления систем NT будет неполным без упоминания об утилитах производства независимых компаний, значительно облегчающих этот процесс. ERD Commander и Remote Recover компании Winternals Software, а также NTRecover от Systems Internals относятся к числу весьма полезных программных продуктов производства ведущих поставщиков программ восстановления. И хотя каждая из этих утилит упрощает процесс восстановления разрушенной системы NT, в них используются различные подходы, и они обладают разными возможностями. Так, NTRecover компания Systems Internals позволяет получить доступ к жесткому диску не загружающейся системы через последовательный порт с работоспособной машины. После установления соединения можно копировать и удалять файлы, запускать программу проверки диска Chkdsk или антивирусную программу на жестком диске удаленной системы. В большинстве случаев возможностей программы будет вполне достаточно для успешного восстановления незагружающейся системы.
ERD Commander — мечта администратора NT, ставшая явью. Тот, кто целыми днями мучается с установочными дискетами DOS или Windows 95 несомненно оценит ее по достоинству. Утилита с интерфейсом в виде командной строки загружается с простой трехдюймовой дискеты и может читать и записывать на тома с NTFS. На Экране 4 показан интерфейс утилиты ERD Commander.
ЭКРАН 4. Выполнение операций восстановления утилитой ERD Commander.
Профессиональная версия данной программы предоставляет дополнительные возможности, такие, как поддержка избыточных наборов дисков (наборы дисков, поддерживаемые драйвером NT ftdisk.sys), способность запуска Chkdsk, восстановление утраченных паролей, чтение дисков с FAT32, а кроме того, возможность работы с утилитой Expand и параметры командной строки, которые позволят выборочно управлять начальным состоянием служб и драйверов или деактивировать их.
Remote Recover — новейшая разработка компании Winternals. Эта программа со своим загрузочным диском, который включает в себя сетевой драйвер спецификации NDIS2, позволяющий обеспечить удаленный доступ к томам NTFS не стартующей системы по сети. После получения доступа к файлам системы можно выполнять процедуры восстановления, подобные NTRecover и ERD Commander.
Роль аппаратного обеспечения
Давать какие-либо советы по восстановлению систем после сбоев достаточно опасно. Так, первое, что приходит на ум при виде «голубого экрана смерти» в ходе установки системы NT, это мысль о проблемах с программным обеспечением. Но реальным виновником может быть и неисправное оборудование, и просто сбой в работе какого-либо элемента системы (например, жесткого диска или его контроллера, ошибки в работе оперативной или кэш-памяти, неверно выбранные параметры в установках BIOS). Т. е. ни в коем случае нельзя исключать вероятность того, что сбой в работе аппаратуры может привести к появлению «голубого экрана смерти» и сообщения об ошибке, относящегося к работе программного обеспечения.
Об этой возможности особенно важно помнить при добавлении нового аппаратного компонента в систему или в том случае, если наблюдались сбои в подаче электропитания (полное отключение электричества, броски напряжения и т. д.). Предположим, что на прошлой неделе в сервер была установлена новая факс-плата, и во время тестирования все работало замечательно. Но неделю спустя появились «голубой экран смерти» и сообщение STOP, причем оно не ссылается ни на проблемы с вновь установленным драйвером или службой, ни на неполадки с факс-платой. Причиной такого явления могут быть порождаемые новой факс-платой ошибки взаимодействия с другими платами в компьютере или некорректность работы драйвера, которая возникает только при высоком сетевом трафике. В подобной ситуации круг виновников нарушения работы NT можно примерно определить. Но если попытаться решить проблему, вызванную неисправной аппаратурой, средствами, предназначенными для исправления ошибок, связанных с программным обеспечением (восстановление реестра или даже переустановка NT), можно надолго увязнуть в бесплодных попытках восстановления системы.
Под лежачий камень…
Итак, в своих статьях я рассказал о передовых методах и полезных утилитах, которые имеет смысл применять в экстремальной ситуации, если вдруг система Window NT не загрузится. Что более важно, я описал превентивные меры, которые можно предпринять уже сейчас, дабы увеличить вероятность успешного восстановления системы при сбое и сэкономить время, которое придется потратить на решение возникших проблем. В документации компании Microsoft, как обычно, предлагается воспользоваться программой установки системы NT с параметром Repair или восстановить последнюю рабочую конфигурацию системы, выбрав вариант LastKnownGoodConfiguration при начальной загрузке. Но, к сожалению, эти меры недостаточно эффективны. По большому счету, если активно готовиться к возможным авариям, используя в том числе описанные в статье методы, подобной рекомендацией от Microsoft не придется воспользоваться никогда.
Об авторе
Шон Дейли — один из редакторов журнала Windows NT Magazine и президент компании iNTellinet Solutions, занимающейся консалтингом и сетевой интеграцией. Имеет звание MCSE. Последней из его книг была Optimizing Windows NT, выпущенная издательством IDG Books. С ним можно связаться по адресу электронной почты sean@ntsol.com.
Причуды regback.exe
Regback.exe — одна из самых полезных утилит, поставляемых в составе Microsoft Windows NT Server 4.0 Resource Kit. Однако она имеет некоторые изъяны. Основной недостаток связан с тем, как утилита обращается с частью реестра, содержащей установки текущего пользователя (а именно HKEY_CURRENT_USER) при создании резервной копии. Regback.exe выводит имена файлов ветвей системного реестра, копии которых она создает (например, SOFTWARE, SYSTEM, SECURITY).
РИСУНОК 1. Пример последовательности сообщений программы Regback.exe.
C:\REGBACK>regback 072899.PRE saving SECURITY to 072899.PRE\SECURITY saving SOFTWARE to 072899.PRE\software saving SYSTEM to 072899.PRE\system saving .DEFAULT to 072899.PRE\default saving SAM to 072899.PRE\SAM ***Hive = \REGISTRY\USER\S-1-5-21-36516332-637091160-1803697834-1001 Stored in file \Device\Harddisk1\Partition2\WINDOWS\Profiles\Sean\NTUSER.DAT Must be backed up manually regback <filename you choose> users S-1-5-21-36516332-637091160-1803697834-1001 C:\REGBACK>regback NTUSER.DAT users S-1-5-21-36516332-637091160-1803697834-1001 saving S-1-5-21-36516332-637091160-1803697834-1001 to NTUSER.DAT
На Рисунке 1 показана последовательность сообщений, выводимых утилитой regback.exe. Но, кроме этого, она сообщает о невозможности создания копии файла ветви реестра с именем ntuser.dat, хранящего настройки системы текущего пользователя. Приходится делать копию этого файла вручную. Если не задействован профиль пользователя, хранящийся централизованно на сервере, то для сохранения ваших настроек системы придется это делать обязательно. Инструкции по сохранению файла ntuser.dat, приведенные на Рисунке 1, выглядят устрашающе, тогда как сам процесс достаточно прост. Нужно щелкнуть правой кнопкой мыши в левом верхнем углу окна с командной строкой и воспользоваться опциями появившегося меню Edit, Mark и Edit, Copy для формирования верной команды. Или же можно сконфигурировать окно командной строки для работы с функцией QuickEdit, которая позволяет проводить операции выделения, копирования и вставки с помощью мыши. Необходимо скопировать строку сообщения, которую утилита regback.exe выводит в качестве примера (например, regback users S-1-5-21-36516332-637091160-1803697834-1001), и вставить ее в командную строку. Надеюсь, что в дальнейшем Microsoft исправит этот недостаток, а пока можно воспользоваться предлагаемой последовательностью действий.
WINDOWS 2000 MAGAZINE #02/99
Шон Дейли