Вот так, вы сможете исправить ошибки, связанные с LogWatNT.exe
Информация о файле LogWatNT.exe
Подробный анализ: LogWatNT.exe не является необходимым для Windows. Файл LogWatNT.exe находится в папке C:\Windows. Известны следующие размеры файла для Windows 10/8/7/XP 50,176 байт (97% всех случаев) или 49,152 байт. Находится в папке Windows, но это не файл ядра Windows. У файла нет информации о создателе этого файла. Приложение не видно пользователям. Это не системный процесс Windows. Поэтому технический рейтинг надежности 71% опасности.
Если LogWatNT.exe находится в подпапках диска C:\, тогда рейтинг надежности 42% опасности. Размер файла 69,632 байт (80% всех случаев) или 53,248 байт. Приложение не видно пользователям. Это не системный процесс Windows.
Если LogWatNT.exe находится в подпапках «C:\Program Files», тогда рейтинг надежности 26% опасности. Размер файла 53,248 байт. Это не системный процесс Windows. Вы можете деинсталлировать эту программу из панели инструментов. Приложение не видно пользователям.
Важно: Некоторые вредоносные программы маскируют себя как LogWatNT.exe. Таким образом, вы должны проверить файл LogWatNT.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Лучшие практики для исправления проблем с LogWatNT
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
LogWatNT сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
Reimage бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Журнал событий (Event Logging)
Win32: централизованное протоколирование событий
Автор: Серебряков Алексей (Smooky) QUIBECK INC. Источник: RSDN Magazine #3-2007
Опубликовано: 14.11.2007 Исправлено: 10.12.2016 Версия текста: 1.0
Предисловие
Для решения этой проблемы операционная система Windows предоставляет такой сервис и программный интерфейс, как Eventlog. Этот инструментарий относится к числу базовых сервисов Windows, т.е. поставляется с самой системой и система сама же его использует. Стоит заметить, что эта возможность есть только у систем семейств WinNT/XP, т.к. приложение для протоколирования событий является сервисом. Также стоит заметить, что в Windows Vista и Windows Longhorn этот сервис существенно переработан, новый вариант в этой статье рассматриваться не будет.
Мы не будем также рассматривать этот замечательный инструмент с точки зрения администраторов, сборщиков журналов и прочих персон, которые призваны управлять системой. Итак, приступим.
Теория
Рисунок 1.
Наверное, почти все разработчики используют в своих программах протоколирование событий при выявлении ошибок, отладке и диагностировании приложений. Но даже после успешного сбора и просмотра статистики иной раз бывает сложно проанализировать, что же всё-таки случилось и в каком месте? Так вот, сервис «Журнал событий» является стандартным, централизованным способом сбора статистики и просмотра сообщений о событиях, поступающих от приложений, сервисов операционной системы и аппаратных устройств. Средство для просмотра этих событий является оснасткой Microsoft Management Console. В Windows XP Rus эта оснастка запускается так: Пуск->Настройка->Панель управления->Администрирование->Просмотр Событий (Event Viewer).
ПРЕДУПРЕЖДЕНИЕ
При использовании сервиса протоколирования в журнал следует записывать достаточно важные и нужные сведения о происшедших ошибках, которые действительно потом могут помочь разработчикам разобраться, что же произошло с приложением. Не следует, например, писать в системный журнал с периодичностью 100нс сообщения о том, что пользователь случайно удалил файл readme.txt. Журнал событий – это не средство трассировки.
Рекомендации по протоколированию событий
Сообщение в журнале событий – это, прежде всего, информация, способная помочь вам, администратору и даже пользователю понять, какая проблема возникла в приложении и как её устранить. В частности, это событие может предназначаться специалисту технической поддержки в вашей компании, и даже ему будет тоскливо читать сообщение: «Процесс А не смог прочитать 0x05 байт 0x2-ого сектора дисковода В». Поэтому идеальное сообщение должно помочь пользователю ответить на следующие вопросы:
Могут пригодиться и следующие рекомендации:
Соглашения о стиле содержания сообщения:
Это неполный список рекомендаций, взятый из MSDN. На самом деле в популярных книгах, например, у Саттера, есть более интересные рекомендации.
События в журнале
В журнал можно записывать пять типов событий. Все типы событий достаточно понятно классифицированы, определены и могут включать много дополнительной информации. Каждое событий, которое мы посылаем из своего приложения, может иметь только один тип. Определены следующие типы событий:
Тип события
Пояснение
Ошибка (Error)
Этим типом обычно определяется серьёзная ошибка приложения. Например, исполнение приложения прервалось из-за нехватки ресурсов.
Предупреждение (Warning)
Этим типом приложение обычно информирует о том, что скоро может возникнуть проблема, например, закончится дисковое пространство.
Информация (Information)
Этим типом приложение обычно информирует об успехе какой-либо важной операции, например, при старте сервиса.
Успешный отчёт (Success Audit)
Этот тип события обычно означает об успехе какой-либо операции доступа, например, пользователь вошёл в систему.
Не успешный отчёт (Fault Audit)
Этот тип события обычно означает, что произошла какая-то ошибка при доступе к ресурсу, например, пользователь не смог обратиться к сетевому диску.
Поскольку запись в журнал может происходить нечасто, в тексте сообщения следует достаточно полно описывать происшедшее событие. Следует достаточно понятно описывать событие, так как информацию о событии, до того как она попадёт к разработчику, может просмотреть, например, администратор системы и не придав ей особого значения, просто проигнорировать.
СОВЕТ
Элементы журнала событий
Журналы
Всю информацию о настройках журнала сервис берёт из реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog.
Каждая ветка в этом ключе – это журнал. Изначально их всего три, но можно создавать свои журналы, и регистрировать свои приложения как источники событий для этих журналов.
Журнал (Log)
Пояснение
Приложение (Application)
Этот журнал содержит записи от приложений. Например, если мы зарегистрируем свой источник событий (т.е. приложение) и не укажем журнал, по умолчанию записи будут поступать сюда.
Система (System)
Этот журнал содержит записи, поступающие от системных служб. Но писать в него может любое приложение.
Безопасность (Security)
Этот журнал предназначен для аудита, например, событий входа пользователя в систему.
Другой (Custom)
Можно создать свой журнал. Не поддерживается в Windows NT.
Для каждого журнала определяются ключи. Практически все они необязательны и имеют значения по умолчанию, но рекомендуется всё же создавать их для своего журнала.
Ключ в реестре
Пояснение
DisplayNameFile
Имя файла, в котором содержится локализованная строка с названием журнала, то есть строка, которую покажет Event Viewer. Если параметр не указан, Event Viewer в качестве строки покажет наименование подключа, в котором определён параметр. По умолчанию все локализованные ресурсы находятся в %SystemRoot%\system32\ELS.DLL. Строковый параметр.
DisplayNameID
Идентификатор строки в ресурсной DLL. Тип параметра DWORD.
File
Путь к папке, где Event Viewer будет хранить файлы журналов. По умолчанию это %SystemRoot%\system32\config\MyLogName, где MyLogName – имя журнала. При создании нового файла журнала сервис должен иметь права на полный доступ к файлу. Если значение этого параметра будет неверным, все записи будут перенаправляться в журнал Application. В пути нельзя использовать имя удалённого компьютера, DOS-устройства, дисководы, именованные каналы. Нельзя использовать переменные окружения, которые нельзя раскрыть в контексте сервиса.
MaxSize
Максимальный размер журнала в байтах. По умолчанию 512К. Параметр DWORD.
PrimaryModule
Наименование ключа, где хранятся настройки по умолчанию. Обычно совпадает с наименованием журнала. Строковый параметр.
Retention
Интервал в секундах, в течение которого записи могут остаться не перезаписанными. Если установлено в ноль, записи в журнале всегда перезаписываются, если не ноль или 0xFFFFFFFF, то записи никогда не перезаписываются. При достижении максимального размера журнал необходимо очистить вручную, иначе записи будут потеряны. Перед тем, как изменять это значение, журнал необходимо очистить. Параметр DWORD. По умолчанию – 0.
Sources
Список приложений, сервисов, которые могут писать в журнал. Только для чтения. Этот список создаёт сам сервис. Названия приложений берутся из текущей ветки журнала и разделяются null-terminated. Параметр многострочный.
AutoBackupLogFiles
Если значение параметра – 0, журнал не сохраняется как резервная копия. По умолчанию – 0.
RestrictGuestAccess
Если значение – 1, то пользователи под учётной записью Guest и Anonymous не имеют доступа к журналу. По умолчанию – 0.
Isolation
Не используется.
Источники событий
Каждая подветка в ветке Eventlog – это источник событий.
Например, для приложения MySuperApp.EXE, которое будет записывать события в журнал Application, необходимо создать такую подветку:
Здесь MySuperApp – это произвольное имя, по которому сервис (журнал) будет опознавать события, поступающие от нашего приложения. Каких либо соглашений об имени в документации не указано, но видимо, имя должно быть уникально в пределах одной подветки. Обычно используется название приложения или исполняемого модуля. По сути дела, это и есть регистрация приложения в сервисах Event Logging и Event Viewer.
Пользовательские приложения и сервисы должны либо регистрировать себя в журнале Application, либо создавать свой журнал. Журнал Security используется только системой. Драйверы устройств должны использовать журнал System.
Каждый источник событий (как мы уже знаем, приложение) должен в своей подветке определить перечисленные ключи. Они помогают Event Viewer сопоставлять сообщения и подставляемые параметры из ресурсной DLL-библиотеки с идентификаторами в приложении (позже я это продемонстрирую на примере):
Ключ в реестре
Пояснение
CategoryCount
Число используемых категорий. Тип DWORD.
CategoryMessageFile
Путь к файлу с локализованными строками, определяющими категории. Строковый параметр.
EventMessageFile
Путь к файлу с локализованными строками сообщений. Можно перечислить несколько файлов через запятую. Например, EVT_ENG.DLL, EVT_RUS.DLL. Строковый параметр.
ParameterMessageFile
Путь к файлу с локализованными строками параметров, подставляемых в текст сообщения. Строковый параметр.
TypeSupported
Параметр определяет типы поддерживаемых сообщений. Например, только ошибки и предупреждения: EVENTLOG_ERROR_TYPE | EVENTLOG_WARNING_TYPE. Параметр DWORD определяет маску из следующих типов:EVENTLOG_ERROR_TYPE, EVENTLOG_WARNING_TYPE, EVENTLOG_INFORMATION_TYPE, EVENTLOG_AUDIT_SUCCESS, EVENTLOG_AUDIT_FAILURE
ПРЕДУПРЕЖДЕНИЕ
Однако если ветка была найдена, но не были определены файлы сообщений для найденного источника событий, то при открытии Event Viewer сообщит об ошибке. Поэтому хорошим тоном будет, не только зарегистрировать источник событий, но и предоставить файлы сообщений.
Рисунок 2.
Вот, собственно, основные теоретические сведения. Можно приступить к практическим занятиям.
Практика
Создадим сначала ресурсную библиотеку с категориями, сообщениями и параметрами. Для этого необходимо создать обычный текстовый файл с расширением MC.
Файл сообщений
Категории, сообщения и подставляемые параметры можно разместить как в одном файле, так и в разных. Для удобства и наглядности разместим всё в одном файле MYEVT_ENG.MC.
Категории событий
Категории событий – это всего лишь числовые идентификаторы, которые помогают фильтровать записи при просмотре журнала в Event Viewer. Каждый источник событий может обозначить свои категории любым числом. Надо только учесть, что они должны располагаться в начале файла сообщений последовательно (по порядку) и начинаться с 1. Подробное описание формата файла *.MC можно найти в в MSDN.
Идентификаторы событий
Каждый идентификатор события уникален в пределах файла сообщений. Каждый источник событий может определять свои собственные идентификаторы и связанные с ними строки. В Event Viewer при просмотре журнала мы как раз и видим эти строки (см. рисунок).
Формат кода идентификатора события выглядит так (впрочем, это соглашение, принятое в Windows):
3
3
2
2
2
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
1
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Severiry
C
R
Facility
Code
Важность ошибки (Severity):
Принадлежность (Customer bit):
Подробные пояснения можно найти в книге Рихтера или в MSDN.
Строки сообщений
Теперь определим строки сообщений, поясняющие событие. Строки сообщений могут содержать подставляемые параметры.
Итак, мы написали файл MYEVT_ENG.MC. Теперь нам понадобится утилита MessageCompiler (MC.EXE), которая поставляется с MSVC6.0 и Platform SDK. Это консольное приложение скомпилирует файл сообщений:
В результате мы получим следующие файлы: MYEVT_ENG.H (определения символических имён), Msg00001.bin (бинарный ресурс для каждого языка), MYEVT_ENG.RC (в нём подключены бинарные ресурсы). Кстати, файл WINERROR.H, поставляемый с Microsoft Visual Studio, именно так и сгенерирован.
Теперь скомпилируем файл ресурсов MYEVT_ENG.RC:
В результате мы получим файл MYEVT_ENG.RES. И, наконец-то, скомпилируем библиотеку:
Теперь нам осталось зарегистрировать источник событий и написать код, использующий журнал событий. К сожалению, Microsoft не предоставляет никаких утилит для регистрации источника событий (мне, по крайней мере, они неизвестны), поэтому делать все придется ручками. На целевой машине это можно сделать всего один раз, например, при инсталляции.
СОВЕТ
Один и тот же файл сообщений могут использовать несколько приложений. И даже если сообщения написаны на разных языках, они всё равно могут находиться в одном ресурсном файле.
Регистрация источника событий
Для регистрации источника событий достаточно всего лишь определить несколько ключей в реестре (описание ключей приведены выше).
Теперь сервис Eventlog готов принимать сообщения о событиях, а Event Viewer – показывать их. Осталось только это использовать.
Использование журнала событий
Здесь стоит пояснить две важные функции: RegisterEventSource и ReportEvent.
lpSourceName – это имя источника события, который будет отсылать сообщения в журнал. В нашем примере это был MySuperApp. Нельзя использовать журнал Security (функция вернёт INVALID_HANDLE_VALUE). Если имя источника события не было найдено в реестре (в подключе \Eventlog), будет использоваться журнал Application.
Функция возвращает описатель журнала или NULL.
hEventLog – описатель, который вернула функция RegisterEventSource.
wType – тип события (EVENTLOG_SUCCESS, EVENTLOG_AUDIT_FAILURE, EVENTLOG_AUDIT_SUCCESS, EVENTLOG_ERROR_TYPE, EVENTLOG_WARNING_TYPE, EVENTLOG_INFORMATION). Указать можно только один тип.
wCategory – категория (см. Категории событий)
dwEventType – сообщение (см. Идентификаторы событий)
lpUserSid – указатель на структуру SID.
wNumStrings – количество подставляемых параметров в lpStrings. Каждая строка ограничена 32К.
dwDataSize – число байт в lpRawData.
lpRawData – произвольный массив байтов. Event Viewer никак не интерпретирует эти данные и отображает их в том виде, в котором они были переданы.
Eventlog предоставляет еще несколько функций (перебрать записи в журнале, найти запись, и т.д.) для работы с журналами событий. Почти все они нужны только для какой-либо программы-анализатора.
Послесловие
Кому-то это может показаться нудным и даже ненужным занятием. Но логи всегда были очень полезным и действенным способом отладки приложений и устранения ошибок. Использование журналов событий имеет ряд преимуществ:
В Windows Vista Microsoft переработала этот сервис. Например, можно генерировать логи в XML, отсылать отчёты о логах и т.д.
Event Log Watcher Класс
Определение
Некоторые сведения относятся к предварительной версии продукта, в которую до выпуска могут быть внесены существенные изменения. Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, относительно приведенных здесь сведений.
Позволяет подписаться на входящие события. Каждый раз при публикации требуемого события в журнале событий вызывается событие EventRecordWritten и выполняется метод, обрабатывающий данное событие.
Примеры
Комментарии
Экземпляры этого класса создаются из EventLogQuery объектов, которые указывают запрос для подписки на события. Событие EventRecordWritten вызывается при регистрации события, соответствующего критериям, выраженным в запросе.
Конструкторы
Инициализирует новый экземпляр класса EventLogWatcher, указывая запрос событий.
Инициализирует новый экземпляр класса EventLogWatcher, указывая запрос событий и закладку, используемую в качестве начальной позиции для запроса.
Инициализирует новый экземпляр класса EventLogWatcher, указывая запрос события, закладку, используемую в качестве начальной позиции для запроса и логическое значение, определяющее, следует ли считывать события, уже зарегистрированные в журнале событий.
Инициализирует новый экземпляр класса EventLogWatcher, указывая имя или путь к журналу событий.
Свойства
Получает или задает значение, указывающее, следует ли этому объекту начать доставку событий делегату событий.
Методы
Освобождает все ресурсы, используемые этим объектом.
Освобождает неуправляемые ресурсы, используемые этим объектом. Кроме того, возможно освобождение управляемых ресурсов.
Определяет, равен ли указанный объект текущему объекту.
Служит хэш-функцией по умолчанию.
Возвращает объект Type для текущего экземпляра.
Создает неполную копию текущего объекта Object.
Возвращает строку, представляющую текущий объект.
События
Позволяет задать делегат (метод обработчика событий), который вызывается каждый раз при публикации события, соответствующего критериям, указанным в запросе события для данного объекта.
Журналирование Windows EventLog и система оповещения для администраторов
Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.
Microsoft своими «добрыми» технологиями сделала Windows практически несовместимым со штатными системами журналирования событий(syslog), но оставила небольшую лазейку которую можно использовать. Лазейка представляет собой комбинацию SNMP trap и программы экспорта системных событий evntwin.
Для работы связки нужен настроенный snmptrapd, а также активированный сервис SNMP на windows сервере (добавляется через «добавление/удаление компонентов»).
Первым делом нужно настроить сервер на который будут сбрасываться сообщения из Eventlog. После того как сервис настроен, запускаем программу evntwin.exe technet.microsoft.com/en-us/library/cc759390%28WS.10%29.aspx Как она выглядит видно на следующем скриншоте.
Принцип использования evntwin прост. Вы выбираете категорию и код события которые Вас интересуют и добавляете их в список. При наступлении события сообщение одновременно будет сохранено в EventLog, а также будет «трапнуто» на сервер мониторинга.
На сервере мониторинга в snmptrapd.conf нужно добавить строку обработчика.
Сам обработчик написан мной на perl, код можно взять по ссылке trapd.pl(Не рекомендуется копипастить подсвеченный код из поста, лучше взять по ссылке). Он разбирает входящие trap сообщения и формирует письмо администраторам.
Logon Failure: Reason:Unknown user name or bad password User Name:Popov_V Domain:MYDOM Logon Type:3 Logon Process:Advapi Authentication Package:Negotiate Workstation Name:SADC Caller User Name:SADC$ Caller Domain:MYDOM Caller Logon ID:(0x0,0x3E7) Caller Process ID:580 Source Network Address:192.168.0.20 Source Port:36018
Так как мы подписаны только на интересующие нас сообщения, мы не видим остального системного мусора из EventLog. Очень удобна данная система при вирусных эпидемиях типа Kido, когда сразу нельзя понять откуда пошло всё размножаться или при брутфорсе системных паролей. Потому что чётко виден Logon Failure и имя машины с которой была неудачная попытка.
Спокойной Вам работы. PS: готовый конфиг с представленными на скриншоте категориями лежит тут
