How to fix Event ID 642 ESENT error on Windows 10

Содержание

В статье «Диагностика проблем кластеров Windows Server 2008 R2», опубликованной в Windows IT Pro/RE № 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:\Windows\Cluster\Reports. По умолчанию, при выполнении команды для каждого узла создается свой файл 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 Это ключевое слово появляется в журнале при отказе ресурса. При наличии такой строки необходимо про-смотреть предыдущие записи, чтобы узнать, что инициировало отказ. В просмотре записей после этого события необходимости нет. При отказе ресурса всегда следует попытаться пройти через нормальный процесс отключения, даже если, скорее всего, будет выдана ошибка, поскольку ресурс недоступен.

Fix Event ID 642 ESENT error on Windows 10

The Extensible Storage Engine (ESE), which includes the ESENT. DLL, has been included in all releases of Windows since Windows 2000 and itвЂ™s used by a number of Windows components including Windows Update. If youвЂ™re encountering the Event ID 642 ESENT error after you upgrade Windows 10 on your device, then this post is intended to help you. In this post, we will provide the potential solutions you can try to mitigate this issue.

Users who just upgraded to Windows 10 v2004 are seeing this error. It appears to be a bug and Microsoft is expected to release a fix for this soon.

When this error occurs, youвЂ™ll see in the event log the following error description;

Video. UI (23680,D,2) : The database format feature version 9080 (0x2378) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Fix Event ID 642 ESENT error

LetвЂ™s take a look at the description of the process involved concerning either of the listed solutions.

1] Run SFC and DISM scan

Since the Event ID 642 ESENT error is triggered by a Windows update error, you should try restoring the Windows Update Datastore by running the SFC and DISM scan.

TheВ SFC/DISMВ is a utility in Windows that allows users to scan for corruptions in Windows system files and restore corrupted files.

On boot, check if the issue is resolved. If not, continue with the next solution.

2] Rollback the Windows 10 upgrade to an earlier version

This solution requires you to roll back the Windows 10 to the earlier version you upgraded from and see if the Event ID 642 ESENT error will be resolved.

Ошибка DistributedCOM Код события 10016 Windows 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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