Возникла ошибка код события eventid 0x00002720

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

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

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

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

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

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

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

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

— 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), ус-тановленного на всех узлах кластера. Данные журнала позволяют диагностировать проблемы прямых операций ввода/вывода.

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

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

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

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

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

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

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

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

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

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

На этот раз команда возвращает сообщение 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;

—List Fibre Channel Host Bus Adapters

—List iSCSI Host Bus Adapters

—List SAS Host Bus Adapters

—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

— List Network Binding Order;

— Validate Cluster Network Configuration;

— Validate IP Configuration;

— Validate Network Communications;

— Validate Windows Firewall Configuration.

— 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

— 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. log, следует научиться из-влекать из них нужную информацию.

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

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

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

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

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, стоит задействовать поиск по ключевым словам. В таблице приведен список ключевых слов, ко-торые я использую для поиска ресурсов.

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

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

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

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

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

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

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

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

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

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 («Показать критические события»). На экран выдаются следующие события:

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.

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, где имеется следующее событие:

Description: The Cluster service is attempting to failover

The clustered service or application ‘FILESERVER2’ from

Node ‘NODE2’ to node ‘NODE1’

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

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

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] TransitionToState( IP Address 1.1.1.1)

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

В ходе расследования выясняется, что при попытке запустить сервер DCOM с помощью приложения у вас нет никаких прав на это, и вы получите приведенную ниже ошибку в средстве просмотра событий: «Параметры разрешений для конкретного приложения не дают разрешения Локальной Активации для приложения COM-сервера«. Чтобы иметь четкую концепцию и избежать ошибок, мы разделим всю процедуру на четыре последовательных раздела. Давайте перейдем к ним сразу. Мы сосредоточимся на решении этой досадной ошибки в журнале событий «Код события 10016 DistributedCOM Windows 10«, следуя приведенным ниже инструкциям.

Перед тем, как приступить к исправлению Создайте точку восстановления системы.

Исправление кода события 10016 Ошибки DistributedCOM

Проверка процесса

Шаг 2. Отроем теперь редактор реестра. Нажмите сочетание кнопок Win+R и введите Regedit.

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

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

Исправление разрешений

Наконец, когда вы удостоверились, что это именно тот файл выдает ошибку, то проделайте следующие шаги:

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

Чтобы обойти эту ошибку, вам нужно отредактировать некоторые разрешения в разделе «Служба компонентов» ключа RuntimeBroker. Прежде чем перейти к модификации, вам нужно запустить скрипт, который поможет вам изменить разрешения. Дальше поймете зачем мы это делали.

Шаг 1. Нажмите сочетание кнопок Win+X и выберите Windows PowerShell (администратор).

Шаг 2. Загрузите файл с кодом ниже. Разархивируйте скаченный архив, в нем содержится текстовый файл с кодом.

Шаг 3. Вставьте скаченный скрипт с файла в командную строку PowerShell.

Добавим группы Система и Local service.

Перезагрузите компьютер, ноутбук и код события 10016 Ошибка DistributedCOM должен пропасть.

ИСПРАВЛЕНИЕ: Предупреждение о событии диска 51 Обнаружена ошибка на устройстве во время операции подкачки.

Предупреждение Disk Event 51 «Обнаружена ошибка на устройстве Device Harddisk … во время операции подкачки», обычно указывает на проблему, связанную с оборудованием или драйвером устройства. Сообщение о событии с кодом события 51 регистрируется, если возникает ошибка, когда ваш компьютер перенаправляет информацию на диск или с него.

Код события 51 не обязательно означает, что ваш жесткий диск неисправен. Ошибка может возникать, когда на диске заканчивается свободное место, из-за проблемного контроллера жесткого диска, из-за поврежденного кабеля данных жесткого диска или из-за неправильного извлечения диска (например, если это внешний USB-диск или большой палец USB) диск).

В этом руководстве вы найдете подробные инструкции по устранению предупреждающего сообщения «Предупреждение о событии диска 51. Ошибка устройства на устройстве во время операции подкачки», в Windows 10, 8, 7 или Vista.

Как исправить: Событие диска 51. На жестком диске устройства обнаружена ошибка во время операции подкачки.

ВАЖНЫЙ: Перед устранением неполадок в Event ID 51 на диске, используя шаги, упомянутые ниже, Убедитесь, что диск не заполнен а также РЕЗЕРВНЫЙ ваши данные. Если вы не можете прочитать содержимое диска, то:

1. Подключите жесткий диск к другому компьютеру (если есть).
2. Если у вас есть настольный компьютер, подключите жесткий диск к другому порту (например, порту SATA) на материнской плате или замените кабель жесткого диска.
3. Если у вас есть портативный компьютер, отсоедините жесткий диск от его кабеля и подключите его снова или замените его.
4. Если вы получили сообщение об ошибке Event ID 51 на внешнем USB-диске, то, вероятно, ошибка вызвана тем, что диск был удален из системы без использования опции «Безопасное удаление USB». В этом случае проверьте диск на наличие ошибок с помощью команды «CHKDSK» (см. Инструкции в шаге 3 ниже). Если после запуска CHKDSK ошибка не устранена, подключите диск к другому USB-порту или, если можете, извлеките диск из его корпуса и подключите его непосредственно к вашей системе.

Шаг 1. Найдите, на каком диске отображается ошибка «Event ID 51».

Продолжите и выясните, на каком физическом диске ссылается ошибка 51, используя Управление дисками. *

* Заметка: Если в вашей системе установлен только один жесткий диск, пропустите этот шаг и перейдите к шагу 2.

1. Одновременно нажмите Ключ Windows + Р открыть окно запуска команды.
2. Внутри окна поиска (запуска) введите: Diskmgmt. msc и нажмите Войти.

3. В Управление диском Окно идентифицирует, какой диск, по номеру «жесткого диска», указанному в событии с идентификатором 51.

А. Как видно на приведенном ниже снимке экрана, предупреждающее сообщение о событии 51 относится к устройству «Жесткий диск».0Msgstr «В этом случае Событие 51 указывает на Диск 0.

«Событие 51, диск — Обнаружена ошибка на устройстве Устройство Жесткий диск0 DR0, во время пейджинговой операции «

Б. Таким образом, в данном случае Событие 51 указывает на Диск 0.

4. Затем щелкните правой кнопкой мыши на проблемном диске и выберите Свойства.

5. В Генеральный На вкладке вы увидите модель диска.

6. Используя эту информацию, продолжайте и найдите, на каком физическом диске возникла проблема.

Шаг 2. Обновите драйверы устройств контроллера жесткого диска.

Следующим шагом для устранения ошибки 51 является обновление драйверов для контроллера жесткого диска. Для этого:

2. В диспетчере устройств Двойной щелчок расширять ‘Контроллеры IDE ATA / ATAPI». *
3. Щелкните правой кнопкой мыши на контроллерах хранилища (по одному) и выберите Обновить драйвер.

* Заметки:
1. Если Windows не может найти обновленный драйвер, перейдите на сайт поддержки производителя, найдите обновленный драйвер набора микросхем и установите все другие рекомендуемые драйверы для контроллеров хранилища.
2. Если проблемным диском является USB-диск, разверните и обновите драйверы универсальных контроллеров последовательной шины.
3. Если проблемный диск — SCSI или IEEE 1394 (Firewire), установите обновленный драйвер для контроллера SCSI или IEEE 1394.

Шаг 3. Проверьте и исправьте ошибки файловой системы с помощью CHKDSK.

Следующим шагом является проверка жесткого диска на наличие проблем с помощью команды CHKDSK. Для этого:

1. Открыть Командная строка от имени администратора.
2. В окне командной строки введите следующую команду * и нажмите Войти:

* Замените букву «X» в приведенной выше команде в соответствии с буквой диска проблемного диска.

3. После завершения операции команды CHKDSK перезагрузите систему и проверьте, сохраняется ли предупреждающее сообщение Event ID 51 в средстве просмотра системных событий.

Другие способы разрешения диска с предупреждением ID 51:

1. Удалите Intel Storage Manager (если установлен).
2. Измените режим SATA с AHCI на IDE в настройках BIOS. *

* Примечание. В некоторых случаях при переходе с SATA на AHCI (или наоборот) Windows может не загружаться. Если это произойдет, верните настройки режима SATA обратно в режим AHCI.

3. Замените блок питания (блок питания), если у вас есть настольный компьютер.
4. Протестируйте и диагностируйте жесткий диск на предмет аппаратных проблем.

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