Идентификаторы событий Windows - PullRequest
9 голосов
/ 01 февраля 2011

Существует ли определенный диапазон идентификаторов событий в Windows, зарезервированных для разработчиков приложений?

Я работаю над приложением .Net, которое будет записывать ошибки в журнал событий Windows. Это приложение на самом деле предназначается для серверов и будет запускаться как запланированное задание администраторами paranoid sys, которые захотят максимально заблокировать его (включая запуск с учетной записью обслуживания с ограниченными правами). Приложение не будет официально установлено & mdash; на самом деле, я даже не собираю инсталлятор для этого; просто zip-файл с файлами .exe и app.config.

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

Проблема в том, что я все еще хочу, чтобы мои события немного выделялись, а не просто маскировались под Office. Таким образом, мои системные администраторы могут легко отфильтровать только те события в Просмотрщике событий или агрегаторе журналов по своему выбору. Лучшее решение, которое мне известно на данный момент, - это использование идентификатора события, но меня беспокоит конфликт с внутренними событиями Windows, особенно с учетом моей целевой аудитории.

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

Ответы [ 2 ]

4 голосов
/ 02 февраля 2011

Не совсем. На верхнем уровне у вас есть источник событий. Каждый источник событий имеет свои собственные категории событий. Каждое сообщение о событии «принадлежит» источнику события и попадает в одну из его категорий событий. Если вы собираетесь регистрировать свои события под чьим-либо источником событий, вы нарушаете это соглашение и вполне можете столкнуться с Event ID.

С другой стороны, Идентификаторы событий структурно аналогичны HRESULT, и есть бит Customer, который можно установить. Существует также поле «Код объекта», но Microsoft предоставляет только одно средство для третьих лиц (остальные зарезервированы). Даже если вы возитесь с этими битами, вы все еще в зависимости от владельца источника события; если бы Microsoft когда-нибудь записала что-то в используемый вами источник событий и установила бит клиента или код объекта (например, возможно, компоненты, отличные от Windows, такие как Office или что-то в этом роде), вы бы снова оказались в той же опасности коллизий. Или если какой-то другой разработчик решит сделать то же самое, что и вы. На самом деле самый безопасный способ - определить собственный источник событий.

2 голосов
/ 02 февраля 2011

Кажется, в этом суть проблемы

Меня беспокоит конфликт с внутренними событиями Windows, особенно с учетом моей целевой аудитории.

Я не думаю, что вам нужно беспокоиться, потому что ID события соответствуют конкретному источнику событий, поэтому, если вы не используете точно такой же источник, вы не расстроитесь. Например, MS иногда использует один и тот же идентификатор с разными источниками.

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

wevtutil ep

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

wevtutil gp Microsoft-Windows-EventLog /ge /gm:true

Если вы хорошо разбираетесь в powershell, я уверен, что вы могли бы придумать сценарий для получения всех зарегистрированных идентификаторов событий

...