Проверка windows server 2008 на ошибки

Апр 28, 2017 14:37

Авторское примечание: Статья в первую очередь написана для начинающих системных администраторов, опытные вряд ли почерпнут для себя здесь что-нибудь новое и полезное. Навеяно статьей про GPUPDATE /force (спасибо mrHobbY).

Active Directory – это большой и сложный организм (даже если он состоит и двух контроллеров домена и одного сайта), и для системного администратора очень важно в любой момент времени провести диагностику для анализа работы этого организма.
Ну, а так как по оснасткам ходить и смотреть малоэффективно, по логам системы тоже не всегда поймешь, что происходит, поэтому на помощь приходят различные утилиты. Одна из них – dcdiag от компании Microsoft.
Посмотрим на нее внимательно – ибо полезность данной утилиты трудно переоценить. Я не буду приводить многочисленные ключи данной команды – про них при желании можно и в справке прочитать — а остановлюсь только на тех, – которые использую сам при диагностике на практике.

Первое, что нужно сделать, чтобы работать с этой утилитой – это установить ее к себе на рабочую станцию или на сам сервер (тут каждый волен выбирать сам, но в последних версиях dcdiag – уже в помощи написано, что проверки необходимо запускать на самих серверах — контроллерах домена, за исключением тестов dcPromo и RegisterInDNS). Для Windows 2003 необходимо установить пакет Support Tools c дистрибутива операционной системы, для Windows 7 и 8 – необходимо установить пакет Remote System Administration Tools (они разные для win7, win7sp1, и win8 – будьте внимательны, когда будете скачивать). Кстати, RSAT — сам по себе полезный продукт – внутри много утилит, которые просто необходимы в повседневной жизни администратора домена.
После установки пакета команда уже доступна из командной строки.
Но не торопитесь запускать ее сразу, на рабочей станции ничего не получится без указания контроллера домена, к которому надо подключиться. Утилита выдаст соответствующее предупреждение:

Примечание: начиная с Windows 7 сообщения dcdiag переведены на русский. До этого – все только на английском. Может будет кому полезно. Хотя и в старых версиях очень простой и понятный английский язык.

Замечательно – мы выяснили – что желательно указать контроллер домена с помощью ключа /s: или контекст именования – /n:. Какой сервер указывать понятно – тот контроллер домена, который вы хотите проверить – а вот если указать контекст именования домена – (имя домена другими словами – можно указывать в форматах Netbios, DNS или DN.), то будет найден ближайший (в пределах сайта) контроллер домена (далее КД).
Проведем самую простую проверку: dcdiag /s:dc01-local
И опять беда, хотя кое-что уже видно:

dcdiag /s:dc01-local.local

Диагностика сервера каталогов

Выполнение начальной настройки:
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: Localdc01-local
      Запуск проверки: Connectivity
         ......................... DC01-LOCAL - пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: Localdc01-local
      Запуск проверки: Advertising
         ......................... DC01-LOCAL - пройдена проверка Advertising
      Запуск проверки: FrsEvent
         Ошибка 5 при открытии File Replication Service журнала событий
         \DC01-LOCAL:File Replication Service:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка FrsEvent
      Запуск проверки: DFSREvent
         ......................... DC01-LOCAL - пройдена проверка DFSREvent
      Запуск проверки: SysVolCheck
         ......................... DC01-LOCAL - не пройдена проверка SysVolCheck
      Запуск проверки: KccEvent
         Ошибка 5 при открытии Directory Service журнала событий
         \DC01-LOCAL:Directory Service:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка KccEvent
      Запуск проверки: KnowsOfRoleHolders
         ......................... DC01-LOCAL - пройдена проверка
         KnowsOfRoleHolders
      Запуск проверки: MachineAccount
         ......................... DC01-LOCAL - пройдена проверка MachineAccount
      Запуск проверки: NCSecDesc
         ......................... DC01-LOCAL - пройдена проверка NCSecDesc
      Запуск проверки: NetLogons
         [DC01-LOCAL] В учетных данных пользователя отсутствует разрешение на
         выполнение данной операции.
         Учетная запись, используемая для этой проверки, должна иметь права на
         вход в сеть
         для домена данного компьютера.
         ......................... DC01-LOCAL - не пройдена проверка NetLogons
      Запуск проверки: ObjectsReplicated
         ......................... DC01-LOCAL - пройдена проверка
         ObjectsReplicated
      Запуск проверки: Replications
         [Проверка репликации,DC01-LOCAL] Сбой функции
         DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
         "Доступ к репликации отвергнут."
         ......................... DC01-LOCAL - не пройдена проверка Replications
      Запуск проверки: RidManager
         ......................... DC01-LOCAL - пройдена проверка RidManager
      Запуск проверки: Services
         Не удалось открыть диспетчер управления службой в
         dc01-local.local, ошибка 0x5 "Отказано в доступе."
         ......................... DC01-LOCAL - не пройдена проверка Services
      Запуск проверки: SystemLog
         Ошибка 5 при открытии System журнала событий \DC01-LOCAL:System:
          Отказано в доступе.
         ......................... DC01-LOCAL - не пройдена проверка SystemLog
      Запуск проверки: VerifyReferences
         ......................... DC01-LOCAL - пройдена проверка VerifyReferences


   Выполнение проверок разделов на: Schema
      Запуск проверки: CheckSDRefDom
         ......................... Schema - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Schema - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: Configuration
      Запуск проверки: CheckSDRefDom
         ......................... Configuration - пройдена проверка
         CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Configuration - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: LOCAL
      Запуск проверки: CheckSDRefDom
         ......................... LOCAL - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... LOCAL - пройдена проверка
         CrossRefValidation

   Выполнение проверок предприятия на: LOCAL.local
      Запуск проверки: LocatorCheck
         ......................... LOCAL.local - пройдена
         проверка LocatorCheck
      Запуск проверки: Intersite
         ......................... LOCAL.local - пройдена
         проверка Intersite

Как мы видим, часть тестов пройдена – но части отказано в доступе. Это из-за того, что dcdiag я запускал из-под обычной учетной записи домена, без администраторских прав. Понятно – что часть проверок пройти под ней просто невозможно. Поэтому, что бы получить правильную диагностику, необходимо запускать утилиту с административными полномочиями – либо запустить командную строку от имени администратора, либо использовать ключи /u: имя доменаимя пользователя и /p: пароль. Попробуем:
dcdiag /s:dc01-local /u:localuser19 /p:Password

Диагностика сервера каталогов

Выполнение начальной настройки:
   * Идентифицирован лес AD.
   Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

   Сервер проверки: MagadanDC01-LOCAL
      Запуск проверки: Connectivity
         ......................... DC01-LOCAL - пройдена проверка Connectivity

Выполнение основных проверок

   Сервер проверки: MagadanDC01-LOCAL
      Запуск проверки: Advertising
         ......................... DC01-LOCAL - пройдена проверка Advertising
      Запуск проверки: FrsEvent
         ......................... DC01-LOCAL - пройдена проверка FrsEvent
      Запуск проверки: DFSREvent
         ......................... DC01-LOCAL - пройдена проверка DFSREvent
      Запуск проверки: SysVolCheck
         ......................... DC01-LOCAL - пройдена проверка SysVolCheck
      Запуск проверки: KccEvent
         ......................... DC01-LOCAL - пройдена проверка KccEvent
      Запуск проверки: KnowsOfRoleHolders
         ......................... DC01-LOCAL - пройдена проверка
         KnowsOfRoleHolders
      Запуск проверки: MachineAccount
         ......................... DC01-LOCAL - пройдена проверка MachineAccount
      Запуск проверки: NCSecDesc
         ......................... DC01-LOCAL - пройдена проверка NCSecDesc
      Запуск проверки: NetLogons
         ......................... DC01-LOCAL - пройдена проверка NetLogons
      Запуск проверки: ObjectsReplicated
         ......................... DC01-LOCAL - пройдена проверка
         ObjectsReplicated
      Запуск проверки: Replications
         ......................... DC01-LOCAL - пройдена проверка Replications
      Запуск проверки: RidManager
         ......................... DC01-LOCAL - пройдена проверка RidManager
      Запуск проверки: Services
            Недопустимый тип службы: RpcSs на DC01-LOCAL, текущее значение -
            WIN32_OWN_PROCESS, ожидаемое значение - WIN32_SHARE_PROCESS
         ......................... DC01-LOCAL - не пройдена проверка Services
      Запуск проверки: SystemLog
         ......................... DC01-LOCAL - пройдена проверка SystemLog
      Запуск проверки: VerifyReferences
         ......................... DC01-LOCAL - пройдена проверка VerifyReferences


   Выполнение проверок разделов на: Schema
      Запуск проверки: CheckSDRefDom
         ......................... Schema - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Schema - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: Configuration
      Запуск проверки: CheckSDRefDom
         ......................... Configuration - пройдена проверка
         CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... Configuration - пройдена проверка
         CrossRefValidation

   Выполнение проверок разделов на: LOCAL
      Запуск проверки: CheckSDRefDom
         ......................... LOCAL - пройдена проверка CheckSDRefDom
      Запуск проверки: CrossRefValidation
         ......................... LOCAL - пройдена проверка
         CrossRefValidation

   Выполнение проверок предприятия на: LOCAL.Local
      Запуск проверки: LocatorCheck
         ......................... LOCAL.Local - пройдена
         проверка LocatorCheck
      Запуск проверки: Intersite
         ......................... LOCAL.Local - пройдена
         проверка Intersite

ак видим, проверки пройдены почти все – кроме проверки Services. Но тут у меня есть вполне логичное объяснение – я с помощью новой утилиты (из пакета для windows 7) пытаюсь проверять контроллер домена на базе win2003 – и вполне возможно, название службы может отличаться.

Лирическое отступление №1. При подготовке статьи я столкнулся с

epic fail

забавным феноменом, может в комментариях обсудим? :). В общем, запуская dcdiag из-под обычной учетной записи другого домена (связанного доверительными отношениями с исследуемым доменом local) и задавая параметры /u и /p – (имя пользователя и пароль административной учетной записи домена local) – утилита выдавала ошибки в части проверок — например sysvolchek (в версии dcdiag 2003 – frssysvol). Если же на рабочую станцию зайти под учетной записью с административными полномочиями в домене local — проверки прекрасно проходятся. Так что – может быть, все-таки не лишним будет проводить проверку на самом сервере. Конец лирического отступления №1.

Полностью описывать результаты работы команды я не вижу смысла. Это прекрасно описано в помощи к утилите (dcdiag /h). Видно главное – с данным контроллером домена проблем нет и все тесты пройдены. Но из проверки одного сервера – не следует факт, что AD сейчас находится в

шоколаде

работоспособном состоянии. И вот здесь нам на помощь придет ключ для проверки всех серверов предприятия.
Это ключ /e. Данный ключ заставляет утилиту обойти все КД в домене с запуском всех тестов на каждом сервере. Полезно вместе с этим применить /v – вывод расширенной информации по каждому тесту. Ну и чтобы проанализировать все это – полезно данные вывести в файл – причем лог отдельно, сообщения об ошибках – отдельно. Помогут в этом ключи /f: имя_файла_лога и ferr:/имя_файла_лога_ошибок (в новых версиях ключ /ferr убран). Если вы хотите провести проверку не того домена, в котором находитесь сейчас – добавите ключ для указания наименования контекста /n:.

Полностью команда выглядит так:
dcdiag /n:local /e /v /f:c:logsadtest.log /ferr:c:logsaderrors.log /u:localuser19 /p:Password

Внимание! В версиях dcdiag, начиная с windows 2008 ключ /ferr: убран из поддерживаемых (специально повторился :)).
Если у вас сложная структура леса, да еще и с медленными каналами связи приготовьтесь подождать. Да даже и если несложная – скажем у меня в одном реальном лесе – 10 КД, 5 сайтов и каналы 256 кбит/сек. Выполнение данной команды занимает в среднем до 20 минут.
Результат исполнения очень рекомендуется внимательно просмотреть на наличие проблем. Ну и очень желательно запускать данную утилиту регулярно для диагностики здоровья AD.
Для хардкора можно еще добавить ключ /fix – внесение безопасных исправлений, но бездумно все-таки этого делать не стоит.

Вот собственно и все что я хотел сегодня рассказать. А как часто вам приходится пользоваться данной утилитой на производстве? Какие альтернативы вы знаете?

update 1: Что-то вспомнилось, опять же из личного опыта: если у вас большой домен, связанный небыстрыми (например, спутниковыми) каналами связи — утилита будет выдавать массу ошибок в случае ее отсутствия — чаще всего, что недоступен RPC. Это нормально, и про это надо знать. Если большинство тестов оканчивается подобным сообщением — значит нет связи, необходимо применять меры по устранению сбоя. Вторая часто распространенная проблема — ошибки в DNS — но это тема уже для отдельной статьи.
p.s. к update 1 -dcdiag /fix — в том числе регистрирует по новой записи в dns службы netlogon — это тоже бывает полезно знать!

Джон Марлин

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

Первое, с чем предстоит работать – диспетчер отказоустойчивости кластеров. Этот новый инструмент управления кластером позволяет руководить группами и ресурсами и выполнять диагностику неполадок. Диспетчер отказоустойчивости кластеров открывается из пункта «Администрирование» в меню «Пуск».

Каналы событий

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

— FailoverClustering

* Operational

* Diagnostic (если выбран пункт Show Analytic and Debug Logs («отобразить журналы анализа и отладки»))

* Performance-CSV (если выбран пункт Show Analytic and Debug Logs)

— FailoverClustering-Client

* Diagnostic (если выбран пункт Show Analytic and Debug Logs)

— FailoverClustering-Manager

* Admin

* Diagnostic (если выбран пункт Show Analytic and Debug Logs)

— FailoverClustering-WMIProvider

* Admin

* Diagnostic (если выбран пункт Show Analytic and Debug Logs).

Экран 1. Каналы, относящиеся к?отказоустойчивой кластеризации

События запуска/остановки службы кластеров, перемещения групп, перевода групп в онлайн/автономный режим и т.д. регистрируются в журнале FailoverClusteringOperational. Например:

-Идентификатор события: 1061

-Описание: служба кластеров успешно настроила отказоустойчивый кластер JohnsCluster.

Неудачные попытки установления соединения с другими узлами при открытии диспетчера отказоустойчивости кластеров регистрируются в журнале FailoverClustering-ManagerAdmin. Например:

-Идентификатор события: 4684

-Описание: диспетчеру отказоустойчивости кластеров не удалось связаться с серверами DNS для разрешения имени W2K8-R2-NODE2.contoso.com. Дополнительные сведения можно найти в канале диагностики диспетчера отказоустойчивости кластеров.

В журнале FailoverClustering-ManagerDiagnostic можно увидеть следующее:

-Идентификатор события: 4609

-Описание: ошибка при попытке проверки связи с W2K8-R2-NODE2.contoso.com. System.ApplicationException: не удалось связаться с одним или несколькими DNS-серверами. Убедитесь в правильности настройки DNS и полном подключении компьютера к сети.

-Идентификатор события: 4612

-Описание: проверка связи с W2K8-R2-NODE2.contoso.com завершилась сбоем.

Именно по этим событиям можно установить проблему подключения узла к серверу DNS и затем приступить к ее устранению. Не просматривая указанные журналы, о наличии неполадок можно будет судить по тому, что в диспетчере отказоустойчивости кластеров узел W2K8 R2-NODE2 будет отображен как неисправный. Еще один журнал в числе упомянутых выше, Failover-ClusteringDiagnostic, мы обсудим несколько позже.

Диспетчер отказоустойчивости кластеров

Для упрощения анализа системные ошибки и предупреждения можно просматривать из окна диспетчера отказоустойчивости кластеров. На главной странице на центральной панели находится ссылка на последние события кластера Recent Cluster Events (экран 2). Эта ссылка позволяет вывести на экран все предупреждения и ошибки, связанные с отказоустойчивым кластером, за последние 24 часа. События, собранные со всех узлов, сосредоточены в одном месте, что избавляет от необходимости открывать несколько журналов событий на нескольких компьютерах.

Экран 2. Последние события кластера

Для просмотра конкретных событий можно использовать элемент Query, доступ к которому открывается из элемента Cluster Events на левой панели главной страницы. В меню, которое мы открываем правым щелчком на Cluster Events, выберите пункт Query, либо укажите Query на панели Actions справа. На экране 3 показан фильтр событий кластера.

Экран 3. Фильтр событий кластера

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

Поиск событий определяют два параметра. События появления отказов можно искать по всем ресурсам, либо только по конкретному ресурсу. Для этого в меню Actions (экран 4) можно выбрать пункт Show the critical events for this application («Отображение критических событий для данного приложения») или Show the critical events for this resource («Отображение критических событий для данного ресурса»). Это позволяет формировать запрос всех событий из текущих журналов, создаваемых на всех узлах, либо ограничить список запрашиваемых событий рамками заданного периода времени или узла.

Экран 4. Пункт Actions в диспетчере отказоустойчивости кластеров

Журнал диагностики – эквивалент Cluster.Log в Windows 2003 Server Cluster. Начиная с отказоустойчивой кластеризации, реализованной в Server 2008, функции журнала больше соответствуют процессу трассировки событий для Windows Event Tracing (ETW). Вместо текстового файла Cluster.Log запись осуществляется в журнал диагностики, хранящийся в папке C:WindowsSystem32winevtlogs. Существует три журнала диагностики, куда осуществляется запись (clusterlog.etl.001, clusterlog.etl.002 и clusterlog.etl.003). В ходе каждой отдельной загрузки запись происходит только в один из журналов. Более подробные сведения о файлах журналов и их применении можно найти в блоге «Understanding the Cluster Debug Log in 2008» (http://blogs.technet.com/b/askcore/archive/2010/04/13/understanding-the-cluster-debug-log-in-2008.aspx).

Журнал диагностики включен и постоянно осуществляет запись. Если в меню, открываемом правым щелчком на FailoverClusteringDiagnostic, выбрать команду Disable log («Отключить журнал»), то можно просмотреть все записанные события. После отключения журнала система перестает записывать в него данные, и информация не сохраняется. Если журнал был отключен, то лучше всего сохранить данные в виде журнала событий или текстового файла и включить журнал снова. В журнале регистрируются три основных типа событий:

*событие 2049 – информационное;

*событие 2050 – предупреждение;

*событие 2051 – ошибка.

Эти события выводятся только из текущего журнала трассировки событий. ETL, в который осуществляется запись. Информация о событиях отображается так же, как в системном журнале и журнале приложения. Однако каждое событие занимает отдельную строку, поэтому просмотр всего журнала диагностики может оказаться делом довольно утомительным. Можно создать текстовый файл Cluster.Log с помощью команд, позволяющих свести воедино три журнала, что значительно облегчает восприятие информации.

Команда PowerShell Get-ClusterLog инициирует на всех узлах создание журнала Cluster.Log, который помещается в папку C:WindowsClusterReports. Меню Get-ClusterLog содержит пункты, которые могут оказаться полезными в определенных обстоятельствах. Например, для выяснения причин проблемы можно воспроизвести ее, а затем воспользоваться командой

Get-ClusterLog -TimeSpan 5

для вывода данных за последние 5 минут. Поскольку требуется журнал только с одного узла, на котором воспроизводится проблема, можно добавить параметр Node Nodename для создания Cluster.Log только на этом узле. Если требуется пересылка журналов с нескольких узлов, то установление соединения с каждым из них для получения нужного файла может занять некоторое время. В этом случае можно воспользоваться параметром –Destination, который обеспечит создание Cluster.Log на каждом узле и последующее копирование этого журнала в заданную папку в виде файла под именем, к которому прикреплено имя компьютера (например, W2K8-R2-Node1_Cluster.Log).

Создаваемый журнал Cluster.Log – это моментальный снимок во времени, который фиксирует текущее состояние и уже не обновляется. Если при создании журнала в папке Reports уже есть Cluster.Log, то существующий файл удаляется и освобождается место для нового.

Система наблюдения за ресурсами

Теперь перейдем к системе наблюдения за ресурсами Resource Host System (RHS), одной из функций которой является отслеживание состояния всех ресурсов в кластере. Система выполняет серию проверок (базовых и полных). Если ресурс не реагирует на проверку, то RHS генерирует следующее системное событие:

-Идентификатор события: 1230

-Описание: ресурс кластера ‘Cluster Disk 1’ (resource type», DLL ‘clusres.dll’) либо поврежден, либо заблокирован.

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

Проводя диагностику события RHS, необходимо проанализировать проблемный ресурс. Если диск заблокирован, следует проверить все содержимое стека диска. Возможно, причиной является медленный в/в диска, либо потерян путь к нему. Это должно быть ориентиром проводимой диагностики. На следующем этапе выполняется поиск относящихся к диску событий в системном журнале, анализ системного монитора, обновление драйверов и т.д. Если ресурсом является IP-адрес или сетевое имя, то в центре внимания должен быть сетевой стек и все его содержимое.

Проверка кластера

Последняя тема обсуждения – отчет о результатах проверки кластера Cluster Validate. Чтобы кластер был «кондиционным», все его компоненты должны быть перечислены в каталоге Windows Server, и необходимо, чтобы он прошел полную проверку. Многие запускают проверку кластера до или сразу после создания. Однако если проблемы возникают позже, то лишь немногие помнят об этой функции, которую также можно использовать как средство диагностики. Если возникают проблемы с диском, запустите тесты хранилища Storage Tests. При наличии проблем с сетевой передачей данных воспользуйтесь сетевыми тестами Network Tests. С помощью функции проверки кластера можно также получить данные о группах, ресурсах и параметрах текущего отказоустойчивого кластера для обращения к этим сведениям в дальнейшем.

Достоинством проверки кластера является возможность ее запуска без прерывания рабочего процесса. При выборе теста хранилища Storage Test выдается вопрос, следует ли переводить работающие группы в автономный режим (экран 5). Установка по умолчанию предполагает невмешательство в работу групп, находящихся в режиме онлайн, и рабочий процесс не затрагивается. Тесты хранилища предусматривают проверку дисков, которые:

— принадлежат группам в автономном режиме;

— принадлежат активной группе хранения;

— не являются частью кластера.

Экран 5. Проверка кластера

При каждом запуске проверки кластера в каталоге C:WindowsClusterReports на каждом проверяемом узле создается файл с именем, часть которого составляют дата и время.

Существуют и другие способы диагностики отказоустойчивых кластеров, однако для их описания в этой статье не хватило бы места. Однако приведенные здесь рекомендации применимы к большинству проблем, с которыми вы можете столкнуться. Для получения дополнительной информации посетите блог Ask the Core Team (http://blogs.technet.com/b/askcore/) или Clustering and High Availability (http://blogs.msdn.com/b/clustering/). Успешной кластеризации!

Sfc /scannow — это команда командной строки, которая позволяет сканировать вашу систему Windows на наличие ошибок и исправлять их.

sfc /scannow

sfc /scanfile=c:windowssystem32ieframe.dll

sfc /scannow /offbootdir=c: /offwindir=c:windows

sfc /verifyonly

Как использовать инструмент Scannow SFC в Windows XP

Windows XP имеет возможность защитить себя от нестабильности системы, вызванной сторонним программным обеспечением, переписывающим важные системные файлы.

Раньше это было (и по-прежнему на самом деле), проблема с Windows 95 и Windows 98.

С введением Windows Millennium Edition Microsoft предприняла настоящие усилия, чтобы остановить это.

Теперь в Windows XP у нас есть гораздо более совершенная защита этих важных файлов …

Основная причина использования этой утилиты — когда вы подозреваете, что может возникнуть проблема с системным файлом Windows XP.

Возможно, вы получите диалоговое окно, сообщающее вам о проблеме с DLL-файлом или ваша программа просто не загружается! Поэтому стоит проверить, есть ли поврежденные системные файлы, используя scannow sfc.

Для этого просто перейдите в поле «Выполнить» в меню «Пуск» и введите:

sfc /scannow.

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

В идеальном мире, который станет концом истории … Любые поврежденные, отсутствующие или неправильные файлы будут заменены этим процессом.

Как использовать Sfc /Scannow для восстановления Windows 7

1. Первый шаг — открыть окно с повышенными командами. Для Windows 7 нажмите «Пуск» и введите cmd в поле «Поиск». Щелкните правой кнопкой мыши на cmd, чтобы получить раскрывающийся список. В списке нажмите «Запуск от имени администратора».
2. Когда откроется окно командной строки, введите sfc /scannow и нажмите enter
   Процесс сканирования файлов поврежденных файлов занимает около 10-15 минут. Не закрывайте окно командной строки в течение этого времени.
3. После того, как система выполнит 100% сканирование, могут быть два результата. В случае, если не обнаружено ошибок, появится сообщение: «Защита Windows не обнаружила нарушений целостности».
   В случае обнаружения ошибки система обнаружит ошибки и устранит их.

Также есть вероятность, что в окне появится сообщение о том, что Windows Resource Protection обнаружила поврежденные файлы, но не смогла исправить некоторые из них.

В таких случаях команда sfc /scannow требует дополнительной информации о местонахождении диска, на котором установлена ​​Windows 7.

Запуск сканирование SFC /SCANNOW помимо командной строки

При запуске sfc /scannow из-за пределов Windows, например, из командной строки, доступной при загрузке с установочного диска Windows или флеш-накопителя или с вашего диска восстановления системы или накопителя, вам нужно будет сообщить команду sfc точно, где Windows существует.

sfc /scannow /offbootdir=d: /offwindir=d:windows

Параметр /offbootdir = указывает букву диска, в то время как параметр / offwindir = указывает путь к Windows, снова включающий букву диска.

Примечание. В зависимости от того, как настроен ваш компьютер, командная строка при использовании извне Windows не всегда назначает буквы дисков так же, как вы видите их изнутри Windows. Другими словами, Windows может быть в C: Windows, когда вы ее используете, но D: Windows из командной строки в ASO или SRO.

В большинстве установок Windows 10, Windows 8 и Windows 7 C: обычно становится D: и в Windows Vista C: обычно остается C :. Чтобы убедиться в этом, найдите диск с папкой « Пользователи » на нем — это будет диск, на котором установлен Windows, если у вас нет нескольких установок Windows на нескольких дисках. Вы можете просматривать папки в командной строке с помощью команды dir .