EventLog
permite obtener acceso a registros de eventos de Windows o personalizarlos; estos registros graban información sobre eventos de software o hardware importantes. Mediante EventLog, se puede leer a partir de registros existentes, escribir entradas en registros, crear o eliminar orígenes de eventos, eliminar registros y responder a entradas de registros. También se pueden crear nuevos registros al crear un origen de eventos.
Nota |
|---|
Si el Source del registro de eventos asociado a la instancia EventLog no existe, se crea un nuevo origen de eventos. Para poder crear un origen de eventos en Windows Vista y versiones posteriores o Windows Server 2003, debe tener privilegios de administrador. La razón de este requisito es que deben buscarse todos los registros de eventos, incluidos los de seguridad, para determinar si el origen del evento es único. A partir de Windows Vista, los usuarios no tienen permiso de acceso al registro de seguridad; por tanto, se produce una excepción SecurityException. A partir de Windows Vista, el Control de cuentas de usuario (UAC) determina los privilegios de un usuario. Si es miembro del grupo Administradores integrados, se le asignarán dos símbolos (tokens) de acceso en tiempo de ejecución: un símbolo (token) de acceso de usuario estándar y un símbolo (token) de acceso de administrador. De forma predeterminada, se le asignará el rol de usuario estándar. Para ejecutar el código que tiene acceso al registro de seguridad, primero debe elevar el nivel de sus privilegios de usuario estándar a administrador. Podrá hacerlo cuando inicie una aplicación haciendo clic con el botón secundario en el icono de la aplicación e indicando que desea ejecutarla como administrador. |
Importante |
|---|
Crear un objeto EventLog, escribir una entrada y pasar el objeto a código de confianza parcial puede originar un problema de seguridad. Los objetos del registro de eventos, como EventLogEntry y EventLogEntryCollection, no deben pasarse nunca a código que no sea de plena confianza. |
Importante |
|---|
En las versiones 1.0 y 1.1 de .NET Framework, esta clase necesita llamadores inmediatos que sean de plena confianza. En la versión 2.0 esta clase necesita EventLogPermission para acciones específicas. Es muy recomendable que no se conceda EventLogPermission al código de confianza parcial. La capacidad de leer y escribir en el registro de eventos permite que el código lleve a cabo acciones como la emisión de mensajes del registro de eventos en nombre de otra aplicación. |
Importante |
|---|
La creación o eliminación de un origen de eventos requiere la sincronización del código subyacente utilizando una exclusión mutua con nombre. Si una aplicación que cuenta con muchos privilegios bloquea la exclusión mutua con nombre, los intentos de crear o eliminar un origen de eventos harán que la aplicación deje de responder hasta que desaparezca el bloqueo. Para evitar este problema, no conceda nunca el permiso UnmanagedCode a código que no sea de confianza. Además, el permiso UnmanagedCode permite potencialmente omitir otros permisos y sólo se debería conceder a código de gran confianza. |
Para leer desde un registro, especifique el nombre de Log y MachineName (nombre del equipo del servidor) para EventLog. No es necesario especificar Source, ya que sólo es necesario un origen para escribir en registros. El miembro Entries se llena de forma automática con la lista de entradas del registro de eventos.
Nota |
|---|
No es necesario especificar MachineName si está conectándose a un registro mediante la especificación de un par Log / MachineName. Si no especifica el valor MachineName, se supone que se trata del equipo local ("."). |
Si se escribe en un registro de eventos, se debe especificar o crear un evento Source. Es necesario contar con derechos administrativos en el equipo para crear un nuevo origen de eventos.
Source
registra la aplicación con el registro de eventos como un origen de entradas válido. Solamente se puede utilizar la propiedad Source para escribir en un único registro cada vez.
Source
puede ser cualquier cadena aleatoria, pero el nombre debe ser diferente de otros orígenes del equipo. Es habitual que el origen sea el nombre de la aplicación u otra cadena de identificación. Un intento de crear un valor de Source duplicado produce una excepción. Sin embargo, se puede asociar un solo registro de eventos a varios orígenes.
Nota |
|---|
No existe nada para proteger a una aplicación de escribir como cualquier origen registrado. Si a una aplicación se le otorga el permiso Write, puede escribir eventos para cualquier origen válido que esté registrado en el equipo. |
Las aplicaciones y los servicios deben escribir en el registro de la aplicación o en un registro personalizado. Los controladores de dispositivos deben escribir en el registro del sistema. Si no se establece la propiedad Log explícitamente, el registro de eventos tomará como predeterminado el registro de aplicaciones.
Nota |
|---|
El registro de seguridad es de sólo lectura. |
Para escribir eventos en un registro de eventos, deberán utilizarse WriteEvent y WriteEntry. Para escribir eventos, es necesario especificar un origen de eventos; asimismo, antes de escribir la primera entrada con el origen, es necesario crearlo y configurarlo.
El nuevo origen de eventos deberá crearse durante la instalación de la aplicación. Esto permite al sistema operativo actualizar con tiempo la lista de orígenes de eventos registrados y su configuración. Si el sistema operativo aún no ha actualizado la lista de orígenes de eventos y se intenta escribir un evento con el nuevo origen, se producirá un error en la operación de escritura. Para configurar un nuevo origen, puede utilizarse EventLogInstaller o el método CreateEventSource. Es necesario contar con derechos administrativos en el equipo para crear un nuevo origen de eventos.
Aunque cada origen sólo puede escribir en un registro de eventos a la vez, la aplicación puede utilizar varios orígenes para escribir en diversos registros. Por ejemplo, una aplicación podría requerir la configuración de varios orígenes para registros de eventos o archivos de recursos diferentes. Para cambiar los detalles de configuración de un origen ya existente, será necesario eliminarlo primero para volver a crearlo con la nueva configuración. Si otras aplicaciones o componentes lo estuvieran utilizando, en lugar de eliminarlo, deberá crearse uno nuevo con la configuración actualizada.
El origen de eventos puede registrarse con recursos adaptados para la categoría de eventos y las cadenas de mensaje. La aplicación puede escribir entradas en el registro de eventos utilizando los identificadores de recursos, en lugar de especificar los valores de cadena reales. Vea las clases EventLogInstaller y EventSourceCreationData para obtener más información sobre cómo configurar su origen con archivos de recursos.
Cuando una aplicación escribe valores de cadena directamente en el registro de eventos, no es necesario establecer las propiedades del archivo de recursos para el origen. El origen deberá configurarse para escribir o bien entradas adaptadas o bien cadenas directas. Cuando una aplicación escriba entradas usando tanto identificadores de recursos como valores de cadena, deberán registrarse dos orígenes diferentes. Por ejemplo, puede configurarse un origen con archivos de recursos y usarlo en el método WriteEvent para escribir entradas en el registro de eventos mediante identificadores de recursos. A continuación, puede crearse otro origen sin archivos de recursos y usarlo en el método WriteEntry para escribir cadenas directamente en el registro de eventos.
Al escribir eventos, deberá especificarse como mínimo una cadena de mensaje o el identificador de recursos de una cadena de mensaje. Las demás propiedades de eventos son opcionales. Pongamos algunos ejemplos de la configuración opcional de eventos: se puede establecer EventLogEntryType para especificar el icono que muestra el visor de eventos para la entrada; es posible especificar un identificador de categoría para el evento, en caso de que la aplicación utilice categorías para filtrar los eventos; y también se pueden agregar datos binarios a la entrada de un evento, si éste debe llevar asociada información adicional.
Además de obtener acceso a registros de eventos individuales y a sus entradas, la clase EventLog proporciona acceso a la colección de todos los registros de eventos. Los miembros static de EventLog pueden utilizarse para eliminar registros, obtener listas de registros, crear o eliminar un origen o determinar si un equipo ya contiene un origen determinado.
Hay tres registros de eventos predeterminados: Application, System y Security. Otras aplicaciones y servicios instalados, como Active Directory, pueden tener registros de eventos adicionales. Se puede usar EventLog para crear registros de eventos personalizados visibles desde el Visor de eventos del servidor. El método RegisterDisplayName se utiliza para mostrar en el Visor de eventos un nombre adaptado para el registro de eventos. El método ModifyOverflowPolicy, por su parte, se utiliza para configurar el comportamiento del registro de eventos cuando llegue a su tamaño máximo.
El registro de eventos consume espacio en disco, tiempo de procesador y otros recursos del sistema. Es importante registrar solamente información esencial. Se recomienda colocar llamadas del registro de eventos en una ruta de acceso de error, en lugar de en la ruta de acceso de código principal, para que no afecte negativamente al rendimiento.
Para obtener una lista con los valores de propiedad iniciales de una instancia de EventLog, vea el constructor EventLog.
Nota de la plataforma : Los registros de eventos no son compatibles en Windows 98 y Windows Millennium (Me).