» Windows Server 2012 R2 — перестает отвечать, виснет

Исходные данные:
— Конфигурация компьютера/сервера: AMD Athlon II X3 440/RAM 8Gb/2 x HDD 500GB + 2 x SSD Samsung 850 EVO 250GB/Video Palit NVIDIA GeForce 210 512 Mb
— Установлена Windows 2012R2 со всеми обновлениями с ролью терминальных служб (терминальный сервер)
— Установлены также MS SQL 2012R2 и 1C:Предприятие 8.2
— Из HDD сделан программный массив средствами ОС (диск C), также сделан массив из двух SSD (диск D). На диске C — система, а на диске D — базы SQL для 1С.

Временами, точнее всегда виснет вся винда, как-бы замирает на 5-10 секунд, курсов мышки при этом двигается. Потом отвисает и работает. Это повторяется, сперва одну минуту все нормально, а потом тормоза, explorer и программы — не отвечают, но курсор мышки двигается во время 5-10го секундного зависания.

В логах появляется сообщение:
1.
Цитата:

svchost (1680) Запрос на чтение файла «C:\Windows\system32\LogFiles\Sum\Current.mdb» со смещением 151552 (0x0000000000025000) размером 4096 (0x00001000) байт не был выполнен в течение 36 с. Скорее всего, данная проблема связана с неисправным оборудованием. За помощью в диагностике проблемы обращайтесь к поставщику оборудования.

svchost (1680) Запрос на запись в файл «C:\Windows\system32\LogFiles\Sum\Svc.log» со смещением 929792 (0x00000000000e3000) размером 4096 (0x00001000) байт выполнен, но его выполнение ОС заняло слишком много времени (60 секунд). Кроме того, с тех пор как последнее сообщение об этой ошибке было возвращено 7559 секунд назад, выполнение 0 других запросов ввода-вывода из этого файла также заняло слишком много времени. Вероятно, эта ошибка вызвана сбоем оборудования. Обратитесь к поставщику оборудования, чтобы точно установить причину ошибки.

svchost (1680) Запрос на запись в файл «C:\Windows\system32\LogFiles\Sum\Svc.log» со смещением 929792 (0x00000000000e3000) размером 4096 (0x00001000) байт не был выполнен в течение 36 с. Скорее всего, данная проблема связана с неисправным оборудованием. За помощью в диагностике проблемы обращайтесь к поставщику оборудования.

Служба «Диспетчер настройки устройств» перешла в состояние Остановлена.

Служба «Диспетчер настройки устройств» перешла в состояние Работает.

Вот с датчиков инфа:
Свойства датчика

Тип датчика ITE IT8728F (ISA 228h)
Тип датчика ГП Diode (NV-Diode)
Системная плата Gigabyte 890GPA-UD3H / 970A / 990FXA / 990XA / A55 / A75 Series
Обнаружено вскрытие корпуса Да

Системная плата 27 °C (81 °F)
ЦП 25 °C (77 °F)
ЦП 1 / Ядро 1 25 °C (77 °F)
ЦП 1 / Ядро 2 25 °C (77 °F)
ЦП 1 / Ядро 3 25 °C (77 °F)
Северный мост 38 °C (100 °F)
Диод ГП 32 °C (90 °F)
ST3500413AS (5VMRNLG4) 32 °C (90 °F)
ST3500413AS (5VMPW0XE) 31 °C (88 °F)
Samsung SSD 850 EVO 250GB (S21MNSAG105418D) 30 °C (86 °F)
Samsung SSD 850 EVO 250GB (S21MNSAG105379Z) 30 °C (86 °F)

Ядро ЦП 1.320 V
+3.3 V 3.344 V
+5 V 5.040 V
+12 V 12.024 V
DIMM 1.488 V
Ядро ГП 1.050 V

До этого я поменял мат. плату и ОЗУ, оставив только процессор. Системе — всего две недели.

Сам думаю переустановить всю Windows 2012R2 или установить более старую и наверно стабильную 2008R2.

ESENT Event ID 327 и 326 заполняют журнал приложения

В этой статье предоставляется решение проблемы, из-за которой ESENT Event IDs 327 и 326 заполняются файлом журнала приложений.

Оригинальная версия продукта: Windows Server 2019, Windows Server 2016
Исходный номер КБ: 2900773

Симптомы

При использовании Версий Windows Server 2012 и более поздних версий в журнале событий приложений с высокой частотой (около 5 раз/сек) в журнале событий приложения регистрируются следующие события о SystemIdentity.mdb.

Источник: ESENT
ID события: 327
Категория задач: общие
Уровень: Сведения
Ключевое слово: Классический
Описание:
Двигатель базы данных svchost (2576) имеет присоединенную базу данных (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity.mdb). (Time=0 sec)

Внутренняя последовательность времени: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.032, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.015. Кэш восстановления: 0
Источник: ESENT
ID события: 326
Категория задач: общие
Уровень: Сведения
Ключевое слово: Классический
Описание:
Двигатель базы данных svchost (2576) имеет присоединенную базу данных (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity.mdb). (Time=0 sec)

Внутренняя последовательность времени: [1] 0.000, [2] 0.000, [3] 0.281, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.000.
Кэш хранилища: 1

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

Причина

Эта проблема возникает при проблеме с данными в файле базы данных SystemIdentity.mdb.

Решение

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

После остановки службы сделайте одно из следующих.

Удаление и регенерация файлов базы данных

После остановки службы удалите все файлы в %SystemRoot%\system32\LogFiles\Sum\ папке. После этого запустите службу журнала доступа пользователей. База данных будет создана заново.

Остановка службы журнала доступа к пользователю

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

ESENT Event ID 327 and 326 fill up the Application log

This article provides a solution to an issue where ESENT Event IDs 327 and 326 are filled up the Application log file.

Original product version: В Windows Server 2019, Windows Server 2016
Original KB number: В 2900773

Symptoms

When using Windows Server 2012 and later versions, the following events are logged in the application event log at high frequency (about 5 times/sec) about SystemIdentity.mdb.

Source: ESENT
Event ID: 327
Task category: General
Level: Information
Keyword: Classic
Description:
svchost (2576) database engine has attached database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity.mdb). (Time=0 sec)

Internal timing sequence: [1] 0.000, [2] 0.000, [3] 0.000, [4] 0.000, [5] 0.000, [6] 0.032, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.015. Recovery cache: 0
Source: ESENT
Event ID: 326
Task category: General
Level: Information
Keyword: Classic
Description:
svchost (2576) database engine has attached database (2, C:\Windows\system32\LogFiles\Sum\SystemIdentity.mdb). (Time=0 sec)

Internal timing sequence: [1] 0.000, [2] 0.000, [3] 0.281, [4] 0.000, [5] 0.000, [6] 0.000, [7] 0.000, [8] 0.000, [9] 0.000, [10] 0.000, [11] 0.000, [12] 0.000.
Storage cache: 1

As a result, the application event log will be filled up and other events may be difficult to confirm.

Cause

This issue occurs when there’s a problem with the data in the SystemIdentity.mdb database file.

Resolution

To stop the occurrence of this event, stop the User Access Logging service.

After stopping the service, do one of the following.

Database file deletion and regeneration

After stopping the service, delete all files in the folder %SystemRoot%\system32\LogFiles\Sum\ . After that, launch the User Access Logging service. The database will be newly generated.

Stop User Access Logging service

If you aren’t using the User Access Logging service, disable it. After stopping the service, disable Startup Type for User Access Logging at the Service item of the maintenance tool.

Вертим логи как хотим ― анализ журналов в системах Windows

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

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

Журналы и командная строка

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

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

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

Для получения списка доступных системных журналов можно выполнить следующую команду:

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

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

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

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