2011-02-01 9 views
9

¿Existe un rango específico de Id. De evento en Windows reservado para desarrolladores de aplicaciones?Id. De evento de Windows

Estoy trabajando en una aplicación .Net que escribirá errores en el registro de eventos de Windows. Esta aplicación en realidad se dirige a los servidores y los administradores de sistemas paranoicos la ejecutarán como una tarea programada y querrán bloquearla tanto como sea posible (incluida su ejecución con una cuenta de mantenimiento de privilegios reducida). La aplicación no se instalará formalmente —, de hecho, ni siquiera estoy construyendo un instalador para esto; solo un archivo zip con el archivo .exe y app.config.

Este es el truco: en Windows, necesita privilegios de administrador para crear una fuente en el registro de eventos de la aplicación. Como no puedo contar con esto y no quiero que los administradores de sistemas con exceso de trabajo tengan que crear uno, estoy usando "Error de aplicación" (utilizado por MS Office) como alternativa. (Escojo una mejor alternativa en mi lista de tareas pendientes, ya que la oficina no está tan frecuentemente instalada en los servidores).

El problema es que todavía quiero que mis eventos se destaquen un poco, en lugar de simplemente hacerse pasar por Office. De esta forma, mis administradores de sistema pueden filtrar fácilmente a esos eventos en el Visor de eventos o al agregador de registros de su elección. La mejor solución de la que tengo conocimiento en este momento es usar el Id. De evento, pero me preocupa entrar en conflicto con los eventos internos de Windows, especialmente teniendo en cuenta mi público objetivo.

Lo he buscado, pero no encuentro ninguna documentación al respecto. Entonces, ¿hay un rango específico de Id. De evento que debería usar, estaré bien usando lo que sea, o debería considerar una opción completamente diferente aquí?

+0

Sé que los ID de eventos web tienen un rango reservado. En cuanto al registro de eventos en general, no sé. – leppie

Respuesta

4

No realmente. En el nivel superior, tienes una Fuente de evento. Cada fuente de evento tiene sus propias categorías de eventos. Cada mensaje de evento es "propiedad" de una fuente de evento y cae en una de sus categorías de evento. Si vas a registrar tus eventos en la fuente de eventos de otra persona, estás incumpliendo esta convención y posiblemente puedas tener colisiones de identificación de evento.

Por otro lado, Event IDs son estructuralmente similares a HRESULT y hay un cliente que puede configurar. También hay un campo de Código de instalación, pero Microsoft solo proporciona una instalación para terceros (el resto está reservado). Incluso si te metes con estos bits, todavía estás a merced del propietario de la Fuente del evento; si alguna vez Microsoft escribiera algo al Origen del evento que está utilizando y configurara el Bit del cliente o el Código de instalación (por ejemplo, componentes que no sean de Windows como Office o algo así), estaría en el mismo peligro de colisiones. O si algún otro desarrollador decide hacer lo mismo que estás haciendo. Realmente, la forma más segura es definir tu propia fuente de eventos.

2

Parece que este es el quid de la cuestión

me preocupa en conflicto con eventos internos de Windows, sobre todo teniendo en cuenta mi público objetivo.

No creo que tenga que preocuparse porque la identificación del evento corresponde a una fuente de evento específica, así que a menos que use exactamente la misma fuente no provocará que el administrador se enoje. Por ejemplo, MS a veces hace uses the same ID con diferentes fuentes.

Si desea obtener información sobre los editores registrados y los identificadores de eventos, puede usar Wevtutil Por ejemplo, esto mostrará los editores.

wevtutil ep 

Desde que se puede obtener los identificadores de eventos específicos que se utilizan para un editor puede utilizar el siguiente (Registro de eventos se utilizó en este ejemplo)

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

Si usted es bueno en powershell I' Estoy seguro de que podría encontrar una secuencia de comandos para obtener todos los identificadores de eventos que están registrados

+2

El problema con usar el Origen de eventos de otra persona es que el visor de eventos usará el archivo de mensaje correspondiente para formatear el mensaje de error, para que los registros de eventos se vean como "Microsoft Outlook experimentó un error de aplicación" o lo que sea cuando en realidad el mensaje era generado por tu programa. O si usa identificadores de eventos "no utilizados", el usuario tendrá que memorizarlos ya que no habrá una cadena correspondiente en el archivo de mensajes. De cualquier manera, no es una buena experiencia de usuario. – Luke

+0

Viejo ahora, pero volver a utilizar una fuente de eventos existente era el punto. Crear mi propia fuente de eventos hubiera requerido privilegios de administrador, pero quiero que la aplicación pueda ejecutarse sin necesidad de derechos de administrador, incluso en el momento de la instalación. –

Cuestiones relacionadas