Создаем собственный журнал событий в Windows

Как вы знаете, большинство «нормальных» приложений записывают свои события в журнал событий Windows (Application Event Log). Это отличное место для централизованного хранения и просмотра событий приложений, однако зачастую при возникновении необходимости журналировать события от определенного приложения в данном журнале, мы можем столкнуться с тем, что из-за большого количества и чрезмерной подробности событий, работать со стандартным журналом приложений Windows становится очень неудобно. В данном случае было бы удобно создать собственный журнал событий для данного приложения, и для него настраивать различные параметры, такие как размер журнала, фильтры и т.д., а стандартный журнал Application можно использовать как обычно, не засоряя его ненужной информацией. В ОС семейства Windows присутствует функция, позволяющая создать собственный журнал событий.

Сначала создадим новый файл журнала. Сделать это можно при помощи реестра. Запустите редактор реестра regedit и перейдите в ветку:

Щелкните правой кнопкой по узлу Eventlog и создайте новый ключ (New > Key)

Имя ключа в этом случае будет являться и именем нового журнала. По умолчанию новый журнал (файл .evt) создается тут:

Его можно переименовать, изменив строковый параметр в реестре по своему усмотрению.

Далее нужно добавить источники (Sources) событий для нового журнала. Создайте новый ключ типа Multi-String с именем “Sources”, в качестве параметров укажите имена всех приложений, который будут использовать данный журнал (каждое приложение с новой строки).

Затем нужно перенести ассоциации ваших приложений из стандартного журнала Application в ваш новый журнал. Разверните ветку “Application”, находящуюся по адресу:

И скопируйте все ветки, которые относятся к интересуемым Вами приложениям в новый ветку реестра нового журналa:

Т.к. команда скопировать/вставить в редакторе реестра не работает, их можно пересоздать вручную (если их немного), или же можно осуществить перенос при помощи процедуры экспорта/импорта веток реестра с ручным редактирование .reg файла. Убедитесь, что после переноса вы удалили ключи реестра ваших приложений из ветки Application, иначе Windows не поймет, что нужно писать события в новый журнал. В том случае, если вы используете новый источник событий для журнала, нужно будет создать параметр типа DWORD с именем CustomSource и значением равным 1:

В моем примере, я создал собственное приложение .NET 2.0, причем я хочу, чтобы оно записывало события в созданный нами журнал. Для этого я создам новый ключ реестра EventMessageFile и укажу в нем путь к библиотеке журналирования.NET 2.0:

Затем нужно перезагрузить Windows, а после загрузки системы вы увидите новый журнал событий в разделе Event Viewer-а. В том случае, если ваше приложение по какой-либо причине не пишет событий в новый журнал, можно протестировать его работу вручную, откройте командую строку и перейдите в каталог:

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

Update:

Небольшое обновление статьи по письмам читателей:

Вышеприведенная инструкция по созданию собственного журнала ориентирована на серверные ОС семейства Microsoft. Более общий способ, который должен работать в большинстве Windows следующий (отличаются пути в реестре и ключи):

Создаем новый раздел в реестре (имя раздела — имя создаваемого журнала), путь к созданному будет таким:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\NewEventLog , в котором нужно создать следующие ключи:

• «AutoBackupLogFiles» — тип DWORD, создавать или нет резервные копии журнала (0 — не создавать)
• «MaxSize» -тип DWORD, максимальны размер журнала в байтах, значение должно быть кратным 64Кб
• «Retention» — тип DWORD, время хранения записей в случае переполнения журнала.
• «File» — тип REG_EXPAND_SZ, строка, в которой содержится путь к логу журнала на жестком диске, например %SystemRoot%\System32\config\NewEventLog.evt)
• «Sources»- тип REG_MULTI_SZ, здесь указан список источников событий, чьи логи должны попадать в этот журнал, каждый источник с новой строки

Запись записей в журнал событий с помощью Visual C++

В этой статье описывается, как добавить собственные записи в журнал событий операционной системы с помощью Microsoft .NET Framework.

Исходная версия продукта: Visual C++
Исходный номер статьи базы знаний: 815661

Требования

Visual Studio .NET

Запись записей в журнал событий

Ведение журнала событий обеспечивает стандартный централизованный способ, позволяющий приложениям записывать важные события программного обеспечения и оборудования. Windows предоставляет стандартный пользовательский интерфейс для просмотра журналов: «Просмотр событий». Используя компонент EventLog общеязыковой среды выполнения, вы можете легко подключаться к существующим журналам событий на локальном и удаленном компьютере, а также записывать записи в эти журналы. Вы также можете читать записи из существующих журналов и создавать собственные журналы событий. В самой простой форме запись в журнал событий включает несколько шагов для создания примера приложения.

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

Запустите Visual Studio .NET.

Создайте новый проект приложения с управляемым C++ для Visual C++.

Добавьте ссылку на system.dll , добавив следующую строку в код:

Используйте using директиву для System System::Diagnostics пространств имен, чтобы не было необходимости уточнять объявления из этих пространств имен позже в коде. Перед всеми другими объявлениями можно использовать следующие операторы:

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

• Ваше сообщение
• Имя журнала, в котором необходимо создать запись (если он еще не существует).
• Строка, представляющая источник события

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

Используйте два статических метода EventLog класса, чтобы проверить, существует ли источник, и если источник не существует, создайте этот источник, связанный с определенным журналом событий. Если указанное имя журнала не существует, имя создается автоматически при записи первой записи в журнал. По умолчанию, если для метода не указано имя журнала CreateEventSource , то файл журнала называется log Application.

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

Сохраните свое приложение. Запустите приложение, а затем проверьте наличие новых событий в разделе Просмотр событий в приложении «Просмотр событий».

Использование ведения журнала событий в центре администрирования Windows для получения сведений о действиях по управлению и отслеживания использования шлюза Use event logging in Windows Admin Center to gain insight into management activities and track gateway usage

Область применения. Windows Admin Center, ознакомительная версия Windows Admin Center Applies To: Windows Admin Center, Windows Admin Center Preview

Центр администрирования Windows записывает журналы событий, чтобы видеть, какие действия по управлению выполняются на серверах в вашей среде, а также как устранять неполадки в работе центра администрирования Windows. Windows Admin Center writes event logs to let you see the management activities being performed on the servers in your environment, as well as to help you troubleshoot any Windows Admin Center issues.

Получение сведений о действиях управления в вашей среде с помощью ведения журнала действий пользователя Gain insight into management activities in your environment through user action logging

Центр администрирования Windows предоставляет сведения о действиях управления, выполняемых на серверах в вашей среде, путем регистрации действий в канале событий Microsoft-серверманажементекспериенце в журнале событий управляемого сервера с идентификаторами EventID 4000 и Source смегатевай. Windows Admin Center provides insight into the management activities performed on the servers in your environment by logging actions to the Microsoft-ServerManagementExperience event channel in the event log of the managed server, with EventID 4000 and Source SMEGateway. Центр администрирования Windows регистрирует только действия на управляемом сервере, поэтому события, регистрируемые пользователем, обращаются к серверу только для чтения. Windows Admin Center only logs actions on the managed server, so you won’t see events logged if a user accesses a server for read-only purposes.

В число записанных событий входят следующие сведения: Logged events include the following information:

Ключ Key	Значение Value
PowerShell PowerShell	Имя сценария PowerShell, которое было запущено на сервере, если действие выполнило сценарий PowerShell. PowerShell script name that was run on the server, if the action ran a PowerShell script
ПРОГРАММЕ CIM	Вызов CIM, который был выполнен на сервере, если действие выполняло вызов CIM CIM call that was run on the server, if the action ran a CIM call
Модуль Module	Инструмент (или модуль), в котором было выполнено действие Tool (or module) where the action was run
Шлюз Gateway	Имя компьютера шлюза центра администрирования Windows, на котором было запущено действие Name of the Windows Admin Center gateway machine where the action was run
усеронгатевай UserOnGateway	Имя пользователя, используемое для доступа к шлюзу центра администрирования Windows и выполнения действия User name used to access the Windows Admin Center gateway and execute the action
усеронтаржет UserOnTarget	Имя пользователя, используемое для доступа к целевому управляемому серверу, если оно отличается от Усеронгатевай (т. е. доступ пользователя с помощью сервера с использованием учетных данных «Управление как»). User name used to access the target managed server, if different from the userOnGateway (i.e. the user accessed using the server using «Manage as» credentials)
Делегирование Delegation	Логическое: Если целевой управляемый сервер доверяет шлюзу и учетные данные делегируются с клиентского компьютера пользователя Boolean: if the target managed server trusts the gateway and credentials are delegated from the user’s client machine
Lap LAPS	Логическое значение: Если пользователь обратился к серверу с помощью учетных данных Lap Boolean: if the user accessed the server using LAPS credentials
Файл File	Имя переданного файла, если действие прошло отправку файла name of the file uploaded, if the action was a file upload

Сведения о действиях центра администрирования Windows с ведением журнала событий Learn about Windows Admin Center activity with event logging

Центр администрирования Windows записывает активность шлюза в канал событий на компьютере шлюза, чтобы помочь в устранении неполадок и просмотре метрик использования. Windows Admin Center logs gateway activity to the event channel on the gateway computer to help you troubleshoot issues and view metrics on usage. Эти события регистрируются в канале событий Microsoft-серверманажементекспериенце . These events are logged to the Microsoft-ServerManagementExperience event channel.

Создание собственных событий Windows в журнале

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

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

eventcreate /l ИмяЖурнала /so ИсточникСобытия /t ТипСобытия / id КодСобытия /d ОписаниеСобытия

1. ИмяЖурнала — название журнала для записи события; если оно содержит пробелы, заключите его в кавычки, на­пример «DNS Server».
2. ИсточникСобытия — указывает источник события и может быть любой строкой. Если строка содержит пробелы, зак­лючите ее в кавычки, например «Event Tracker*. В боль­шинстве случаев источник указывает на приложение, зада­ние или сценарий, вызвавший ошибку.
3. ТипСобытия — задает тип события. Может принимать зна­чения Information, Warning или Error. Типы событий «Success Audit» и «Failure Audit» неприменимы, так как исполь­зуются в журнале безопасности, в который записывать соб­ственные события нельзя.
4. КодСобытия — залает числовой код события. Может при­нимать любое значение от 1 до 1000. Чем случайно назна­чать идентификаторы, лучше составить список общих собы­тий, которые могут возникнуть, а затем разбить его на кате­гории. Тогда каждой категории можно присвоить свой диа­пазон кодов событий. Например, события из первой сотни могут быть общими, из второй — событиями состояния, из пятой — предупреждениями, а из девятой — ошибками.
5. ОписаниеСобытия — задает описание события и может быть любой строкой. Не забудьте заключить строку в кавычки.

Журнал событий (Event Logging)

Win32: централизованное протоколирование событий

Автор: Серебряков Алексей (Smooky)
QUIBECK INC.
Источник: RSDN Magazine #3-2007

Опубликовано: 14.11.2007
Исправлено: 10.12.2016
Версия текста: 1.0

Предисловие

Многие из Вас, наверное, принимали участие в крупных и долгосрочных проектах, где разрабатывалось приличное количество модулей, использовались многочисленные библиотеки, сценарии и т.д. Мне тоже приходилось участвовать в таких проектах. Один из них и натолкнул меня на мысль о создании этой статьи. В том проекте участвовало множество программистов, разработчиков и тестеров. Каждый разработчик писал небольшой модуль протоколирования (логирования, от англ. logging, — снимать, записывать показания с прибора) и трассировки своих модулей и наработок. Кто-то писал свои утилиты, которые потом разбирали эти протоколы, кто-то использовал буферизованный вывод, т.е. какого-то чёткого регламента по этой деятельности не было. Результатом всей этой деятельности стало большое количество разбросанных текстовых и бинарных файлов с понятными и непонятными расширениями, непонятного формата и содержания. Понятно, что при такой организации так и должно было случиться. Хуже того, бывает и так, что при выходе финальной версии не удаётся всё это убрать, и всё это оказывается у пользователя и заказчика.

Для решения этой проблемы операционная система Windows предоставляет такой сервис и программный интерфейс, как Eventlog. Этот инструментарий относится к числу базовых сервисов Windows, т.е. поставляется с самой системой и система сама же его использует. Стоит заметить, что эта возможность есть только у систем семейств WinNT/XP, т.к. приложение для протоколирования событий является сервисом. Также стоит заметить, что в Windows Vista и Windows Longhorn этот сервис существенно переработан, новый вариант в этой статье рассматриваться не будет.

Мы не будем также рассматривать этот замечательный инструмент с точки зрения администраторов, сборщиков журналов и прочих персон, которые призваны управлять системой. Итак, приступим.

Теория

Рисунок 1.

Наверное, почти все разработчики используют в своих программах протоколирование событий при выявлении ошибок, отладке и диагностировании приложений. Но даже после успешного сбора и просмотра статистики иной раз бывает сложно проанализировать, что же всё-таки случилось и в каком месте? Так вот, сервис «Журнал событий» является стандартным, централизованным способом сбора статистики и просмотра сообщений о событиях, поступающих от приложений, сервисов операционной системы и аппаратных устройств. Средство для просмотра этих событий является оснасткой Microsoft Management Console. В Windows XP Rus эта оснастка запускается так: Пуск->Настройка->Панель управления->Администрирование->Просмотр Событий (Event Viewer).

ПРЕДУПРЕЖДЕНИЕ При использовании сервиса протоколирования в журнал следует записывать достаточно важные и нужные сведения о происшедших ошибках, которые действительно потом могут помочь разработчикам разобраться, что же произошло с приложением. Не следует, например, писать в системный журнал с периодичностью 100нс сообщения о том, что пользователь случайно удалил файл readme.txt. Журнал событий – это не средство трассировки. Рекомендации по протоколированию событий При описании событий в журнале старайтесь придерживаться следующих рекомендаций, это поможет вам сделать журналы событий удобочитаемыми и опрятными. Помните, что журналы — это уже не только ваши собственные файлы трассировки, а разделяемый сервис, и не только вы ими пользуетесь. Сообщение в журнале событий – это, прежде всего, информация, способная помочь вам, администратору и даже пользователю понять, какая проблема возникла в приложении и как её устранить. В частности, это событие может предназначаться специалисту технической поддержки в вашей компании, и даже ему будет тоскливо читать сообщение: «Процесс А не смог прочитать 0x05 байт 0x2-ого сектора дисковода В». Поэтому идеальное сообщение должно помочь пользователю ответить на следующие вопросы: Что случилось и почему? Что ему (пользователю) делать дальше? Что он (пользователь) может сделать, чтобы этого больше не повторилось? Могут пригодиться и следующие рекомендации: Избегайте условных ошибок. Если вы можете спрогнозировать ошибку, которая может случиться в случае выполнения некоторого действия, перепишите свой код так, чтобы пользователь не получал сообщения об ошибке. Напишите текстовое сообщение для каждой известной ошибки. Используйте системные коды и сообщения об ошибках. Предоставьте пользователю хотя бы один вариант решения проблемы, возникшей вследствие вашей ошибки. Не используйте технические термины, жаргон, сленг и аббревиатуры. В диалоговых сообщениях используйте именно необходимые кнопки (такие как Yes, No, Cancel). Соглашения о стиле содержания сообщения: Используйте подробные, но простые предложения. Не используйте слова, состоящие из одних заглавных букв. Используйте точную семантику. Например, вместо сообщения “Bad size” лучше всё-таки указать пользователю правильный размер. Это неполный список рекомендаций, взятый из MSDN. На самом деле в популярных книгах, например, у Саттера, есть более интересные рекомендации. События в журнале В журнал можно записывать пять типов событий. Все типы событий достаточно понятно классифицированы, определены и могут включать много дополнительной информации. Каждое событий, которое мы посылаем из своего приложения, может иметь только один тип. Определены следующие типы событий: Тип события Пояснение Ошибка (Error) Этим типом обычно определяется серьёзная ошибка приложения. Например, исполнение приложения прервалось из-за нехватки ресурсов. Предупреждение (Warning) Этим типом приложение обычно информирует о том, что скоро может возникнуть проблема, например, закончится дисковое пространство. Информация (Information) Этим типом приложение обычно информирует об успехе какой-либо важной операции, например, при старте сервиса. Успешный отчёт (Success Audit) Этот тип события обычно означает об успехе какой-либо операции доступа, например, пользователь вошёл в систему. Не успешный отчёт (Fault Audit) Этот тип события обычно означает, что произошла какая-то ошибка при доступе к ресурсу, например, пользователь не смог обратиться к сетевому диску. Поскольку запись в журнал может происходить нечасто, в тексте сообщения следует достаточно полно описывать происшедшее событие. Следует достаточно понятно описывать событие, так как информацию о событии, до того как она попадёт к разработчику, может просмотреть, например, администратор системы и не придав ей особого значения, просто проигнорировать. СОВЕТ В тексте сообщения о событии лучше не применять символы табуляции и точку с запятой, так как журнал может экспортироваться в текстовый файл с разделителями. Многие организации импортируют журналы событий в свои базы данных для диагностики своими средствами. Строки в формате UNC лучше заключать в треугольные скобки, например . Элементы журнала событий Журналы Всю информацию о настройках журнала сервис берёт из реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog. Каждая ветка в этом ключе – это журнал. Изначально их всего три, но можно создавать свои журналы, и регистрировать свои приложения как источники событий для этих журналов. Журнал (Log) Пояснение Приложение (Application) Этот журнал содержит записи от приложений. Например, если мы зарегистрируем свой источник событий (т.е. приложение) и не укажем журнал, по умолчанию записи будут поступать сюда. Система (System) Этот журнал содержит записи, поступающие от системных служб. Но писать в него может любое приложение. Безопасность (Security) Этот журнал предназначен для аудита, например, событий входа пользователя в систему. Другой (Custom) Можно создать свой журнал. Не поддерживается в Windows NT. Контроллер домена имеет еще два дополнительных журнала: Directory и File Replication . DNS-сервер также имеет дополнительный журнал, DNS . Для каждого журнала определяются ключи. Практически все они необязательны и имеют значения по умолчанию, но рекомендуется всё же создавать их для своего журнала. Ключ в реестре Пояснение 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. Именно это имя будет передаваться функции RegisterEventSource , которая вернёт описатель (handle) журнала. Пользовательские приложения и сервисы должны либо регистрировать себя в журнале 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 Фактически получается, что когда приложение вызовет функции RegisterEventSource или OpenEventLog , сервис Eventlog будет искать в реестре ветку MySuperApp, чтобы вернуть описатель журнала. Если он не найдет ветку с именем MySuperApp, по умолчанию будет использован журнал Application. ПРЕДУПРЕЖДЕНИЕ Однако если ветка была найдена, но не были определены файлы сообщений для найденного источника событий, то при открытии 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): 00 – Success 01 – Informational 10 – Warning 11 – Error Принадлежность (Customer bit): 0 – Системный 1 – Пользовательский Зарезервирован (R) Код подсистемы (Facility) Код ошибки (Code) Подробные пояснения можно найти в книге Рихтера или в 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. lpUNCServerName – UNC-имя удалённого компьютера (NULL — локальный). 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 предоставляет еще несколько функций (перебрать записи в журнале, найти запись, и т.д.) для работы с журналами событий. Почти все они нужны только для какой-либо программы-анализатора. Event Viewer при отображении журнала использует очень важную функцию FormatMessage . Мы тоже можем её использовать, чтобы показать сообщение из нашей ресурсной DLL. Послесловие Кому-то это может показаться нудным и даже ненужным занятием. Но логи всегда были очень полезным и действенным способом отладки приложений и устранения ошибок. Использование журналов событий имеет ряд преимуществ: Eventlog является «родным» сервисом системы, так почему бы им не пользоваться, тем более что им пользуется сама система? Вы можете, например, создать один раз один файл сообщений на всех языках, и все ваши приложения будут его использовать. Это дружественный сервис даже для администраторов. Вы можете создать свои надстройки над этим сервисом, например, анализатор логов, поиск и фильтрование. В Windows Vista Microsoft переработала этот сервис. Например, можно генерировать логи в XML, отсылать отчёты о логах и т.д. Читайте также:  Как настроить java linux Оцените статью Вам также может понравиться Windows или Linux: Что лучше выбрать? Есть много причин выбирать между Windows и Linux, но Файл владелец изменить linux Команда Chown в Linux Chown Command in Linux (File Установка шлюза по умолчанию linux Настройка сети вручную Содержание Краткое описание Чем разбить диск для linux ИТ База знаний Курс по Asterisk Полезно — Узнать IP — Правообладателям Политика конфиденциальности Контакты