Иллюстрация: Стив Адамс

А вы задумывались над тем, что будете делать, если однажды ваш сервер зависнет после перезагрузки системы? И, что не менее важно, сколько времени вам потребуется на решение возникшей проблемы? Большинство администраторов Windows NT при одной мысли о возможности увидеть голубой экран с кучей цифр и надписью STOP (известный как blue screen of death) бросает в холодный пот. Впрочем, и любая другая неполадка в работе сервера компании не может вызвать улыбку.

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

Причин, по которым система Windows NT может остановиться при загрузке, много, но результатом их действия почти всегда является ужасающий «голубой экран смерти» (см. экран 1). После того как Windows NT останавливает систему, она выводит этот экран, чтобы предотвратить дальнейшее нарушение целостности данных.

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

Каждый из этих сценариев имеет различные причины и решения, поэтому дальше рассмотрим их по отдельности более подробно.

Системный реестр — сердце системы NT. Поэтому в зависимости, от вида и степени нарушения целостности, поврежденный реестр весьма часто вызывает сбой при загрузке операционной системы. Нарушения целостности реестра могут быть физические и логические. Физическое нарушение подразумевает, что какие-то неполадки (обычно сбои в работе дисковой подсистемы) вносят путаницу в файлы реестра (например, в файлы SOFTWARE или SYSTEM в системном каталоге %winntroot%system32config). Логические нарушения означают, что приложение, пользователь или сама операционная система записали в реестр неверные данные, которые в свою очередь могут вызвать сбой при загрузке, если значение данного ключа в реестре достаточно критично.

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

Если имеются основания подозревать, что проблемы с загрузкой связаны именно с реестром, можно начать восстановление с использованием варианта загрузки предыдущей конфигурации (Last known good configuration). Это можно сделать несколькими путями.

Вариант Last known good configuration. Вы можете воспользоваться этой опцией при появлении соответствующей подсказки и нажатии клавиши пробела в период загрузки системы. Выбрав эту опцию, вы загрузитесь с предыдущей работоспособной конфигурацией. Это самый быстрый и легкий способ, если, конечно, он срабатывает. К сожалению, шансы на успех в реальной ситуации не так уж велики, поскольку данный способ ограничивается восстановлением только одной части реестра (а именно, ветви ControlSet00X в ключе HKEY_LOCAL_MACHINESYSTEM). То есть вы сможете восстановить систему данным способом, только если проблема ограничена данной ветвью реестра и вы сразу использовали вариант Last known good configuration. Однако в большинстве случаев предложенный метод не поможет.

Восстановление через процесс установки и с помощью дискеты восстановления ERD (Emergency Repair Disk). Можно воспользоваться процедурой установки NT для проверки и замены индивидуальных файлов реестра, если первый способ не сработал. После установки дискеты восстановления ERD в дисковод вы должны будете указать, какую часть существующей операционной системы требуется проверить (см. экран 2). Если вы выберете пункт Inspect registry files, появится список файлов реестра, и вы сможете указать, какие из них нужно заменить. Заменяющие файлы берутся либо с диска ERD, либо из каталога %systemroot%repair. Файлы на диске ERD и в каталоге %systemroot% repair хранятся в сжатом виде, и каждый из них имеет расширение в виде подчерка «_» (например, SYSTEM._, SOFTWARE._).

Использование самых последних копий заменяющих файлов позволит не потерять важную информацию о конфигурации приложений и системы. Созданию диска 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 по http://www.internals.com или NTFS-DOS от Winternals Software по http://www.winternals.com. После загрузки альтернативной системы вы имеете возможность выполнить те же действия по восстановлению, что и при использовании программы установки и выборе опции восстановления, но с большей гибкостью и избирательностью. И хотя специалисты из Microsoft не рекомендуют применять данный способ, мы считаем, что он лучше всего подходит для опытных пользователей NT. Более подробная информация об использовании параллельно установленной системы находится во врезке «Параллельное мышление».

Прежде чем начать операцию восстановления, сделайте копии своих файлов реестра. Я обычно копирую существующие файлы в подкаталог каталога, содержащего файлы реестра (например, %systemroot%system32configbackup). Только после этого можно начинать эксперименты с заменой отдельных файлов реестра. Однако вы не можете просто скопировать файлы, которыми будете заменять поврежденные, поскольку на дискете ERD и в каталоге %systemroot%repair эти файлы хранятся в сжатом виде. Перед использованием этих файлов примените к ним команду expand.exe, чтобы разархивировать их вручную. Например, чтобы развернуть сжатую копию ветви SYSTEM с дискеты ERD или из каталога %systemroot%repair, наберите в командной строке NT:

Скопируйте получившийся файл в %systemroot%system32config первоначальной системы и перезагрузитесь.

Если вы не хотите иметь дело со сжатыми файлами, можете использовать утилиту 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.