Как проверить windows server на ошибки

В статье «Диагностика проблем кластеров Windows Server 2008 R2», опубликованной в Windows IT Pro/RE № 10 за 2012 год, говорилось об устранении неполадок кластеров с обходом отказов. В частности, приводились рекомендации по извлечению информации, необходимой для диагностики проблем. На этот раз я хочу рассказать о расширенных средствах поиска и устранения неисправностей кластеров с обходом отказов в Windows Server 2012 и об их наиболее эффективном применении.

Знакомство с новыми каналами событий

В диагностике проблем кластеров с обходом отказов могут помочь новые каналы событий. На экране 1 показаны все существующие ка-налы. Заметим, что все события относятся к текущему узлу.

Экран 1. Каналы событий кластеров с?обходом отказов в?Server 2012

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

* FailoverClustering

— Diagnostic. Это главный журнал, генерируемый всякий раз при запуске службы кластеров. Если функция ведения журнала выклю-чена, события могут выводиться в окно программы просмотра со-бытий Event Viewer. Данные журнала можно преобразовать в тек-стовый файл.

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

— Performance-CSV. Этот канал используется для сбора информа-ции, касающейся функционирования общих томов кластера (CSV).

* FailoverClustering-Client

— Diagnostic. Этот канал используется для сбора данных журнала трассировки API Cluster. Данные журнала могут быть полезны для выявления причин ошибок при выполнении действий по созданию кластера (Create Cluster) и добавления узла в кластер (Add Node Cluster).

* FailoverClustering-CsvFlt (новый канал в Server 2012)

— Diagnostic. По этому каналу осуществляется сбор данных жур-нала трассировки драйвера фильтра CSV (CsvFlt.sys), установ-ленного только на узле координатора для CSV. Данные журнала позволяют выявить причины сбоев операций с метаданными и пе-ренаправленных операций ввода/вывода.

* FailoverClustering-CsvFs (новый канал в Server 2012)

— Diagnostic. Этот канал используется для сбора данных журнала трассировки драйвера файловой системы CSV (CsvFs.sys), ус-тановленного на всех узлах кластера. Данные журнала позволяют диагностировать проблемы прямых операций ввода/вывода.

* FailoverClustering-Manager

— Admin. На этом канале регистрируются ошибки, связанные с диалоговыми окнами и всплывающими предупреждениями, отобра-жаемыми в окне диспетчера кластеров.

* FailoverClustering-WMIProvider

— Admin. Этот канал используется для регистрации событий, связанных с поставщиком WMI кластеров с обходом отказов.

— Diagnostic. Журнал трассировки, связанный с поставщиком WMI кластера, который можно использовать для диагностики ошибок сценариев инструментария управления Windows (WMI) или прило-жений Microsoft System Center.

Использование канала FailoverClustering-Client/Diagnostic

При создании кластеров и присоединении узлов к кластеру нередко возникают проблемы, поэтому важно знать, как применять журнал FailoverClustering-Client/Diagnostic. По умолчанию этот канал выключен, и данные не регистрируются. Для включения канала щелкните на нем правой кнопкой и выберите Enable Log. После этого начинается сбор информации, относящейся к операциям присоединения и создания.

Предположим, что при включенном канале Diagnostic возникла проблема при создании кластера. Для просмотра собранных данных щелкните на канале правой кнопкой и выберите Disable Log. В журнале FailoverClustering-Client/Diagnostic можно увидеть следующее:

Event ID: 2
Level: Error
Description: CreateCluster (1883): Create cluster failed
with exception. Error = 8202, msg: Failed to create
cluster name CLUSTER on DC DC.CONTOSO.COM. Error 8202.
Event ID: 2
Level: Error
Description: CreateClusterNameCOIfNotExists (6879): Failed
to create computer object CLUSTER on DC DC.CONTOSO.COM
with OU ou=Clusters,dc=contoso,dc=com. Error 8202.

Для просмотра значения кода состояния ошибки (8202) восполь-зуемся командой Net.exe:

NET HELPMSG 8202

Команда возвращает сообщение The specified directory service attribute or value does not exist («Указанное значение или атрибут службы каталогов не существует»). Новые возможности кластеров с обходом отказов Server 2012 предполагают, что кластер создается в том же подразделении (OU), что и узлы. Для создания имени кластера активный пользователь должен иметь, как минимум, разрешения Read и Create Computer Objects. Если пользователь не обладает такими правами, имя кластера не соз-дается, и выдается ошибка такого типа.

Теперь предположим, что ошибка возникает при добавлении узла в существующий кластер. При просмотре журнала FailoverClustering-Client/Diagnostic видим следующее:

Event ID: 56
Level: Warning
Description: AsyncNotificationCallback (1463): ApiGetNotify
on hNotify=0x0000000021EBCDC0 returns 1 with rpc_error 0
Event ID: 2
Level: Error
Description: SCMStateNotify (837): Repost of
NotifyServiceStatusChange failed for node
'NodeX': status = 1168

Описание первого события указывает на ошибку вызова удаленной процедуры (RPC). В описании второго события содержится код состояния 1168. Чтобы узнать значение кода, снова воспользуемся командой Net.exe:

NET HELPMSG 1168

На этот раз команда возвращает сообщение Element not found («Элемент не найден»). При попытке присоединения узла кластеру необходимо установить соединение RPC с присоединяемым узлом. В данном случае кластер не находит узел.

Из полученной информации можно заключить, что рабочий узел кластера не может установить RPC-соединение с добавляемым узлом, поскольку не находит его. После дальнейшего анализа выясняется, что на сервере DNS у добавляемого узла некорректный IP-адрес. После исправления IP-адреса узел успешно присоединяется к кла-стеру.

Новые тесты мастера проверки настроек

Полезным инструментом диагностики ошибок является мастер про-верки настроек Validate a Configuration Wizard, который в Server 2012 дополнен новыми тестами кластеризации. В приведенном ниже списке новые тесты выделены жирным шрифтом.

* Hyper-V (только если установлена роль Hyper-V):

— List Hyper-V Virtual Machine Information;

— List Information About Servers Running Hyper-V;

— Validate Compatibility of Virtual Fibre Channel SANs for Hyper-V;

— Validate Firewall Rules for Hyper-V Replica Are Enabled;

— Validate Hyper-V Integration Services Version;

— Validate Hyper-V Memory Resource Pool Compatibility;

— Validate Hyper-V Network Resource Pool and Virtual Switch Compatibility;

— Validate Hyper-V Processor Pool Compatibility;

— Validate Hyper-V Role Installed;

— Validate Hyper-V Storage Resource Pool Compatibility;

— Validate Hyper-V Virtual Machine Network Configuration;

— Validate Hyper-V Virtual Machine Storage Configuration;

— Validate Matching Processor Manufacturers;

— Validate Network Listeners Are Running;

— Validate Replica Server Settings.

* Cluster Configuration (только для рабочего кластера):

— List Cluster Core Groups;

— List Cluster Network Information;

— List Cluster Resources;

— List Cluster Volumes;

— List Clustered Roles;

— Validate Quorum Configuration;

— Validate Resource Status;

— Validate Service Principal Name;

— Validate Volume Consistency;

* Inventory:

— Storage

—List Fibre Channel Host Bus Adapters

—List iSCSI Host Bus Adapters

—List SAS Host Bus Adapters

— System

—List BIOS Information

—List Environment Variables

—List Memory Information

—List Operating System Information

—List Plug and Play Devices

—List Running Processes

—List Services Information

—List Software Updates

—List System Drivers

—List System Information

—List Unsigned Drivers

* Network:

— List Network Binding Order;

— Validate Cluster Network Configuration;

— Validate IP Configuration;

— Validate Network Communications;

— Validate Windows Firewall Configuration.

* Storage:

— List Disks

— List Potential Cluster Disks

— Validate CSV Network Bindings

— Validate CSV Settings

— Validate Disk Access Latency

— Validate Disk Arbitration

— Validate Disk Failover

— Validate File System

— Validate Microsoft MPIO-Based Disks

— Validate Multiple Arbitration

— Validate SCSI device Vital Product Data (VPD)

— Validate SCSI-3 Persistent Reservation

— Validate Simultaneous Failover

— Validate Storage Spaces Persistent Reservation

* System Configuration:

— Validate Active Directory Configuration

— Validate All Drivers Signed

— Validate Memory Dump Settings

— Validate Operating System Edition

— Validate Operating System Installation Option

— Validate Operating System Version

— Validate Required Services

— Validate Same Processor Architecture

— Validate Service Pack Levels

— Validate Software Update Levels

Кроме тестов хранилища, все тесты можно запускать в любой мо-мент, так как они не нарушают работу кластера.

Использование мастера проверки настроек

Рассмотрим применение мастера проверки настроек Validate a Configuration Wizard. Для предыдущего примера с проблемой при добавлении узла предположим, что IP-адрес на DNS правильный, и соединение между узлами за пределами кластера может быть установлено. В этом случае можно запустить мастер проверки настроек.

При работе мастера возникает ошибка выполнения теста Net-work/Validate Windows Firewall Configuration. В ходе этого теста при анализе параметров брандмауэра Windows выясняется, что порт 3343, используемый кластером, не включен. Если порт отключен, вся идущая через него связь блокируется, и канал Diagnostic выдает ошибки.

Новый параметр команды Get-ClusterLog

Команда Get-ClusterLog из инструментария PowerShell позволяет преобразовать регистрируемые в журнале (например, Failover-Clustering/Diagnostics) события в текстовый файл. Текстовый файл именуется Cluster.log и помещается в папку C:WindowsClusterReports. По умолчанию, при выполнении команды для каждого узла создается свой файл Cluster.log. Изменить это можно с помощью перечисленных ниже параметров, например, UseLocalTime.

• -Cluster – имя кластера, к которому применяется команда. Этот параметр позволяет указать удаленный кластер. Если параметр опущен, то команда применяется к текущему кластеру.
• -Node – имя узла, к которому применяется команда. Эта команда используется, если файл Cluster.log генерируется только для конкретного узла.
• * -Destination – папка, в которую копируются файлы Cluster.log. При использовании этого параметра PowerShell не только создает файл Cluster.log в папке C:WindowsClusterReports для каждого узла, но и копирует все файлы журнала в заданную папку. Имя узла составляет часть имени файла, копируемого в целевую папку (например, Node1_Cluster.log, Node2_Cluster.log), что позволяет легко идентифицировать журналы.
• -TimeSpan. Этот параметр используется для создания журнала за заданный интервал времени в минутах (например, 5), что по-зволяет значительно уменьшить анализируемый файл. Этот параметр можно использовать при воспроизведении ошибки, то есть воспроизвести предполагаемую ошибку и сгенерировать журнал за последние 5 минут, чтобы проверить предположение.
• -UseLocalTime. Как уже говорилось, это новый параметр в Server 2012. Вся информация в кластере регистрируется во вре-менной зоне GMT. Например, в часовом поясе GMT-5, когда местное время составит 13:00 (1:00 p.m.), в журнале Cluster.log по умолчанию будет указано время 18:00 (6:00 p.m.). Это облегчает сопоставление времени, возвращаемого командой Get-ClusterLog, со временем в журнале Event Log.

Освоив создание журналов Cluster.log, следует научиться из-влекать из них нужную информацию.

Анализ файлов Cluster.log

Анализ файлов Cluster.log может отнимать много времени из-за большого объема информации. Ниже приведены рекомендации, которые помогут правильно приступить к делу.

Прежде всего, следует знать строение файла Cluster.log. Каждая запись имеет свою основную структуру. В частности, запись о подключении ресурса с данным IP-адресом, выглядит следующим образом:

00000bb8.000001d4::2013/05/15-01:13:24.852
INFO [RES] IP Address:
Online: Opened object handle for netinterface
353c85ee-7ea7-4b2a-927d-1538dffcdecd

Разобьем запись на отдельные фрагменты и поясним их смысл.

00000bb8 – шестнадцатеричное представление идентификатора процесса. Обычно процессом является Resource Host System (RHS). Сортируя или применяя поиск строк, включающих этот ID, можно узнать, какие ресурсы использует процесс. Это удобно в случае отладки дампа RHS при наличии нескольких файлов. Каждый дамп идентифицируется по ID, поэтому знание идентификатора гарантирует работу именно с нужным дампом процесса. Если есть полный дамп памяти, то в нем представлены несколько процессов RHS, каждый из которых идентифицируется по ID.

000001d4 – идентификатор цепочки в шестнадцатеричном пред-ставлении. Сортируя или применяя поиск строк, включающих этот ID, можно отследить действия цепочки. Используя этот ID для поиска, можно перейти прямо к нужной цепочке – например, при отладке процесса RHS, имеющего 100 цепочек.

2013/05/15-01:13:24.852 – дата и время в зоне GMT (если журнал генерируется без использования параметра UseLocalTime). В часовом поясе GMT-5 данное время соответствует местному времени 14 мая 2013 г., 8:13 p.m. Время детализируется с точностью до миллисекунд.

INFO – уровень записи: INFO (информация), WARN (предупреждение), ERR (ошибка) или DBG (отладка). Есть и другие, но в большинстве случаев используются именно эти уровни. Строка с ERR обычно означает проблему с ресурсом. Открыв файл Cluster.log, можно выполнить поиск по конкретному уровню, чтобы быстрее локализовать проблемный участок.

[RES] IP Address – тип ресурса. В журнале каждый ресурс иден-тифицируется по типу. Располагая этой информацией, можно быстро отследить проблемный подключающийся ресурс, если в одно и то же время подключаются ресурсы разных типов.

. Это – фактический ресурс, отображаемый в диспетчере кластеров.

Online: Opened object handle for netinterface 353c85ee-7ea7-4b2a-927d-1538dffcdecd – описание того, что происходит с ре-сурсом. В данном случае ресурс открывает дескриптор доступа к драйверу сетевого адаптера для привязки к нему IP-адреса. Если здесь возникает сбой, то это может указывать на проблему с драйвером сетевого адаптера, либо на неисправность самого се-тевого адаптера. Следующим шагом будет анализ записей в журнале системных событий и поиск событий, относящихся к сети (сбой сети или сетевого адаптера). Выявить причину проблемы помогают описания. Особенно полезны описания последних действий перед наступлением отказа.

Поиск в файлах Cluster.log

Анализируя файлы Cluster.log, стоит задействовать поиск по ключевым словам. В таблице приведен список ключевых слов, ко-торые я использую для поиска ресурсов.

Ключевые слова следует вводить в точности так, как они ото-бражены, то есть с двумя дефисами и знаком «больше» (—>) и без пробелов.

Ключевые слова также позволяют быстро определить, сколько времени требуется ресурсу для отключения или подключения. Предположим, например, что подключение некоторой группы занимает больше времени, чем обычно. В этом случае сначала можно применить поиск по —>OfflinePending, а затем по —>Offline для всех ресурсов группы. Другой вариант: сначала поиск по —>OnlinePending, а затем по —>Online. Для каждого ресурса суммируем значения времени, чтобы узнать, сколько времени ему требуется на подключение. Проделав это для каждого ресурса, сравним суммарные значения, чтобы узнать, какому ресурсу тре-буется наибольшее время. Затем можно проанализировать записи в журнале Cluster.log, чтобы определить причину. Например, если подключение группы занимает в целом 30 секунд на одном узле и три минуты на другом, то следует сгенерировать файлы Cluster.log для обоих узлов и сравнить их.

Для групп можно использовать те же ключевые слова, но за сим-волом «больше» должен следовать пробел. Например, при анализе отключения сначала используется —> OfflinePending, а затем —> Offline. Различается еще лишь запись при анализе отказа: для группы используется —> Failed, а для отказа —>ProcessingFailure.

Сведение информации воедино

Сведение представленной информации воедино мы рассмотрим на примере кластера, состоящего из двух узлов, обслуживаемых не-сколькими файловыми серверами, использующих разные сети и сеть хранения данных SAN с подключением по Fibre Channel. Для сетей используются следующие установки:

• Cluster Network 1 = IP scheme 192.168.0.0/24
• Cluster Network 2 = IP scheme 1.0.0.0/8
• Cluster Network 3 = IP scheme 172.168.0.0/16

В сетевых подключениях узлов сетевые адаптеры идентифицируются следующим образом:

• CORPNET = IP scheme 192.168.0.0/24
• MGMT = IP scheme 1.0.0.0/8
• BACKUP = IP scheme 172.168.0.0/16

Сервер FILESERVER1 использует сеть Cluster Network 1, функ-ционирующую на узле NODE1, а сервер FILESERVER2 – сеть Cluster Network 2 на узле NODE2.

Предположим, ночью произошел сбой, и группа файлового сервера FILESERVER2 переместилась с узла NODE2 на узел NODE1. Требуется выяснить причину отказа.

В диспетчере кластеров щелкаем правой кнопкой на группе FI-LESERVER2 и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:

Event ID: 1069

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

type ‘IP Address’ in Clustered Role ‘FILESERVER’ failed.

Event ID: 1205

Description: The Cluster service failed to bring clustered

service or application ‘FILESERVER2’ completely online or

offline. One or more resources may be in a failed state.

Первое событие указывает на сбой ресурса с IP-адресом 1.1.1.1. Щелкаем правой кнопкой на этом ресурсе в диспетчере кластеров и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:

Event ID: 1077

Description: Health check for IP Interface

‘IP Address 1.1.1.1’ (address 1.1.1.1) failed (status is

1168). Run the Validate a Configuration wizard to ensure

that the network adapter is functioning properly.

Event ID: 1069

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

type ‘IP Address’ in Clustered Role ‘FILESERVER’ failed.

На основании описания первого события (1077) воспользуемся мастером проверки настроек Validate a Configuration Wizard. Запускаем только тест Network/Validate Network Communication для проверки всех адаптеров и сетевых путей между узлами.

После выполнения теста Network/Validate Network Communication анализируем отчет. В отчете нет ни ошибок, ни предупреждений, поэтому откладываем его в сторону.

Есть каналы событий, которые можно проанализировать, поэтому обращаемся к каналу FailoverClustering/Operational, где имеется следующее событие:

Event ID: 1153

Description: The Cluster service is attempting to failover

the clustered service or application ‘FILESERVER2’ from

node ‘NODE2’ to node ‘NODE1’

На основании этого описания переходим к каналу FailoverClus-tering/Diagnostics, где имеются следующие события:

Event ID: 2051

Description: [RCM] rcm::RcmResource::HandleFailure:

(IP Address 1.1.1.1)

Event ID: 2051

Description: [RES] IP Address:

Failed to query properties of adapter id

F3EDD1C8-6984-82BC-498806B841CA, status 87.

Генерируем файл Cluster.log для этого узла, в журнале выполняем поиск >ProcessingFailure и находим следующие записи:

[RES] IP Address: IP Interface

3600A8C0 failed LooksAlive check, status 1168.

[RES] IP Address: IP Interface

3600A8C0 failed IsAlive check, status 1168.

[RHS] Resource IP Address 1.1.1.1 has indicated failure.

[RCM] Res IP Address 1.1.1.1: Online -> ProcessingFailure

( State Unknown )

[RCM] TransitionToState( IP Address 1.1.1.1)

Online—>ProcessingFailure.

Далее в Cluster.log находим записи, в которых говорится о том, что группа была перемещена. Это указывает на то, что записи, найденные в результате поиска —>ProcessingFailure, имеют отношение к проблеме, обусловившей перемещение группы. По ошибкам, обозначенным в этих записях, мы точно знаем, что произошел сбой ресурса с данным IP-адресом. Чтобы выяснить значение кода статуса ошибки, воспользуемся командой Net.exe:

NET HELPMSG 1168

Команда возвращает сообщение Element not found («Элемент не найден»). После более тщательного изучения записей видим, что проблема может быть связана с сетевым адаптером. Несколько аппаратных тестов применительно к адаптерам выявляют неисправный адаптер, который даже не виден в Windows. Проблему решает замена неисправного адаптера.

Однако остается вопрос, почему в результатах теста Net-work/Validate Network Communication отсутствуют ошибки. Этот тест предусматривает проверку всех сетевых адаптеров, от одного узла к другому, независимо от их местонахождения (в одной или в разных сетях). Переходы между узлами осуществляются по всевозможным известным маршрутам. Поэтому существуют ожидаемые отказы, обусловленные особенностями организации кабельных соединений в сетях между узлами или разбиения сетей на сегменты.

При более тщательном изучении результатов теста обращаем вни-мание на информацию, представленную на экране 2.

Экран 2. Результаты теста Network/Validate Network Communication

Мы видим, что узел NODE1 не имеет сетевого адаптера, опреде-ляемого как MGMT. По сути, это означает то же, что и события, то есть что у NODE1 – две сети, а у NODE2 – три. Следовательно, недостаточно просто просматривать ошибки и предупреждения в верхней части отчета. Необходимо также изучать результаты теста.

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

Таблица. Ключевые слова, используемые для поиска ресурсов

Ключевое слово Описание

—>OnlinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание подключения» (Online Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить подключение ресурса

—>OfflinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание отключения» (Offline Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить отключение ресурса

—>Offline Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Автономная работа» (Offline) для ресурса. Если отслеживается ресурс, то смотреть дальше необходимости нет. Если этот ресурс зависит от другого ресурса, то тот другой ресурс мог начать процесс отключения первым

—>Online Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «В сети» (Online) для ресурса. Если отслеживается ресурс, то смотреть дальше нет необходимости. Если от этого ресурса зависит другой ресурс, то тот другой ресурс не начнет свой процесс подключения к сети, пока не завершен этот процесс

—>ProcessingFailure Это ключевое слово появляется в журнале при отказе ресурса. При наличии такой строки необходимо про-смотреть предыдущие записи, чтобы узнать, что инициировало отказ. В просмотре записей после этого события необходимости нет. При отказе ресурса всегда следует попытаться пройти через нормальный процесс отключения, даже если, скорее всего, будет выдана ошибка, поскольку ресурс недоступен.

Для проверки целостности системных файлов и восстановления поврежденных файлов (библиотек) компонентов в Windows (Windows Server) можно использовать команды SFC и DISM. Эти две утилиты могут быть крайне полезными, если операционная система Windows работает нестабильно, появляются ошибки при запуске стандартных приложений или служб, после вирусного заражения и т.д.

В этой статье мы рассмотрим, как использовать команды
sfc /scannow
,
DISM /Online /Cleanup-Image /RestoreHealth
или
Repair-WindowsImage -Online -RestoreHealth
для восстановления образа и системных фалов в Windows 10/11 и Windows Server 2022/2019/2016.

SFC /scannow: восстановление системных файлов Windows

Перед тем, как восстанавливать образ Windows с помощью DISM, рекомендуется сначала попробовать проверить целостность системных файлов с помощью утилиты SFC (System File Checker). Команда
sfc /scannow
позволяет проверить целостность системных файлов Windows. Если какие-то системные файлы отсутствуют или повреждены, утилита SFC попробует восстановить их оригинальные копии из хранилища системных компонентов Windows (каталог C:WindowsWinSxS).

Если команда sfc /scannow возвращает ошибку “
Программа защиты ресурсов Windows обнаружила повреждённые файлы, но не может восстановить некоторые из них / Windows Resource Protection found corrupt files but was unable to fix some of them
”, скорее всего утилита не смогла получить необходимые файла из хранилища компонентов (образа) Windows.

В этом случае вам нужно попробовать восстановить хранилище компонентов вашего образа Windows с помощью DISM.

После восстановления образа вы можете повторно использовать утилиту SFC для восстановления системных файлов.

Проверка целостности хранилища компонентов Windows с помощью DISM

Утилита DISM (Deployment Image Servicing and Management) доступна во всех версиях Windows, начиная с Vista.

Для сканирования образа Windows на наличие ошибок и их исправления используется параметр DISM /Cleanup-image. Команды DISM нужно запускать из командной строки, с правами администратора.

Чтобы проверить наличие признака повреждения хранилища компонентов в образе Windows (флаг CBS), выполните команду (не применимо к Windows 7/Server 2008R2):

DISM /Online /Cleanup-Image /CheckHealth

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

В этом примере команда вернула, что с образом все хорошо:

No component store corruption detected.
The operation completed successfully.

Чтобы выполнить полное сканирование хранилища компонентов на наличие повреждений в хранилище компонентов Windows, запустите команду:

DISM /Online /Cleanup-Image /ScanHealth

Команда проверки образа Windows может выполняться довольно долго (от 10 до 30 минут). И вернет один из трех результатов:

• No component store corruption detected – DISM не обнаружил повреждения в хранилище компонентов;
• The component store is repairable – DISM обнаружил ошибки в хранилище компонентов и может исправить их;
• The component store is not repairable – DISM не может исправить хранилище компонентов Windows (попробуйте использовать более новую версию DISM или вам придется восстанавливать образ Windows из резервной копии, сбрасывать или полностью переустанавливать вашу копию Windows.

В Windows 7 и Windows Server 2008 R2 для использования параметра DISM /ScanHealth нужно установить отдельное обновление KB2966583. Иначе при запуске DISM будет появляться “
Ошибка 87. Параметр ScanHealth не распознан в этом контексте
”.

Команда DISM /ScanHealth может вернуть ошибки:

• Ошибка: 1726. Сбой при удалённом вызове процедуры;
• Ошибка: 1910. Не найден указанный источник экспорта объекта.

Это однозначно говорит о том, что ваш образ Windows поврежден и его нужно восстановить.

Восстановление образа Windows с помощью DISM /RestoreHealth

Чтобы исправить повреждения в хранилище компонентов образа Windows нужно использовать опцию RestoreHealth команды DISM. Эта опция позволит исправить найденные в образе ошибки, автоматически скачать и заменить файлы повреждённых или отсутствующих компонентов эталонными версиями файлов из центра обновлений Windows (на компьютере должен быть доступ в Интернет). Выполните команду:

DISM /Online /Cleanup-Image /RestoreHealth

В Windows 7/2008 R2 эта команда выглядит по другому:
DISM.exe /Online /Cleanup-Image /ScanHealth

Процесс сканирования и восстановления компонентов может быть довольно длительным (30 минут или более). DISM автоматически загрузит недостающие или поврежденные файлы образа с серверов Windows Update.

Восстановление выполнено успешно. Операция успешно завершена.

The restore operation completed successfully.

DISM /Source: восстановление образа Windows с установочного диска

Если на компьютере (сервере) отсутствует доступ в Интернет или отключена/повреждена служба Windows Update (как восстановить клиент Windows Update), то при восстановлении хранилища компонентов появятся ошибки:

• 0x800f0906 — Не удалось скачать исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник (0x800f0906 — The source files could not be downloaded. Use the source option to specify the location of the files that are required to restore the feature);
• Ошибка: 0x800f0950 — Сбой DISM. Операция не выполнена (0x800f0950 — DISM failed. No operation was performed);
• Ошибка:0x800F081F. Не удалось найти исходные файлы. Укажите расположение файлов, необходимых для восстановления компонента, с помощью параметра Источник (Error 0x800f081f, The source files could not be found. Use the «Source» option to specify the location of the files that are required to restore the feature).

<

Во всех этих случаях вы можете использовать альтернативные средства получения оригинальных файлов хранилища компонентов. Это может быть:

• Установочный диск/флешка/iso образ Windows
• Смонтированный файл wim
• Папка sourcesSxS с установочного диска
• Файл install.wim с установочным образом Windows

Вы можете указать WIM или ESD файл с оригинальным установочным образом Windows, который нужно использовать в качестве источника для восстановления файлов системы. Предположим, вы смонтировали установочный ISO образ Windows 11 в виртуальный привод D:.

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

С помощью следующей PowerShell команды проверьте, какая версия Windows установлена на вашем компьютере:

Get-ComputerInfo |select WindowsProductName,WindowsEditionId,WindowsVersion, OSDisplayVersion

Выведите список доступных версий Windows в установочном образе:

Get-WindowsImage -ImagePath "D:sourcesinstall.wim"

В нашем случае образ Windows 11 Pro в образе install.wim имеет
ImageIndex = 6
.

Для восстановления хранилища компонентов из локального WIM/ESD файла с блокированием доступа в интернет, выполните следующую команду (не забудьте указать ваш индекс версии Windows в файле):

DISM /online /cleanup-image /restorehealth /source:WIM:D:sourcesinstall.wim:6  /limitaccess

Или:
DISM /online /cleanup-image /restorehealth /source:ESD:D:sourcesinstall.esd:6  /limitaccess

Утилита DISM пишет подробный журнал сканирования и восстановления системных файлов в файл
C:WindowsLogsDISMdism.log
.

После восстановления хранилища компонентов вы можете запустить утилиту проверки системных файлов
sfc /scannow
. Скорее всего она успешно восстановит поврежденные файлы:

Программа защиты ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. 

Windows Resource Protection found corrupt files and successfully repaired them.

Если все системные файлы целы, появится сообщение:

Windows Resource Protection did not find any integrity violations

Восстановление образа Windows с помощью PowerShell

В версии PowerShell в Windows 10/11 и Windows Server 2022/2019 есть аналоги рассмотренных выше команд DISM. Для сканирования хранилища компонентов и поиска повреждений в образе выполните:

Repair-WindowsImage -Online –ScanHealth

Если ошибок в хранилище компонентов не обнаружено, появится сообщение:

ImageHealth State: Healthy

Для запуска восстановления системных компонентов и файлов наберите:


Repair-WindowsImage -Online -RestoreHealth


При отсутствии доступа к интернету эта команда может зависнуть в процессе восстановления образа. Вы можете восстановить системные компоненты из локальной копии образа Windows в виде WIM/ESD файла, скопированного с установочного ISO образа Windows 10 (здесь также нужно указать индекс версии Windows в wim файле в качестве источника восстановления):

Repair-WindowsImage -Online -RestoreHealth -Source D:sourcesinstall.wim:5 –LimitAccess

DISM: восстановление поврежденного хранилища компонентов, если Windows не загружается

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

1. Для этого загрузите компьютер с установочного образа Windows (проще всего создать загрузочную USB флешку с Windows 10/11 с помощью Media Creation Tool) и на экране начала установки нажмите
   Shift + F10
2. Чтобы разобраться с буквами дисков, назначенных в среде WinPE, выполните команду
   diskpart
   ->
   list vol
   (в моем примере диску, на котором установлена Windows присвоена буква C:, эту букву я буду использовать в следующих командах);
3. Проверим системные файлы и исправим поврежденные файлы командой:
   sfc /scannow /offbootdir=C: /offwindir=C:Windows
   
   
4. Для исправления хранилища компонентов используйте следующую команду (в качестве источника для восстановления компонентов мы используем WIM файл с установочным образом Windows 10, с которого мы загрузили компьютер):
   Dism /image:C: /Cleanup-Image /RestoreHealth /Source:WIM:D:sourcesinstall.wim:6
   
5. Если на целевом диске недостаточно места, то для извлечения временных файлов нам понадобится отдельный диск достаточного размера, например F:, на котором нужно создать пустой каталог:
   mkdir f:scratch
   и запустить восстановление хранилища компонентов командой:
   Dism /image:C: /Cleanup-Image /RestoreHealth /Source:D:sourcesinstall.wim /ScratchDir:F:scratch

Апр 28, 2017 14:37

Использование средства проверки системных файлов для восстановления отсутствующих или поврежденных системных файлов

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

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

Запуск средства проверки системных файлов (SFC.exe)

выполнив указанные ниже действия.

Откройте командную строку с повышенными привилегиями. Для этого выполните указанные ниже действия, в зависимости от версии операционной системы:

Пользователям Windows 10, Windows 8.1 или Windows 8 перед запуском средства проверки системных файлов нужно запустить систему обслуживания образов развертывания и управления ими (DISM). (Если на вашем компьютере установлена система Windows 7 или Windows Vista, перейдите сразу к шагу 3.)

Введите следующую команду и нажмите клавишу ВВОД. Выполнение команды может занять несколько минут.

DISM.exe /Online /Cleanup-image /Restorehealth

Важно! При запуске этой команды DISM обращается к Центру обновления Windows, чтобы получить файлы для устранения повреждений. Но если поврежден клиент Центра обновления Windows, используйте работающий экземпляр Windows в качестве источника восстановления либо параллельную папку Windows из сетевого расположения или со съемного носителя, например DVD-диска Windows, в качестве источника файлов. Для этого введите в командной строке такую команду:

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source: C:RepairSourceWindows /LimitAccess

Примечание. Вместо заполнителя C:RepairSourceWindows укажите расположение вашего источника восстановления. Дополнительные сведения об использовании средства DISM для восстановления Windows см. в статье Восстановление образа Windows.

Введите в командной строке приведенную ниже команду и нажмите клавишу ВВОД:

Команда sfc /scannow проверит все защищенные системные файлы и заменит поврежденные файлы их кэшированной копией, расположенной в сжатой папке по адресу %WinDir%System32dllcache.
Заполнитель %WinDir% представляет собой папку операционной системы Windows. Например, C:Windows.

Примечание. Не закрывайте это окно командной строки, пока проверка не завершится на 100 %. Результаты проверки будут показаны после завершения данного процесса.

После завершения процесса проверки на экране может появиться одно из приведенных ниже сообщений:

Защита ресурсов Windows не обнаружила нарушений целостности.

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

Защита ресурсов Windows не может выполнить запрошенную операцию.

Для устранения этой проблемы выполните сканирование с помощью средства проверки системных файлов в безопасном режиме, убедитесь, что папки PendingDeletes и PendingRenames находятся в папке %WinDir%WinSxSTemp.

Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. Сведения см. в журнале CBS.Log %WinDir%LogsCBSCBS.log.

Для просмотра подробных сведений о сканировании и восстановлении системных файлов перейдите к разделу Как просмотреть подробные сведения процесса работы средства проверки системных файлов.

Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. Сведения см. в журнале CBS.Log %WinDir%LogsCBSCBS.log.

Проведите пальцем от правого края экрана к центру и коснитесь кнопки Поиск. Либо, если вы используете мышь, переместите указатель в правый нижний угол экрана и щелкните кнопку Поиск. Введите запрос Командная строка в поле Поиск, щелкните правой кнопкой мыши элемент Командная строка, затем выберите команду Запуск от имени администратора. Если система запросит пароль администратора или подтверждение, введите пароль или нажмите кнопку Разрешить.

Для этого нажмите кнопку Пуск, введите запрос Командная строка или cmd в поле Поиск, щелкните правой кнопкой мыши элемент Командная строка, а затем выберите команду Запуск от имени администратора. При получении запроса на ввод пароля администратора или подтверждения введите пароль или нажмите кнопку Разрешить.

Дополнительная информация

Чтобы ознакомиться с подробными сведениями, включенными в файл CBS.Log, вы можете скопировать сведения в файл Sfcdetails.txt с помощью команды Findstr, а затем просмотреть их в этом файле. Для этого выполните указанные ниже действия.

Откройте командную строку с повышенными привилегиями, как это описано на шаге 1.

Введите в командной строке приведенную ниже команду и нажмите клавишу ВВОД:

Примечание. В файле Sfcdetails.txt содержатся сведения о каждом запуске средства проверки системных файлов на компьютере. Он также содержит информацию о файлах, которые не были исправлены средством проверки системных файлов. Проверьте дату и время записей, чтобы определить проблемные файлы, обнаруженные при последнем запуске средства проверки системных файлов.

Откройте файл Sfcdetails.txt на рабочем столе.

В файле Sfcdetails.txt используется следующий формат:

Сведения о дате и времени SFC В следующем примере файла журнала содержится запись для одного файла, который не удалось исправить: 2007-01-12 12:10:42, Info CSI 00000008 [SR] Cannot repair member file [l:34<17>]»Accessibility.dll» of Accessibility, Version = 6.0.6000.16386, pA = PROCESSOR_ARCHITECTURE_MSIL (8), Culture neutral, VersionScope neutral, PublicKeyToken = , Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing

Как вручную заменить поврежденный системный файл гарантированно работоспособной копией файла.

После определения, какой системный файл поврежден и не может быть восстановлен, с помощью подробных сведений в файле Sfcdetails.txt, выясните расположение поврежденного файла, затем вручную замените поврежденный файл его гарантировано работоспособной копией. Для этого выполните указанные ниже действия.

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

Распространите на поврежденный системный файл права собственности администратора. Для этого скопируйте, а затем вставьте (или введите) в командную строку с повышенными привилегиями приведенную ниже команду, затем нажмите клавишу ВВОД:

takeown /f Путь_и_имя_файла Примечание. Заполнитель Путь_и_имя_файла представляет собой путь и имя файла для поврежденного файла. Например, введите takeown /f C:windowssystem32jscript.dll.

Предоставьте администраторам полный доступ к поврежденному системному файлу. Для этого скопируйте и вставьте (или введите) приведенную ниже команду и нажмите клавишу ВВОД:

icacls Путь_и_имя_файла /GRANT ADMINISTRATORS:F Примечание. Заполнитель Путь_и_имя_файла представляет собой путь и имя файла для поврежденного файла. Например, введите icacls C:windowssystem32jscript.dll /grant administrators:F.

Замените поврежденный системный файл гарантировано работоспособной копией файла. Для этого скопируйте и вставьте (или введите) приведенную ниже команду и нажмите клавишу ВВОД:

Copy Исходный_файл Расположение Примечание. Заполнитель Исходный_файл представляет собой путь и имя гарантировано работоспособной копии файла на вашем компьютере, а заполнитель Расположение представляет собой путь и имя поврежденного файла. Например, введите copy E:tempjscript.dll C:windowssystem32jscript.dll.

Если описанные выше действия не помогли, возможно, потребуется переустановить Windows. Дополнительные сведения см . в разделе Варианты восстановления Windows10.

Проверка согласованности кустов реестра счетчиков производительности при установке SQL Server в Windows

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

Проверка согласованности кустов реестра счетчиков производительности не удалась

По сути, когда мы пытаемся установить SQL, он запускает некоторые правила, чтобы проверить, отвечает ли ваша система всем требованиям для успешного запуска SQL Server 2008. Во время этого процесса, как вы можете видеть на скриншоте, установка завершится неудачей. Вы не можете продолжать дальше.

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

Согласно TechNet, лучшим примером является « Буферные буферы ». Этот счетчик определяет, будут ли буферы данных временно записываться на диск во время работы пакета. Но, как я уже сказал, некоторые приложения, работающие с SQL, в действительности не нуждаются в них. Он в основном используется для автономного SQL на сервере данных, который требует большого контроля. Поэтому, если вы хотите просто пропустить проверку согласованности счетчика производительности, вы можете начать установку SQL Server со следующего значения переключателя.

C: Downloads setup.exe/ACTION = install/SKIPRULES = PerfMonCounterNotCorruptedCheck

Замените место, где у вас есть установочные файлы.

Восстановить счетчик производительности

После запуска установки с этим значением переключателя следует пропустить этот шаг и продолжить установку. Так что это один из способов обойти это сообщение об ошибке. Другой способ, который также упоминается в Microsoft KB, это перестроить счетчик производительности.

• Нажмите на Пуск и введите CMD
• Щелкните правой кнопкой мыши и выберите «Запуск от имени администратора».
• Затем введите lodctr /R:PerfStringBackup.INI и нажмите Enter
• Теперь перезагрузите систему и попробуйте снова установить SQL Server.

Я видел эту работающую onolder версию Windows, такую ​​как XP и Server 2003, но я почти не видел, чтобы она работала в операционной системе нового поколения. Все же стоит попробовать. Есть способ Microsoft вручную перестроить Счетчик производительности, пожалуйста, обратитесь к KB300956.

Тогда возникают ситуации, когда сам нужный ключ реестра отсутствует. В таких случаях мы должны найти, какой ключ отсутствует, а затем вручную создать его. Лучший и самый простой способ. Есть небольшое приложение, которое я нашел, кто-то опубликовал на форумах MSDN, которое скажет вам, какой ключ нам нужно создать. Вы можете скачать его отсюда – это консольное приложение разработано Rafael Candido. Я так думаю. Теперь, прежде чем мы продолжим, нам нужно создать резервную копию вашего реестра.

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

• Нажмите на Пуск и введите Regedit
• Щелкните правой кнопкой мыши и выберите «Запуск от имени администратора».
• Перейдите в HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows NT CurrentVersion Perflib
• Затем щелкните правой кнопкой мыши на Perflib и нажмите на новый ключ
• Затем введите значение, которое вы получили при запуске консольного приложения.

• Тогда у вас могут быть другие ключи под Perflib, такие как 009 и т. Д.
• Вам нужно скопировать эту информацию и поместить ее под вновь созданный ключ

Лучший способ сделать это – просто экспортировать один ключ (в моем случае 009), а затем сохранить его на рабочем столе как PCFix.reg. Щелкните правой кнопкой мыши на PCFix.reg и выберите «Изменить». Затем измените 009 на значение, которое вы получили на консоли. Затем сохраните его и закройте. Просто дважды нажмите на ключ, чтобы вступить в силу. После этого просто перезагрузите компьютер, чтобы изменения вступили в силу.

Чтобы завершить один из этих шагов, необходимо решить проблему, с которой вы сталкиваетесь при проверке согласованности кустов реестра счетчиков производительности при установке SQL Server.

Надеюсь, вы найдете эту статью полезной.

Проверка реестра Windows 10 на ошибки

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

Как проверить систему на целостность и ошибки

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

Проверка с помощью System File Checker

System File Checker – это встроенный в Windows инструмент для проверки и восстановлении целостности файлов и файловой системы. Он может помочь диагностировать и исправить ошибки.

Запуск программы осуществляется через системный терминал. Для этого нажмите правой кнопкой на меню «Пуск» и выбираем пункт «Windows PowerShell (администратор).

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

Программа также сообщит вам, если были обнаружены какие-либо неисправности. Исправление проводится в автоматическом режиме.

Проверка с помощью Deployment Imaging and Servicing Management (DISM)

Если утилита SFC сообщила об обнаружении ошибки или поврежденного файла, но не смогла их исправить или восстановить, то поможет встроенный инструмент DISM.

Также в командной строке вводим следующую команду (можно скопировать или перепечатать):

“Dism /Online /Cleanup-Image /RestoreHealth”

После завершения снова воспользуйтесь SFC. Теперь он должен диагностировать и исправить файлы без каких-либо проблем.

Как проверить жесткий диск

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

Проверка с помощью Windows CHKDSK

Windows CHKDSK Tool — это встроенный инструмент Windows, который сканирует ваш диск, чтобы найти системные ошибки и плохие сектора на HDD. Он также показывает другие проблемы с накопителем. Программа проводит автоматическое исправление найденных проблем, если это возможно.

Для запуска утилиты нажмите правой кнопкой на необходимый жесткий диск и выберете пункт «Свойства». В открывшемся окне выбираем вкладку «Сервис» и нажимаем на кнопку «Проверить».

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

Использование WMIC

Windows Management Instrumentation (WMI) – это инструмент, который позволяет выполнять множество административных задач, включая проверку работоспособности жесткого диска. Он использует S.M.A.R.T функцию жестких дисков. Программа выводит только два ответа: «ОК» и «Pred Fail».

Для запуска приложения нажмите на сочетание клавиш Win+R и в строке напишите “cmd”. После этого откроется командная строка. В ней необходимо ввести две строчки:

Проверка оперативной памяти

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

Проверка с помощью Windows Memory Diagnostic

Для запуска штатной проверки памяти Windows Memory Diagnostic достаточно нажать на Win+R и ввести “mdsched.exe”. Появится диалоговое окно, предлагающее перезагрузить ПК и начать сканирование сейчас или провести проверку при следующей перезагрузке.

Ваш компьютер будет перезапущен и появится экран инструмента диагностики памяти Windows. Просто оставьте его и пусть он выполняет тест. Это может занять несколько минут. Во время этого процесса вы увидите панель прогресса, а сообщение “Статус” сообщит вам, если в ходе процесса были обнаружены какие-либо проблемы.

Для просмотра результатов диагностирования необходимо:

• Перезагрузиться в Windows;
• Нажать Win+R;
• Ввести “eventvwr.msc”;
• В открывшемся журнале событий в левой части выбрать «Журнал Windows» -> «Система»;
• В правой части нажать на кнопку «Найти».
• В открывшемся диалоговом окне ввести «MemoryDiagnostic».

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

Проверка с помощью MemTest86

Если вы ищете более мощный инструмент тестирования, вы можете скачать и использовать MemTest86. MemTest86 сертифицирован Microsoft, так что он будет работать даже на системах с поддержкой Secure Boot.

Программа запускается при помощи загрузочного диска или USB-флэшки. Создание очень простое. Достаточно запустить .exe файл, находящийся в архиве с программой, и указать вашу флэшку.

Внимание! Процедура создания загрузочного USB удалит всю информацию с накопителя.

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

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

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

Распространенные причины ошибок реестра в Windows 10

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

Наиболее частой причиной ошибок и проблем в реестре становятся вредоносные программы:

Также файл реестра может быть поврежден. Из-за этого компьютер не сможет загрузиться.

Как исправить ошибки реестра в Windows 10

Чтобы избавиться от проблем навсегда необходимо проводить периодическое резервное копирование реестра Виндовс. Это легко сделать с помощью штатной программы regedit. Для ее запуска нажмите Win+R и введите regedit.exe. В открывшемся окне нажмите правой кнопкой на пункте «Компьютер» и выберете «Экспорт». Компьютер сохранит полную копию реестра в выбранном месте.

1. Создайте точку восстановления системы.

Еще один простой способ сохранить свой компьютер в рабочем состоянии – создание точек восстановления. Можно настроить регулярное создание с определенной периодичностью.

Для запуска программы достаточно открыть панель управления и в поиске ввести «восстановления». В выпадающем списке выберете «создать точку восстановления». Из открывшегося меню можно исправить систему, или создать новую точку.

1. Восстановите реестр из резервной точки или восстановления.

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

1. Сканирование можно провести с помощью штатной системы проверки.

С проблемами реестра в Windows 10 также может справиться System File Checker (SFC). Как начать исправление ошибок написано в начале статьи.

Использование утилит для проверки реестра Windows 10 на ошибки

Несмотря на то, что ошибки в реестре редко можно исправить автоматизированными сторонними средствами, некоторые программы показывают хорошие результаты. При помощи очистки и сканирования скорость работы компьютера может увеличиться. Наиболее популярные: CCleaner Registry Cleaner, Auslogics Registry Cleaner и RegSofts Free Window Registry Repair. Все эти программы способны проводить очистку реестра, резервное копирование и восстановление, а также исправление самых частых ошибок в реестре.