Материалы о рабочей средеКогда Windows не запускается

Уэс Миллер (Wes Miller)

Содержание

Итак, что может случиться?
Рабочие инструменты
Операционная система отсутствует
Загрузчик отсутствует
Система загружается – и зависает
Безопасный режим Windows и точки восстановления
Система отказывает до завершения загрузки Windows
Последняя известная работоспособная конфигурация
Система отказывает после запуска Windows

Те, кто работал с Windows хоть какое-то время, вероятно, сталкивался со сбоями. Хотя с каждым выпуском Windows она становилась экспоненциально более надежной, некоторые вещи не может контролировать ни пользователь, ни Windows: драйверы и диски дают сбои, системы поражаются отключениями электричества, и файлы повреждаются. И когда это происходит, пользователи опасаются, что им пора искать новый компьютер. В этой статье я рассмотрю, что может пойти не так в системе Windows и как исправить это, чтобы заставить ее работать снова.

Итак, что может случиться?

За почти 20 лет работы Windows я повидал свою долю незагружавшихся систем. Виновник обычно может быть найден довольно быстро – в зависимости от того, что именно делает система. Давайте разобьем на категории симптомы, демонстрируемые системами Windows и сформулируем определенные для использования при устранении неполадок.

• Система не выполняет BIOS POST (самотестирование при включении питания; нет гудка при включении).
• Система выполняет POST, но сообщает, что Missing Operating System («Операционная система отсутствует») или Operating System not found («Операционная система не найдена»).
• Система выполняет POST, но дает сбой в силу того, что NTLDR либо BOOTMGR не найдены.
• Система начинает загружаться, но зависает при запуске.
• Система начинает загружаться, но дает сбой перед появлением рабочего стола Windows (и этот цикл повторяется).
• Система загружает рабочий стол Windows, но затем дает сбой при работе Windows (и этот цикл повторяется).

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

Увы, это почти всегда проблема с оборудованием. Она может требовать чего-нибудь незначительного, вроде замены батареи CMOS, или непростого, скажем, новой материнской платы или блока питания. Но если POST не происходит, то, вероятно, стоит звонить по номеру телефона поддержки для OEM системы, поскольку эту проблему вряд ли удастся решить самостоятельно.

Рабочие инструменты

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

Прежде чем приступать к работе, вот несколько средств, которые стоит держать под рукой.

• В идеале должен существовать доступ к другому компьютеру, использующему Windows, для помощи при анализе сбоев, который должен нести Инструменты отладки для Windows.
• Должна иметься копия Набора средств для диагностики и восстановления Майкрософт (DaRT), являющегося частью пакета оптимизации рабочей среды Майкрософт (MDOP). 30-дневную оценочную копию можно найти в сети. Как вариант, можно использовать компакт-диск Windows PE (в идеале версию 2.1, особенно в случае восстановления системы Windows Vista или Windows Server 2008).
• Необходимо иметь достаточно большой USB-накопитель для содержания любых аварийных копий памяти с проблемной системы.
• Необходимо иметь средства, необходимые для удаления оборудования с проблемной системы.

Операционная система отсутствует

В случае получения ошибки, связанной с отсутствующей или ненайденной операционной системой (текст может различаться в зависимости от BIOS, используемого на ПК) проблема состоит в том, что, по сути, в системе отсутствует загрузочный сектор – сектор на диске, говорящий, где найти начальный загрузчик. Я лишь однажды неожиданно столкнулся с этой проблемой (компьютер руководителя был поражен скачком напряжения при отключении электричества) и, что удивительно, это была единственная немедленно очевидная проблема.

Увы, после более глубокого разбирательства мы обнаружили, что ее система оказалась полностью утратившей все разделы диска. По иронии судьбы, дело было в Winternals, и после этого мы создали средство, именуемое Disk Commander (см. рис. 1), являющееся сейчас частью набора средств для диагностики и восстановления.

Рис. 1. Средство восстановления Disk Commander

Disk Commander также может быть полезен для восстановления целых удаленных каталогов. В данном случае это было как раз то, что доктор прописал, поскольку оно имело возможность проверить диск на предмет недавно удаленных разделов и полностью восстановить их (см. рис. 2).

Рис. 2. Восстановление раздела диска с помощью Disk Commander

Восстановление разделов не стопроцентно надежно, но не недавно удаленны или потерянных разделах (и при использовании средства вроде Disk Commander) оно имеет неплохую вероятность успеха. Само собой, эта ошибка может быть вызвана другими проблемами (обычно с оборудованием). В статье базы знаний «Сообщение об ошибке «Операционная система не найдена» или «Операционная система отсутствует» при запуске компьютера с операционной системой Windows XP» эта тема раскрыта немного подробнее. Как и в случае проблемы BIOS, если существует проблема оборудования, не дающая диску даже заявить о себе, DaRT или любое другое средство вряд ли чем-нибудь помогут.

Загрузчик отсутствует

Если система использует Windows Server 2003, ошибка отсутствующего загрузчика будет указывать на NTLDR; если она обновлена до Windows Vista или более поздних систем или использует двойную загрузку с ними, это будет BOOTMGR. По сути, сообщение зависит от того, на какой загрузчик указывает загрузочный раздел.

Обычно эта ошибка не случается просто так, хотя я слышал о случаях, когда она происходила во многом так же, как я описал насчет потерянного раздела. В первую очередь следует помнить, что здесь достаточно лишь загрузить Windows PE и заменить файлы NTLDR с NTDetect.com на файлы с компакт диска или общего файлового ресурса с Windows на нем. Необходимо гарантировать, что файлы замены происходят из версии Windows не старшей той, для которой они заменяются (используйте последнюю копию из последнего доступного пакета обновления; эти файлы обратно совместимы). В случае как Windows Vista, так и Windows Server 2008, следует скопировать файл BOOTMGR и убедиться, что каталог Boot (по умолчанию скрытый) также находится на месте.

Статья "An NTLDR or NTDETECT.COM Not Found Error" («Ошибка NTLDR or NTDETECT.COM Not Found») предоставляет дополнительную информацию. Можно отметить, что многие из статей базы знаний Майкрософт предлагают использовать консоль восстановления Windows, и некоторые из них, включая статью «Использование средства Bootrec.exe в среде восстановления для устранения неполадок при запуске Windows Vista», могут быть довольно полезны.

Однако моя рекомендация заключается в использовании в данной ситуации Windows PE. Хотя консоль восстановления и может выполнять некоторые действия проще, чем Windows PE, общая широта возможностей и гибкость Windows PE в целом упрощают приведение в рабочее состояние.

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

В случае повреждений, вызванных отключением электроэнергии или другими проблемами, я также предпочитаю убедиться в отсутствии ошибок, выявленных технологией самостоятельного мониторинга и отчетности (S.M.A.R.T.), в журнале событий. Все, что ведет к потере данных, достаточной для стирания раздела или файлов, может без труда привести к более крупным проблемам впоследствии.

Система загружается – и зависает

У этой проблемы есть симптом, с которым сталкиваются многие, но который редко отражает реальную причину. Очень часто можно увидеть, что виновным в зависании называется agp440.sys. Но этот драйвер – всего лишь нечаянная жертва. Это всего лишь последний загруженный драйвер, как можно увидеть на рис. 3, который показывает систему, загружающуюся в безопасном режиме Windows, прямо перед запуском Windows.

Рис. 3. Драйверы, загружающиеся в безопасном режиме Windows

Некоторые из прочтенных мною статей (включая некоторые из статей базы знаний) предлагают отключение этого драйвера как лучший способ заставить систему работать снова. Это неверно. Чтобы заставить систему работать снова, я предлагаю следующее.

• Начните с удаления любого недавно установленного нового оборудования. Делайте это выборочно, по одному устройству за раз.
• Попробуйте загрузиться в безопасном режиме Windows, чтобы увидеть, работает ли он. Если да, то проблема, вероятно, вызвана драйвером от стороннего производителя (поскольку такие драйверы не запускаются в безопасном режиме).
• Используйте Windows PE, либо ERD Commander (из DaRT) для отключения недавно установленных драйверов. Для получения дополнительных сведений см. боковую панель «Отключение драйверов или служб».
• Попробуйте использовать последнюю известную работоспособную конфигурацию (обсуждаемую ниже), чтобы обнаружить, не является ли источником проблемы недавнее изменение драйвера, не входящего в набор последней работоспособной конфигурации.

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

Отключение драйверов или служб

Как ERD Commander, так и Windows PE позволяют отключать драйверы или службы, вешающие Windows при загрузке, хотя и путем разных по сложности действий.

Чтобы использовать Windows PE для включения и отключения проблемных служб, сперва загрузите Windows PE (убедитесь, что загружаются необходимые драйверы контроллера дисков для системы). Начните с редактора реестра Windows (regedit.exe) и выберите куст HKEY_LOCAL_MACHINE.

Из меню файлов выберите Load Hive («Загрузить куст») и перейдите к C:\Windows\System32\Config\system (вносите изменения по мере необходимости, для соответствия собственному пути Windows) и укажите имя для использования в кусте при редактировании (имя не имеет значения). Перейдите к этому новому key\CurrentControlSet\Services\servicename и отметьте значение Start («Пуск»), которое может составлять от 0 до 4:

0—Загрузка ОС: начата загрузчиком операционной системы в первую очередь.

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

2—Автоматический пуск: диспетчер управления службами (SCM) загружает эти драйверы и службы следующими.

3—Пуск по требованию: эти запускаются SCM по требованию.

4—Отключено: загружаться не будет.

Установите службу или драйвер, которую нужно отключить, на 4. Проделайте это аккуратно – у некоторых драйверов имеются взаимозависимости, так что если отключить их, но не их зависимости, это может привести к полной неработоспособности, а не просто зависанию, системы. По завершении работы выгрузите куст реестра и перезапустите систему. Драйвер или служба больше не должны останавливать процесс загрузки.

При наличии MDOP DaRT делает все очень простым. Достаточно загрузить его, подключиться к установке Windows и, через приложение служб и драйверов, показанное на рис. А, можно будет отключать и включать службы или драйверы через очень простой интерфейс пользователя.

Рис. A. Простой способ отключения драйверов или служб

Безопасный режим Windows и точки восстановления

Само собой, если система зависает или дает сбой при запуске, то может помочь загрузка в безопасном режиме, особенно если под рукой нет копии Windows PE и если безопасный режим запустится. Использовать точки восстановления для восстановления клиентских версий Windows можно лишь при том условии, что эти точки включены и защищают именно те файлы, которые требуется восстановить (обратите внимание: на Windows XP точки восстановления защищают не все файлы).

Важно отметить, что в случае использования Windows PE для восстановления Windows Vista следует загружать ее только с помощью Windows PE 2.0 или более поздних версий. Загрузка с помощью более ранних версий повредит точки восстановления, сделав их бесполезными. (Это обусловлено способом, которым точки восстановления системы на Windows Vista отслеживают записи на диск. Windows PE 1.x не знает, как взаимодействовать с системой, не вызывая записей, ведущих к повреждению точек восстановления).

Система отказывает до завершения загрузки Windows

Существует два класса проблем, часто ведущих к сбоям системы до завершения загрузки Windows. Первый – это повреждение реестра. Оно более распространено в ранних версиях Windows, а также в системах, на которых произошел неожиданный перезапуск. Обычно если повреждение реестра не дает системе запуститься, проблема заключается лишь в небольшом разделе реестра. У Windows Vista имеются две копии реестра, расположенных в папке \windows\system32\config\regback и обе они, в большинстве случаев, не старше 24 часов. Файлы реестра можно попробовать заменить на них.

Как вариант, использование описанного мною подхода для загрузки реестра пока система отключена, с помощью Windows PE, порой решает эту проблему. В редактор реестра Windows встроена логика, пытающаяся исправлять повреждения при их обнаружении. Это исправление повреждений хорошо работало в Windows XP и работает еще лучше в Windows Vista и Windows Server 2008.

Если проблему нельзя исправить через Windows PE 1.6, попробуйте использовать Windows PE 2.x или скопировать реестр на систему Windows Vista, исправить его, используя вышеописанные методы и скопировать обратно. Если это не восстановит систему, сделать, увы, зачастую можно немногое. На старых версиях Windows можно попытаться выполнить восстановление установки, но в целом я бы порекомендовал переустановить все заново. Опять же, следует выполнить chkdsk, чтобы убедиться в отсутствии других проблем.

Вероятно наиболее распространенным источником проблем, ведущих к сбоям системы (синим экранам) перед запуском Windows, являются драйверы. Я рекомендую подготовить компакт-диск DaRT и использовать анализатор сбоев Crash Analyzer (см. рис. 4), простой в использовании механизм для анализа аварийных копий памяти Windows – даже на незагружающейся системе.

Рис. 4. Анализ файла копии памяти с помощью Crash Analyzer

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

1. Скопируйте последний файл(ы) *.dmp с отказавшей системы через Windows PE. Эти файлы размещены в %windir%\minidump\. Если включены полные копии памяти, то они будут находиться в самом каталоге Windows и будут, как минимум, настолько же велики как память в системе (то есть они могут быть довольно объемны).
2. Запустите средства отладки для Windows и, через «Файл»|«Открыть аварийную копию памяти» выберите свежескопированный файл памяти.
3. Установите путь к символам, чтобы предоставить информацию по отладке для диагностики двоичными файлами Windows. Введите:

.sympath= SRV*C:\SYMBOLS\*http://
msdl.microsoft.com/download/symbols

1. и нажмите клавишу ВВОД.
2. Наберите .reload и нажмите клавишу ВВОД.
3. Наберите !analyze –v и нажмите клавишу ВВОД.
4. Результаты скорее всего укажут на виновный драйвер (или драйверы).

Учтите, что можно часто получить фальшивый положительный результат, указывающий на один драйвер, тогда как проблема состоит в другом, так что может быть желателен небольшой поиск по сети на предмет мнений, относящихся к данной ситуации. Часто оказывается, что кто-то уже сталкивался с той же проблемой данного драйвера. Можно использовать вышеописанные действия для отключения драйвера(-ов) или загрузки в безопасном режиме, чтобы увидеть, будет ли от этого какая-то разница.

Последняя известная работоспособная конфигурация

Последняя известная работоспособная конфигурация, показанная на рис. 5, часто может помочь при наличии проблем с системой. Она содержит копию последнего успешно загрузившегося набора драйверов и устройств. Но результат от нее не гарантирован и она не поможет при повреждении реестра. И она может что-то исправить только при сбое Windows перед запуском Win32 (перед тем, как можно увидеть инициализацию запуска рабочего стола Windows). Иначе этот запуск будет считаться нормальным и если Windows потерпит сбой после этой точки, ее нельзя будет восстановить данным способом.

Рис. 5. Выбор последней известной работоспособной конфигурации может сделать возможным запуск системы

Система отказывает после запуска Windows

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

В зависимости от направления, в котором указывает Windbg можно попробовать отключение служб или драйверов или рассмотреть недавно добавленное оборудование. Память (в особенности недавно добавленная память) часто может вызывать сбои, точно так же как и диск, не работающий должным образом. Может возникнуть необходимость связаться с OEM или с независимым поставщиком программного обеспечения, чтобы узнать, не видели ли они таких результатов или провести поиск подобных ситуаций в сети.

При подозрении, что источником проблемы является память, не забудьте опробовать Диагностику памяти Windows (входящую в Windows Vista и Windows Server 2008). Средство диагностики памяти является весьма исчерпывающим способом тестирования ОЗУ системы при наличий подозрений на проблемы, ведущие к сбоям.

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

Уэс Миллер (Wes Miller) — старший технический руководитель продуктов в CoreTrace (CoreTrace.com) в Остине, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.