Visor de eventos: qué es, cómo usarlo y qué errores revisar

El Visor de eventos es la herramienta de Windows que anota lo que pasa en el equipo: cada arranque y cada apagado, cada servicio que falla, cada actualización y cada inicio de sesión. Si un computador se reinicia solo, si un programa se cierra o si un servidor amanece lento, la explicación casi siempre está ahí. En esta guía verá qué es el Visor de eventos, cómo abrirlo, cómo leer un ID de evento, qué eventos de Windows conviene conocer, del Kernel-Power 41 al 4625, y cómo consultarlos con Get-WinEvent.

Para escribirla medimos un portátil con Windows 11 Pro en uso diario. Su registro Sistema guardaba 44.440 eventos de 21 días, es decir, unos 2.100 al día. Solo 85 eran errores, menos de 2 por cada 1.000, y ninguno era crítico. Además, casi la mitad de esos errores eran el mismo aviso de un componente de Windows, sin ninguna falla visible detrás. Por eso el Visor de eventos no se lee de arriba abajo: se filtra.

La guía sirve a dos lectores. Si usted usa el computador para trabajar y quiere saber por qué se apagó, le bastan los apartados de cómo abrir el visor, cómo leer un evento y el caso del reinicio. Si administra equipos o servidores, encontrará también los filtros en XML, las consultas con PowerShell y wevtutil, el tamaño de los registros y cómo pasar de revisar a mano a recibir alertas.

¿Qué es el Visor de eventos de Windows?

Primero, lo básico: el Visor de eventos es una consola de Windows que muestra los registros que escribe el servicio Registro de eventos. En inglés se llama Event Viewer, y su archivo es eventvwr.msc. Viene incluido en Windows 10, Windows 11 y Windows Server, así que no hay que instalar nada. Además, cada registro es un archivo .evtx guardado en %SystemRoot%\System32\winevt\Logs, el formato que Windows usa desde Vista.

Por su parte, un evento es un aviso que deja un componente del equipo: el propio Windows, un controlador, un servicio o un programa. Cada evento, además, trae la fecha, el nivel de gravedad, el origen que lo escribió, un número llamado ID de evento y una descripción. Juntos forman el historial del equipo, y por eso ese historial responde preguntas muy concretas:

Pregunta	Dónde se mira	ID de evento
¿Por qué se apagó o se reinició el equipo?	Registros de Windows → Sistema	41, 6008, 1074, 6005 y 6006
¿Hubo una pantalla azul?	Sistema	1001 (origen BugCheck) y 41
¿Qué programa se cerró solo?	Aplicación	1000 y 1002
¿Se instaló la actualización?	Sistema	19 si salió bien y 20 si falló
¿Qué servicio no arrancó o se detuvo?	Sistema	7000, 7009, 7031 y 7034
¿El disco da señales de falla?	Sistema	7, 11, 51, 153 y 157 (origen disk)
¿Quién intentó iniciar sesión?	Seguridad	4624 y 4625
¿Por qué se bloquea una cuenta?	Seguridad	4740

En el soporte técnico, el Visor de eventos es lo primero que se abre ante una falla que nadie vio. Además, es la base de cualquier sistema de monitoreo de Windows, como verá más adelante.

Cómo abrir el Visor de eventos

Hay varias formas de abrir el Visor de eventos, aunque todas llevan a la misma consola:

Forma	Pasos	Dónde funciona
Menú de Windows + X	Pulse Windows + X, o haga clic derecho en Inicio, y elija «Visor de eventos»	Windows 10 y 11
Ejecutar	Pulse Windows + R, escriba eventvwr.msc y pulse Enter	Todas las versiones
Búsqueda	Escriba «Visor de eventos» en el cuadro de búsqueda de Inicio	Windows 10 y 11
Línea de comandos	Escriba eventvwr en CMD o en PowerShell	Todas las versiones
Panel de control	«Herramientas de Windows» en Windows 11 o «Herramientas administrativas» en Windows 10	Windows 10 y 11
Administración de equipos	Clic derecho en Inicio → «Administración de equipos» → «Herramientas del sistema» → «Visor de eventos»	Windows 10, 11 y Server

Sin permisos de administrador el visor abre igual, pero no deja leer el registro Seguridad. Para verlo hay que abrir la consola como administrador o pertenecer al grupo «Lectores del registro de eventos». Ese grupo viene con Windows y da acceso de solo lectura a los registros, sin ningún otro privilegio, así que es la forma correcta de darle acceso a un técnico que solo necesita consultar.

Abrir el Visor de eventos de otro equipo

Primero, desde el panel Acciones, la opción «Conectarse a otro equipo…» abre los registros de un servidor o de otro PC de la red. También se puede indicar el nombre del equipo en la línea de comandos:

eventvwr SRV-ARCHIVOS

Para eso se necesitan permisos de administrador en el equipo remoto. Además, su firewall debe tener habilitado el grupo de reglas «Administración remota de registro de eventos». PowerShell también lo necesita para consultar en remoto, según su documentación.

Abrir un registro guardado

Si alguien le envía un archivo .evtx, ábralo con «Abrir registro guardado…» o directamente desde la línea de comandos. El archivo aparece en «Registros guardados», aparte de los del equipo, y se filtra igual que cualquier otro:

eventvwr /l:C:\Soporte\sistema.evtx

Las partes del Visor de eventos

La consola tiene tres paneles. Primero, a la izquierda, está el árbol de registros; luego, en el centro, la lista de eventos, con la vista previa del evento elegido debajo; a la derecha, el panel Acciones, con lo que se puede hacer en cada momento. El árbol se divide así:

Sección del árbol	Qué contiene
Vistas personalizadas	Filtros guardados. Trae uno de fábrica, «Eventos administrativos», que reúne los eventos críticos, los errores y las advertencias de los registros administrativos, sin importar su origen
Registros de Windows	Los cinco registros clásicos: Aplicación, Seguridad, Instalación, Sistema y Eventos reenviados
Registros de aplicaciones y servicios	Los registros propios de cada componente, como el Programador de tareas o PowerShell. El portátil medido mostraba 476 registros, de los que 391 estaban activos y 129 tenían eventos. Con «Mostrar registros analíticos y de depuración», en el menú Ver, aparecen cientos más: wevtutil contó 1.268 en total
Suscripciones	Las reglas para recibir en «Eventos reenviados» los eventos de otros equipos

Los registros de Windows, uno por uno

Casi todo el diagnóstico pasa por estos cinco registros. Además, la última columna es el tamaño máximo que traían de fábrica en el equipo medido, con Windows 11 Pro 26H2:

Registro	Qué guarda	Tamaño máximo
Aplicación	Los eventos de los programas: cierres inesperados, errores de bases de datos, avisos del antivirus	20.480 KB
Seguridad	La auditoría: inicios de sesión, bloqueos de cuentas, cambios de permisos. Solo lo leen los administradores y los «Lectores del registro de eventos»	No se lee sin permisos
Instalación	La instalación de actualizaciones y de componentes de Windows	1.028 KB
Sistema	Windows, sus servicios y sus controladores: arranques, apagados, discos, red y actualizaciones	20.480 KB
Eventos reenviados	Los eventos que llegan de otros equipos por suscripción	20.480 KB

Cómo leer un evento en el Visor de eventos

Al hacer clic en un evento, la parte de abajo muestra dos pestañas. «General» da el texto en español y los datos básicos; «Detalles», en cambio, muestra todo el contenido, en vista descriptiva o en XML. Estos son los campos que más se usan:

Campo	Qué dice	Ejemplo
Nombre de registro	En qué registro está	Sistema
Origen	Qué componente lo escribió	Kernel-Power
Id. de evento	El número del tipo de aviso	41
Nivel	La gravedad	Crítico
Registrado	La fecha y la hora	2 de octubre, 8:05
Usuario	La cuenta en cuyo nombre ocurrió	SYSTEM
Equipo	En qué máquina pasó	El nombre del PC
Categoría de la tarea y Palabras clave	Clasificaciones adicionales	(63) o Auditoría correcta

Los niveles de gravedad

Todos los eventos de Windows tienen un nivel, y PowerShell lo identifica con un número. Esta es la equivalencia, con lo que conviene hacer en cada caso:

Nivel	Número	Qué significa	Qué hacer
Crítico	1	Una falla grave, como un apagado inesperado	Revisarlo siempre
Error	2	Algo falló: un servicio, un programa o un controlador	Revisarlo si se repite o coincide con una falla
Advertencia	3	Un posible problema, como poco espacio o un tiempo de espera	Vigilarlo
Información	4	Operación normal: un servicio arrancó o una actualización se instaló	Usarlo como contexto
Detallado	5	Información de depuración	Solo para diagnósticos finos
Auditoría correcta y Error de auditoría	—	En el registro Seguridad, un acceso permitido o fallido	Depende de la política de auditoría

Por ejemplo, en el portátil medido, el 98,7 % de los eventos de Sistema eran de información, el 1,1 % advertencias y apenas el 0,19 % errores. Es decir, que el visor muestre errores es normal. Lo que importa es cuáles son, cuándo aparecen y si coinciden con una falla.

El ID de evento no basta: mire también el origen

Dos componentes distintos pueden usar el mismo número, así que un ID de evento siempre se lee junto con su origen. En el portátil medido, por ejemplo, el ID 20 lo escribían tres orígenes distintos, y solo uno, WindowsUpdateClient, avisaba de una actualización fallida. Del mismo modo, el ID 7 de esa máquina no hablaba de discos: venía del conmutador virtual de Hyper-V.

El caso más llamativo fue el ID 12. Lo escribían cuatro orígenes, pero uno de ellos, el servicio de energía UserModePowerService, aparecía 37.189 veces. Así, ese solo aviso informativo ocupaba el 84 % del registro Sistema, un dato que vuelve a salir al hablar del tamaño de los registros.

Las pestañas General y Detalles

La pestaña «General» basta casi siempre. La de «Detalles», sin embargo, muestra los campos internos del evento, y a veces ahí está la respuesta. Por ejemplo, el Kernel-Power 41 guarda en ellos el código de la pantalla azul, si la hubo, y la marca de tiempo del botón de encendido. En la vista XML esos datos aparecen como <Data Name="BugcheckCode">, la misma estructura que leen PowerShell y las herramientas de monitoreo.

Los eventos de Windows que conviene conocer

Windows tiene miles de tipos de eventos; de hecho, el portátil medido tenía 1.278 proveedores capaces de escribirlos. En la práctica, unas pocas docenas resuelven la mayoría de los casos. Por eso, las tablas siguientes reúnen solo los más útiles, con el texto que muestra Windows en español, leído del propio sistema. Los puntos suspensivos marcan los datos que cambian en cada evento.

Apagados, reinicios y pantallas azules

ID	Origen	Texto en el Visor de eventos	Qué significa
41	Kernel-Power	«Se reinició el sistema sin apagarlo limpiamente primero…»	Apagado sucio: corte de energía, bloqueo, botón de encendido o pantalla azul
6008	EventLog	«El cierre anterior del sistema a las … del … resultó inesperado.»	Confirma el apagado inesperado y da su hora
1074	User32	«El proceso … inició el … del equipo … en nombre del usuario … por el siguiente motivo: …»	Apagado o reinicio pedido por una persona, por Windows Update o por un programa
1076	User32	«El motivo proporcionado por el usuario … para el último apagado inesperado del equipo es el siguiente: …»	En Windows Server, la explicación que alguien escribió después del apagado
6005 y 6006	EventLog	«Se inició el servicio de Registro de eventos.» y «Se detuvo el servicio de Registro de eventos.»	Marcan cada arranque y cada apagado limpio
6009	EventLog	«Microsoft (R) Windows (R) …»	La versión de Windows con la que arrancó el equipo
12 y 13	Kernel-General	«El sistema operativo se inició a la hora del sistema …» y «… se está cerrando …»	Inicio y cierre del sistema, con la hora exacta
1001	BugCheck	«Se reinició el equipo después de una comprobación de errores. La comprobación de errores fue: …»	Hubo pantalla azul; trae el código y dónde quedó el volcado de memoria

Servicios, programas y actualizaciones

ID	Origen	Texto en el Visor de eventos	Qué significa
7000	Service Control Manager	«El servicio … no pudo iniciarse debido al siguiente error: …»	Un servicio no arrancó
7009	Service Control Manager	«Se agotó el tiempo de espera (… ms) para la conexión con el servicio …»	Un servicio tardó demasiado en responder al arrancar
7031	Service Control Manager	«El servicio … terminó inesperadamente. Esto se ha repetido … veces. Se realizará la siguiente acción correctora …»	Un servicio se cayó y Windows intentará recuperarlo
7034	Service Control Manager	«El servicio … se terminó de manera inesperada. Esto ha sucedido … veces.»	Un servicio se cayó, sin acción de recuperación
7036	Service Control Manager	«El servicio … entró en estado “…”.»	Un servicio se inició o se detuvo; sirve para fijar la hora
7040	Service Control Manager	«El tipo de inicio del servicio … se cambió de … a …»	Alguien, o algún programa, cambió la configuración de un servicio
1000	Application Error (registro Aplicación)	«Nombre de aplicación con errores: …»	Un programa se cerró por un error; el texto nombra el módulo culpable
1002	Application Hang (registro Aplicación)	«El programa … dejó de interactuar con Windows y se cerró.»	Un programa se congeló
19 y 20	WindowsUpdateClient	«Instalación correcta: …» y «Error de instalación: …»	Resultado de cada actualización
2004	Resource-Exhaustion-Detector	«Windows diagnosticó correctamente una condición de memoria virtual insuficiente…»	Falta de memoria; nombra los tres programas que más consumían

Un solo programa puede llenar el registro Aplicación. En el portátil medido, 535 de sus 560 errores eran el mismo ejecutable cerrándose una y otra vez durante seis días. Por eso, antes de alarmarse por la cantidad, conviene agrupar los errores por origen e ID de evento, como se explica en el apartado de PowerShell.

Discos y hardware

ID	Origen	Texto en el Visor de eventos	Qué significa
7	disk	«El dispositivo, …, tiene un bloque defectuoso.»	El disco tiene sectores dañados
11	disk	«El controlador detectó un error de controladora en …»	Falla en la comunicación con el disco: cable, controladora o disco
51	disk	«Error detectado en el dispositivo … durante una operación de paginación.»	Windows no pudo leer o escribir memoria virtual en el disco
153	disk	«Se reintentó la operación de E/S en la dirección de bloque lógico … del disco …»	El disco tardó en responder y Windows repitió la operación
157	disk	«El disco … se ha extraído de forma imprevista.»	Un disco desapareció sin desconectarse de forma segura
17, 19 y 47	WHEA-Logger	«Error de hardware corregido…»	El hardware detectó y corrigió un error; si se repite, anuncia una falla
18	WHEA-Logger	«Error de hardware irrecuperable…»	Error grave del procesador o del hardware

Un evento 7 o 51 del origen disk merece atención inmediata, porque es el disco avisando de que algo va mal. Antes de cualquier otra prueba, compruebe que existe una copia de seguridad reciente de ese equipo.

Inicios de sesión y cuentas

Estos eventos viven en el registro Seguridad, aunque el 104 lo anota Windows en Sistema:

ID	Texto en el Visor de eventos	Para qué sirve
4624	«Se inició sesión correctamente en una cuenta.»	Saber quién entró, cuándo y de qué forma
4625	«Error de una cuenta al iniciar sesión.»	Contraseñas equivocadas, cuentas inexistentes o bloqueadas
4740	«Se bloqueó una cuenta de usuario.»	Averiguar desde qué equipo se bloqueó una cuenta
4767	«Se desbloqueó una cuenta de usuario.»	Saber quién la desbloqueó y cuándo
1102	«Se borró el registro de auditoría.»	Alguien vació el registro Seguridad
104	«Se borró el archivo de registro …»	Alguien vació otro registro, como Sistema o Aplicación

Además, el campo «Tipo de inicio de sesión» de los eventos 4624 y 4625 dice cómo se intentó entrar. A continuación, los valores más frecuentes, según la documentación de Microsoft:

Tipo	Nombre	Qué significa
2	Interactivo	Alguien inició sesión en el propio equipo
3	Red	Acceso desde la red, como una carpeta compartida
7	Desbloqueo	Se desbloqueó la sesión del equipo
10	Remoto interactivo	Inicio de sesión por Escritorio remoto
11	Interactivo con caché	Inicio de sesión con credenciales guardadas, sin consultar al controlador de dominio

Por su parte, el campo de estado del 4625 dice por qué falló. Por ejemplo, 0xC000006A es una contraseña incorrecta; 0xC0000064, un usuario que no existe; 0xC0000234, una cuenta bloqueada; 0xC0000072, una cuenta deshabilitada, y 0xC0000193, una cuenta vencida. Además, en una red con dominio, los 4740 se buscan en los controladores de dominio. Su campo «Nombre de equipo del autor de la llamada» señala desde qué equipo llegó la contraseña equivocada, por ejemplo un celular o una unidad de red que conserva la clave anterior.

Los errores que puede ignorar

Algunos eventos aparecen en todos los equipos, pero no indican ningún problema. El más conocido es el 10016 de DistributedCOM, que avisa de un permiso que un componente de Windows no tiene. Microsoft explica que lo producen sus propios componentes y que se puede ignorar con seguridad, porque no afecta al funcionamiento y ocurre por diseño. Además, desaconseja cambiar los permisos para ocultarlo. En el portátil medido aparecía 261 veces, como advertencia.

Asimismo, en esa misma máquina, el error 10010 de DCOM, «El servidor … no se registró con DCOM dentro del tiempo de espera requerido», sumaba 41 de los 85 errores de Sistema, sin ninguna falla visible. Para no tenerlos delante, basta con excluirlos del filtro, como se explica más abajo.

Novedad de 2026: el evento 1801 y los certificados de Arranque seguro

En 2026 puede aparecer en Sistema el error 1801, de origen TPM-WMI. Su texto dice: «Los certificados de arranque seguro actualizados están disponibles en este dispositivo, pero aún no se han aplicado al firmware». Cuando el cambio se completa, aparece el 1808: «Este dispositivo ha actualizado la CA o las claves de arranque seguro».

Esto ocurre porque caducan los certificados de 2011 con los que funciona el Arranque seguro. Según Microsoft, primero venció el KEK CA 2011, el 24 de junio de 2026, y después el UEFI CA 2011, el 27 de junio. Por último, el Windows Production PCA 2011, que firma el cargador de arranque de Windows, vence el 19 de octubre de 2026. Los equipos sin los certificados de 2023 siguen arrancando y recibiendo actualizaciones, pero dejan de recibir las nuevas protecciones del arranque. En casa, la mayoría los recibe con Windows Update; en cambio, en una empresa conviene revisar en el Visor de eventos qué equipos siguen con el 1801.

Caso práctico: por qué se apagó o se reinició el equipo

Es la consulta más común en el Visor de eventos, y además se resuelve en cinco minutos:

1. Abra el Visor de eventos y vaya a «Registros de Windows» → «Sistema».
2. En el panel Acciones, elija «Filtrar registro actual…».
3. En el campo de los ID escriba 41,1074,6005,6006,6008 y acepte.
4. Luego, lea los eventos en orden, de abajo arriba, y busque la pareja que rodea el momento del problema.
5. Si hay un 41, ábralo y mire la pestaña «Detalles»: ahí está la causa probable.

Esta tabla resume cómo interpretar lo que encuentre:

Lo que encuentra	Qué significa	Qué hacer
Un 6006 y luego un 6005, con un 1074 antes	Apagado o reinicio normal; el 1074 dice quién lo pidió	Nada, salvo que el motivo sorprenda
Un 1074 de TrustedInstaller.exe	Reinicio de Windows Update	Revisar las horas activas o la política de reinicios
Un 41 con BugcheckCode distinto de 0	Pantalla azul	Convertir el código a hexadecimal y buscar el 1001
Un 41 con PowerButtonTimestamp distinto de 0	Alguien mantuvo pulsado el botón de encendido	Averiguar por qué el equipo no respondía
Un 41 con todo en 0, junto a un 6008	Corte de energía o bloqueo total	Revisar la fuente, la batería, la temperatura y la memoria
Un 41 con todo en 0 y un 46 de volmgr	Windows no pudo escribir el volcado de memoria	Revisar la configuración del archivo de paginación

En el portátil medido, por ejemplo, los 8 arranques de tres semanas se explicaban solos con el 1074. Hubo cinco apagados desde el menú Inicio, dos reinicios de Windows Update y uno ordenado con shutdown.exe. En cambio, no había ni un 41 ni un 6008, así que no hubo apagones ni bloqueos. La misma consulta, en PowerShell, cabe en una línea:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 41, 1074, 6005, 6006, 6008 } -MaxEvents 30 | Format-Table TimeCreated, Id, ProviderName -AutoSize

El error Kernel-Power 41, en detalle

El Kernel-Power 41 es el evento más buscado del Visor de eventos y también el más malentendido. No es la causa del problema: es el aviso de que Windows no pudo apagarse bien. De hecho, Windows lo escribe en el arranque siguiente, cuando comprueba que el apagado anterior no fue limpio. Su texto en español es este: «Se reinició el sistema sin apagarlo limpiamente primero. Este error puede producirse si el sistema dejó de responder, se bloqueó o se interrumpió el suministro eléctrico de forma inesperada».

Por eso, la guía de Microsoft sobre el evento 41 distingue tres escenarios, según los datos de la pestaña «Detalles»:

• BugcheckCode distinto de 0. Hubo una pantalla azul. El código viene en decimal, así que hay que pasarlo a hexadecimal: 159, por ejemplo, es 0x0000009F.
• PowerButtonTimestamp distinto de 0. Alguien apagó el equipo manteniendo pulsado el botón de encendido, normalmente porque no respondía.
• Todo en 0. El equipo no alcanzó a escribir nada, así que suele indicar un corte de energía, una batería agotada, una fuente que no da suficiente potencia o un bloqueo total del equipo.

Para el tercer caso, Microsoft da una prueba sencilla: si el equipo parece colgado, pulse Bloq Mayús. Si la luz del teclado no cambia, el equipo está bloqueado de verdad. Además, recomienda desactivar el overclocking, revisar la memoria, comprobar que la fuente de poder alcanza para todo lo instalado y vigilar la temperatura. Si los cortes de luz son la causa, propone una UPS. Por último, en las máquinas virtuales de Hyper-V hay un caso más: el anfitrión puede reiniciar una máquina que dejó de dar señales de vida.

Leer los datos del Kernel-Power 41 con PowerShell

Para ver esos dos campos sin abrir evento por evento, esta consulta de PowerShell los extrae de los últimos cinco Kernel-Power 41:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-Kernel-Power'; Id = 41 } -MaxEvents 5 |
    ForEach-Object {
        $datos = ([xml]$_.ToXml()).Event.EventData.Data
        [pscustomobject]@{
            Fecha                = $_.TimeCreated
            BugcheckCode         = ($datos | Where-Object Name -eq 'BugcheckCode').'#text'
            PowerButtonTimestamp = ($datos | Where-Object Name -eq 'PowerButtonTimestamp').'#text'
        }
    }

Y para pasar el código a hexadecimal, también en PowerShell:

'0x{0:X8}' -f 159

Cómo filtrar y buscar en el Visor de eventos

«Filtrar registro actual…» es la herramienta más útil del Visor de eventos. Permite elegir el intervalo de fechas, el nivel del evento, los orígenes y también los ID de evento. Este último campo acepta listas, intervalos y exclusiones. El propio Windows lo explica así: «Para incluir o excluir los id. de evento, escriba números o intervalos de id. separados por comas. Para excluir criterios, antecédalos con un signo de menos. Ej: 1,3,5-99,-76».

Por ejemplo, con 41,1074,6005,6006,6008 ve solo los apagados y arranques. Con el nivel Error marcado y -10016,-10010 en el campo de ID, en cambio, ve los errores sin el ruido de DCOM. Por último, «Buscar…» encuentra un texto dentro de los eventos que estén a la vista.

Vistas personalizadas: los filtros que se guardan

Un filtro se aplica al registro que está abierto. Una vista personalizada, en cambio, queda guardada en el árbol y puede abarcar varios registros a la vez. Primero se crea con «Crear vista personalizada…» o con «Guardar filtro en vista personalizada…». Después, «Exportar vista personalizada…» la guarda en un archivo para que la use otro técnico con «Importar vista personalizada». Así, todo el equipo de soporte mira lo mismo.

Filtros en XML para consultas más finas

La pestaña XML del filtro muestra la consulta que arma el Visor de eventos, y además se puede editar a mano. Esta, por ejemplo, reúne los apagados y los arranques:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[(EventID=41 or EventID=1074 or EventID=6005 or EventID=6006 or EventID=6008)]]</Select>
  </Query>
</QueryList>

Además, el XML permite algo que el formulario no tiene: la etiqueta Suppress, que quita de la vista lo que no interesa. Por ejemplo, esta consulta muestra los críticos y los errores de Sistema, sin los dos avisos de DCOM:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">*[System[(Level=1 or Level=2)]]</Select>
    <Suppress Path="System">*[System[(EventID=10016 or EventID=10010)]]</Suppress>
  </Query>
</QueryList>

Por último, ambas consultas sirven tal cual en PowerShell, con el parámetro -FilterXml de Get-WinEvent.

Exportar eventos del Visor de eventos y enviarlos al soporte

Cuando un técnico pide «los registros», lo más útil es enviarle el archivo .evtx, no una captura de pantalla. Para eso está «Guardar todos los eventos como…», que guarda el registro o la vista filtrada en .evtx, que conserva todo, o en formatos de texto como .csv. Si el archivo se va a abrir en otro equipo, conviene marcar «Mostrar información para estos idiomas», porque así viajan con él los textos de cada evento. Para un evento suelto basta con «Copiar detalles como texto».

Desde la línea de comandos, wevtutil hace lo mismo. Así, la primera orden exporta el registro Sistema completo, y la segunda, solo los últimos siete días. Si el archivo ya existe, wevtutil no lo sobrescribe y responde «Este archivo ya existe», salvo que se añada /ow:true:

wevtutil epl System C:\Soporte\sistema.evtx
wevtutil epl System C:\Soporte\sistema-7-dias.evtx /q:"*[System[TimeCreated[timediff(@SystemTime) <= 604800000]]]"

Un consejo importante: no vacíe un registro para «limpiar» los errores. Borrar no arregla nada; en cambio, destruye la evidencia y deja su propia huella, el evento 104 o el 1102. Si de verdad hay que vaciarlo, guarde antes una copia con la opción /bu, por ejemplo wevtutil cl Application /bu:C:\Soporte\aplicacion.evtx. Y si el técnico lo atiende por soporte remoto, el .evtx le llega completo, con todos sus campos.

El Visor de eventos desde la línea de comandos: Get-WinEvent y wevtutil

Todo lo que hace la consola se puede hacer también en PowerShell, con dos ventajas: se automatiza y funciona contra muchos equipos a la vez. El comando moderno es Get-WinEvent. El antiguo, Get-EventLog, solo lee los registros clásicos, y Microsoft advierte que usa una API de Win32 obsoleta, que sus resultados pueden no ser exactos y que debe usarse Get-WinEvent en su lugar. Todos los parámetros están en la documentación de Microsoft.

Las consultas básicas con Get-WinEvent

Primero, los diez registros con más eventos del equipo, con su tamaño máximo:

Get-WinEvent -ListLog * | Where-Object RecordCount -gt 0 | Sort-Object RecordCount -Descending | Select-Object -First 10 LogName, RecordCount, MaximumSizeInBytes

Luego, los críticos y los errores de Sistema de la última semana:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 1, 2; StartTime = (Get-Date).AddDays(-7) }

Para saber qué se repite, conviene agrupar los errores por origen y por ID de evento. Es la consulta que reveló el ruido de DCOM en el portátil medido:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 2 } | Group-Object ProviderName, Id -NoElement | Sort-Object Count -Descending | Select-Object -First 10

Para dejar fuera el ruido existe la clave SuppressHashFilter. Pero cuidado: solo funciona en PowerShell 7. En Windows PowerShell 5.1, la misma consulta respondió en nuestra prueba «No se encontraron eventos que coincidan con los criterios de selección especificados», sin avisar de que esa clave no existe en esa versión. En PowerShell 7, en cambio, devolvió 44 errores de los 85:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 2; SuppressHashFilter = @{ Id = 10016, 10010 } }

Por último, cada proveedor lleva dentro el texto de sus eventos, en el idioma del equipo. Esta orden, por ejemplo, muestra la descripción oficial del Kernel-Power 41:

(Get-WinEvent -ListProvider Microsoft-Windows-Kernel-Power).Events | Where-Object Id -eq 41 | Select-Object -Last 1 -ExpandProperty Description

Las claves de -FilterHashtable que más se usan son estas:

Clave	Qué filtra	Ejemplo
LogName	El registro	'System'
ProviderName	El origen	'Microsoft-Windows-Kernel-Power'
Id	Uno o varios ID de evento	41, 6008
Level	El nivel: 1 crítico, 2 error, 3 advertencia, 4 información, 5 detallado	1, 2
StartTime y EndTime	El intervalo de fechas	(Get-Date).AddDays(-1)
Data	Un dato del cuerpo del evento	'svchost.exe'
SuppressHashFilter	Lo que se excluye; solo en PowerShell 7	@{ Id = 10016 }

Consultar otro equipo con Get-WinEvent

El parámetro -ComputerName lee los eventos de otro equipo, uno por consulta. Según Microsoft, no necesita la comunicación remota de PowerShell, pero sí que el firewall del equipo remoto permita el acceso al servicio de registro de eventos:

Get-WinEvent -ComputerName SRV-ARCHIVOS -FilterHashtable @{ LogName = 'System'; Level = 1, 2; StartTime = (Get-Date).AddDays(-1) }

Para revisar varios servidores, basta con un bucle. Este busca apagados inesperados en tres equipos:

foreach ($equipo in 'SRV-ARCHIVOS', 'SRV-ERP', 'SRV-DC01') {
    Get-WinEvent -ComputerName $equipo -FilterHashtable @{ LogName = 'System'; Id = 41, 6008 } -MaxEvents 5 -ErrorAction SilentlyContinue |
        Select-Object @{ n = 'Equipo'; e = { $equipo } }, TimeCreated, Id
}

wevtutil, para CMD y tareas programadas

wevtutil viene con Windows y funciona en CMD, en archivos por lotes y en tareas programadas. Sus órdenes principales, según la documentación de wevtutil, son estas:

Orden	Qué hace	Ejemplo
el	Lista todos los registros	wevtutil el
gl	Muestra la configuración de un registro	wevtutil gl System
qe	Consulta eventos	wevtutil qe System /c:5 /rd:true /f:text
epl	Exporta a .evtx	wevtutil epl System C:\Soporte\sistema.evtx
gli	Muestra el estado de un registro: tamaño, número de eventos y si está lleno	wevtutil gli System
sl	Cambia la configuración, por ejemplo el tamaño	wevtutil sl System /ms:314572800
cl	Vacía un registro, con copia previa si se indica	wevtutil cl Application /bu:C:\Soporte\aplicacion.evtx

Las consultas de qe aceptan el mismo XPath que el Visor de eventos. Esta, por ejemplo, muestra los últimos veinte críticos y errores de Sistema, del más reciente al más antiguo:

wevtutil qe System /q:"*[System[(Level=1 or Level=2)]]" /c:20 /rd:true /f:text

Cuántos días de historia guarda el Visor de eventos

Los registros no crecen sin límite. En el equipo medido, Sistema y Aplicación tenían un máximo de 20.480 KB, es decir, 20 MB, en modo circular: al llenarse, cada evento nuevo borra el más antiguo. Con 2.096 eventos al día y unos 472 bytes por evento, esos 20 MB guardaban 21 días de Sistema. El registro Aplicación, con menos eventos pero más largos, guardaba 16 días y medio.

Además, aquí vuelve el ID 12 de UserModePowerService, que ocupaba el 84 % del registro Sistema. Sin él, y con el mismo tamaño medio por evento, los mismos 20 MB habrían guardado unos 130 días. Por eso, antes de agrandar un registro, conviene mirar qué lo llena. En general, la cuenta es simple: los días de historia equivalen al tamaño máximo dividido entre los eventos de cada día y lo que ocupa cada uno. Con el tamaño medio del portátil medido, el resultado es este:

Eventos al día en Sistema	Días que caben en 20 MB
2.000	22
10.000	4,4
20.000	2,2
50.000	menos de 1

Cómo ampliar un registro del Visor de eventos

Sin embargo, en un servidor con mucho movimiento, 20 MB pueden ser apenas un par de días. Así, cuando alguien pregunta el lunes qué pasó el viernes, el registro puede no tenerlo ya. Para guardar 30 días a 20.000 eventos diarios hacen falta unos 270 MB. Con 300 MB caben 33 días, y se configura con esta orden, como administrador:

wevtutil sl System /ms:314572800

El valor va en bytes. Además, según Microsoft, el mínimo es 1.048.576 bytes y el tamaño siempre es múltiplo de 64 KB. En la ventana «Propiedades» del registro se elige además qué pasa al llenarse: «Sobrescribir eventos si fuera necesario (eventos anteriores primero)», «Archivar el registro cuando esté lleno; no sobrescribir eventos» o «No sobrescribir eventos (vaciar registros manualmente)». En una empresa, lo práctico es fijarlo por directiva de grupo, en «Configuración del equipo» → «Plantillas administrativas» → «Componentes de Windows» → «Servicio Registro de eventos», con la directiva «Especificar el tamaño máximo del archivo de registro (KB)» de cada registro.

El Monitor de confiabilidad: la vista sencilla

Si el Visor de eventos le parece demasiado técnico, Windows trae una vista más amable: el Monitor de confiabilidad. Se abre con perfmon /rel o, también, desde el Panel de control, en «Seguridad y mantenimiento» → «Ver historial de confiabilidad». Muestra una línea de tiempo, día por día, con los programas que fallaron, los errores de Windows, las advertencias y las instalaciones de software y actualizaciones.

Según Microsoft, empieza a reunir datos desde la instalación del sistema, y además lo pueden usar los usuarios sin permisos de administrador. Por eso, para una persona que no es de sistemas, es la mejor forma de responder «¿desde cuándo falla esto?». Después, con la fecha en la mano, el detalle se busca en el Visor de eventos.

Del Visor de eventos al monitoreo: alertas que llegan solas

Sin embargo, el Visor de eventos tiene un límite evidente: alguien tiene que abrirlo. Y con los registros circulares, si nadie lo abre a tiempo, la evidencia desaparece. El problema crece con el número de equipos. Por ejemplo, pensemos en la empresa de 120 equipos de nuestras guías de Zabbix y PRTG. Si cada equipo anotara como el portátil medido, serían unos 251.500 eventos al día solo en Sistema, con unos 480 errores, o 250 sin el ruido de DCOM. Y revisar a mano el visor de cada equipo cinco minutos por semana costaría 10 horas semanales.

Nadie lee 250.000 eventos de Windows al día. Por eso se cambia la pregunta: en lugar de leer todo, se eligen los pocos ID de evento que importan y se pide una alerta cuando aparecen. Hay tres formas de hacerlo.

Adjuntar una tarea a un evento

Al hacer clic derecho en un evento aparece «Adjuntar tarea a este evento…». La opción crea una tarea en el Programador de tareas, que luego se ejecuta cada vez que se repite ese evento. Sin embargo, de sus tres acciones, solo «Iniciar un programa» funciona: «Enviar un correo electrónico (desusado)» y «Mostrar un mensaje (desusado)» quedaron obsoletas. De hecho, Microsoft retiró el envío de correo desde Windows 8 y Windows Server 2012. Sirve para un equipo, pero no escala a cien.

Suscripciones: reunir los eventos de varios equipos

Por otra parte, Windows puede reenviar eventos a un equipo recopilador, que los guarda en «Eventos reenviados». En el recopilador se prepara el servicio con wecutil qc /q; en los equipos de origen, con winrm qc -q, porque el reenvío viaja por WinRM. Además, en un dominio, lo práctico es que los equipos de origen se suscriban solos mediante una directiva de grupo. Con eso se tienen los eventos en un solo lugar, aunque todavía falta quien los mire y quien avise.

Herramientas de monitoreo

Por eso, la solución completa es un sistema de monitoreo que lea los registros, aplique las reglas y avise. Zabbix lo hace con su elemento eventlog[]. Por ejemplo, eventlog[System,,"Warning|Error"] recoge las advertencias y los errores de Sistema, y eventlog[System,,,,^(41|6008)$] solo los apagados inesperados. Según su documentación, el elemento tiene que configurarse como chequeo activo y no puede leer «Eventos reenviados».

PRTG, por su parte, tiene el sensor «Registro de eventos (Windows API)». Paessler advierte en su manual que su impacto en el rendimiento es muy alto y recomienda no pasar de 50 por sonda. Encima de cualquiera de los dos, Grafana pone los tableros. La tabla compara las tres opciones:

Opción	Para qué sirve	Su límite
Tarea adjunta a un evento	Ejecutar un programa cuando aparece un evento en un equipo	Equipo por equipo y sin correo integrado
Suscripciones	Reunir en un recopilador los eventos de muchos equipos	Junta los datos, pero no avisa ni grafica
Sistema de monitoreo	Leer, filtrar, alertar e informar en un solo lugar	Hay que diseñar las reglas y mantenerlo

Qué eventos de Windows vigilar en un servidor

Esta es una buena lista para empezar. Junto con el monitoreo de servidores por CPU, memoria y disco, cubre la mayoría de las fallas de un servidor Windows:

ID de evento	Por qué vigilarlo	Alerta
41 y 6008	El servidor se apagó sin aviso	Alta
1001 (BugCheck)	Hubo una pantalla azul	Alta
7031 y 7034	Un servicio se cayó	Alta si es un servicio del negocio
7, 11, 51 y 153 (disk)	El disco da señales de falla	Alta
18 (WHEA-Logger)	Error de hardware irrecuperable	Alta
2004	Falta de memoria	Media
20 (WindowsUpdateClient)	Una actualización falló	Media
4740	Se bloqueó una cuenta, en los controladores de dominio	Media
104 y 1102	Alguien vació un registro	Alta
1801 (TPM-WMI)	Certificados de Arranque seguro pendientes	Media

Lo que el Visor de eventos no hace

Conocer sus límites evita conclusiones equivocadas:

• No es un antivirus. Registra los eventos de Windows y de los programas, pero no detecta amenazas por sí mismo.
• No relaciona equipos. Cada visor muestra una máquina. Cruzar eventos de muchos equipos para encontrar un patrón es otro tipo de herramienta.
• No avisa solo. Salvo que se le adjunte una tarea, nadie se entera de un evento hasta que abre la consola.
• No guarda la historia para siempre. Con 20 MB y un registro circular, lo más antiguo se pierde en días o semanas.
• No registra lo que no se auditó. Saber quién borró un archivo exige activar antes la auditoría de esa carpeta. Microsoft explica que el evento 4663 solo se genera si la lista de auditoría del objeto lo pide.

Cuidado con el falso soporte técnico y el Visor de eventos

Los estafadores del falso soporte técnico usan el Visor de eventos para asustar. Primero llaman haciéndose pasar por un fabricante; luego piden abrirlo y señalan los errores como «prueba» de una infección. De hecho, en 2012, la Comisión Federal de Comercio de Estados Unidos frenó seis operaciones de este tipo. Según su comunicado, llevaban a la víctima a «una zona de utilidades del equipo», y la imagen de ejemplo que lo acompañaba era el Visor de eventos.

Como ya vio, todo equipo sano tiene errores en el visor. Además, Microsoft aclara que no hace llamadas no solicitadas para ofrecer soporte técnico, y que sus mensajes de error y advertencia nunca incluyen un número de teléfono. Si alguien lo llama para mostrarle el Visor de eventos, cuelgue. En nuestra guía de soporte remoto encontrará más datos sobre este fraude.

El Visor de eventos en Windows Server, Mac y Linux

En Windows Server el Visor de eventos es el mismo, y el Administrador del servidor muestra además los eventos de cada rol. Los controladores de dominio, por ejemplo, añaden registros propios en «Registros de aplicaciones y servicios». En una instalación sin escritorio, como Server Core, se consulta en remoto o con PowerShell. Y tras un apagado inesperado, el Rastreador de eventos de apagado pide al administrador un motivo, que queda como evento 1076.

Mac y Linux no tienen un Visor de eventos con ese nombre, pero sí su equivalente. En macOS es la aplicación Consola. Por su parte, en Linux está el diario de systemd: journalctl -p err -b muestra los errores desde el último arranque, y journalctl --list-boots, la lista de arranques. Si trabaja con servidores Linux, nuestros comandos básicos de Linux son un buen punto de partida.

Preguntas frecuentes sobre el Visor de eventos

¿Es normal tener errores en el Visor de eventos?

Sí. Por ejemplo, en el portátil medido, sano y en uso diario, hubo 85 errores en tres semanas, y casi la mitad eran ruido conocido. Un error preocupa cuando se repite, cuando coincide con una falla o cuando pertenece a la lista de eventos críticos de esta guía.

¿Puedo borrar los registros del Visor de eventos?

Se puede, con «Vaciar registro…», pero no arregla nada. Además, se pierde la evidencia para diagnosticar y queda la huella del borrado: el evento 104, o el 1102 en Seguridad.

¿Dónde se guardan los registros?

Los eventos de Windows se guardan en archivos .evtx dentro de %SystemRoot%\System32\winevt\Logs, uno por registro. Para compartirlos, lo correcto es exportarlos desde el visor o con wevtutil epl.

¿Cómo veo cuándo se encendió y se apagó el computador?

Filtre Sistema por los ID 6005, el arranque, y 6006, el apagado limpio. Si añade el 1074, verá quién pidió cada apagado; con el 41 y el 6008, los inesperados.

¿Por qué no puedo abrir el registro Seguridad?

Porque solo lo leen los administradores y los miembros del grupo «Lectores del registro de eventos». Abra el visor como administrador o pida que lo agreguen a ese grupo.

¿El Visor de eventos sirve igual en Windows 10 y en Windows 11?

Sí. La consola, los registros y los ID de evento son los mismos. Solo cambia algún camino para llegar a él, como «Herramientas de Windows» en lugar de «Herramientas administrativas».

Cómo lo aborda KHARONTE

En KHARONTE, los eventos de Windows no esperan a que alguien abra la consola. Dentro de nuestro servicio de monitoreo de infraestructura TI vigilamos servidores, servicios y disponibilidad, configuramos alertas ante fallos y degradación, y entregamos reportes periódicos de disponibilidad y de atención de tickets. Las reglas parten de listas como la de esta guía, ajustadas a cada cliente.

Además, cada alerta entra como caso en nuestra mesa de ayuda TI, con su registro, su responsable y su seguimiento hasta el cierre. Si busca soporte técnico para empresas o servicios administrados de TI que reúnan el monitoreo, el soporte y la administración de sus plataformas, conozca el resto de nuestros servicios de TI para empresas.