Cómo interpretar logs de Event Viewer en Windows 11

W11 » Seguridad en Windows 11 » Cómo interpretar logs de Event Viewer en Windows 11

Si trabajas con Windows 11, tarde o temprano te toca pelearte con el Visor de eventos. Y no, no es solo una lista aburrida de mensajes: ahí se esconde casi todo lo que le pasa al sistema, desde un simple aviso de batería baja hasta errores críticos de seguridad o de Microsoft Defender para punto de conexión (MDE).

La buena noticia es que, si sabes leer esos registros, puedes diagnosticar problemas, seguir pistas de seguridad y entender qué hace Windows por debajo de la interfaz bonita. La mala: sin guía, Event Viewer puede parecer un bosque interminable de IDs, códigos de error y textos crípticos. Vamos a desgranarlo paso a paso, con ejemplos reales y muchos trucos prácticos.

Qué es el Visor de eventos y qué tipos de registros existen

El Visor de eventos centraliza todos los sucesos importantes del sistema en una serie de registros organizados por categorías. No solo sirve en Windows 11 de escritorio: la misma lógica aplica a Windows Server 2016 y 2019, y en general a casi todo el ecosistema moderno de Microsoft.

Windows guarda estos sucesos en archivos de registro con extensión .evtx dentro de la carpeta %SystemRoot%\System32\winevt\Logs. En el Registro de Windows se almacena el nombre del log y la ruta exacta de cada fichero.

Los registros más habituales que verás son estos:

• Registro de aplicación: recoge eventos generados por programas instalados. Cada desarrollador decide qué información envía aquí (errores, avisos, información).
• Registro de seguridad: registra inicios de sesión correctos y fallidos, cambios de permisos, uso de recursos sensibles (crear, abrir o borrar archivos, etc.). Solo un administrador puede activar y configurar qué se registra.
• Registro del sistema: muestra eventos de los propios componentes de Windows (controladores, servicios base, kernel…). Es clave para entender fallos al arrancar servicios o problemas de hardware.
• Registro del servicio de directorio: disponible solo en controladores de dominio, con eventos de Active Directory (agregar Windows 11 a un dominio).
• Registro del servidor DNS: almacena sucesos de resolución de nombres (DNS) en servidores que prestan ese servicio.
• Registro del servicio de replicación de archivos: visible en controladores de dominio, muestra la replicación entre servidores.

Cada una de esas categorías agrupa múltiples fuentes de eventos (orígenes). En Windows 11, además, encontrarás secciones específicas dentro de “Registros de aplicaciones y servicios” para componentes como Microsoft Defender para punto de conexión, telemetría, System Guard, etc.

Cómo abrir el Visor de eventos en Windows 11 y orientarse

Para llegar al Visor de eventos desde la interfaz moderna de Windows 11, puedes seguir un camino bastante cómodo a través de Herramientas de Windows y el Panel de control clásico.

En el menú Inicio, cambia la vista para ver las aplicaciones ordenadas alfabéticamente y desplázate hasta Herramientas de Windows. Allí encontrarás, entre otras, la entrada para abrir el Panel de control, que sigue siendo la puerta de acceso a muchas opciones avanzadas.

Dentro del Panel de control, entra en Sistema y seguridad. Al final de esa lista verás el acceso al Visor de eventos. También puedes escribir “Visor de eventos” en el cuadro de búsqueda del menú Inicio y abrirlo directamente, que suele ser más rápido.

Cuando se abre Event Viewer, la ventana se divide en tres paneles bien diferenciados: a la izquierda, un árbol de navegación con categorías; en el centro, la lista de sucesos; a la derecha, las acciones disponibles sobre el registro o el evento seleccionado.

Dentro del árbol, la rama “Registros de Windows” incluye los clásicos (Aplicación, Seguridad, Instalación, Sistema, etc.) y en “Registros de aplicaciones y servicios” vas a encontrar registros específicos de productos como Microsoft Defender para punto de conexión o el cliente de telemetría de Windows.

Interpretar los campos básicos de un evento

Cada entrada de la lista representa un suceso concreto, y siempre incluye varios campos clave que debes acostumbrarte a mirar:

• Fecha y hora: cuándo ocurrió el evento.
• Origen: el componente que lo generó (por ejemplo, “Microsoft-Windows-Security-Auditing”, “Sense”, “DiagTrack”, “MsSecFlt”, etc.).
• Id. de evento: número que identifica el tipo de suceso (4625, 100, 401, etc.).
• Nivel: información, advertencia, error, crítico, auditoría correcta o errónea.
• Equipo: normalmente el nombre del PC local.

Si haces doble clic sobre un evento, se abre una ventana con más detalle. Ahí verás una descripción extensa en texto plano y, a menudo, un enlace a información online de Microsoft para ese ID concreto. Ese campo de descripción, junto con el identificador, es lo que de verdad te ayuda a interpretar qué ha pasado.

Por ejemplo, en el registro de seguridad de Windows 11, el evento con ID 4625 indica un intento de autenticación fallido. Ese número concreto es tan usado que se suele memorizar para localizar ataques de fuerza bruta o credenciales incorrectas.

La idea es que la combinación de origen + Id. de evento + texto descriptivo te da el contexto completo: quién ha generado el evento, qué tipo de suceso es y qué datos específicos aporta.

Cómo filtrar eventos por ID, origen o periodo de tiempo

Cuando estás investigando un problema concreto no tiene sentido leer toda la lista de sucesos a ojo. El truco está en usar el filtro de eventos y las vistas personalizadas del propio Visor.

Para crear un filtro global, selecciona en el panel izquierdo la entrada “Visor de eventos (local)”. A partir de ahí, en el panel derecho, utiliza las opciones de crear vista personalizada o aplicar filtros.

Al abrir la ventana de filtro, lo primero que eliges es el intervalo de tiempo a analizar. Puedes escoger periodos predefinidos o configurar un intervalo personalizado con fecha y hora de inicio y fin, ideal cuando conoces el rango aproximado en el que empezó el problema.

Después puedes acotar por nivel del evento (críticos, errores, advertencias, información…). Si no marcas nada, se incluyen todos los niveles. Luego llega una parte muy útil: decidir si filtras por registro (Aplicación, Sistema, Seguridad, etc.) o por origen (por ejemplo, el spooler de impresión, el servicio “Sense” de Defender para punto de conexión, etc.).

Cuando eliges filtrar “Por origen”, el campo “Por registro” se ajusta de forma automática al registro correcto, lo que ayuda a no perderte entre tantas categorías. Esto resulta especialmente práctico cuando sabes el componente que da guerra pero no recuerdas en qué log escribe.

En el cuadro dedicado a identificadores de evento puedes hilar muy fino:

• Un único ID: escribes solo el número, por ejemplo 4625.
• Varios IDs: los separas por comas, como 4624, 4625.
• Rangos: indicas primero y último, separados por un guion, por ejemplo 4650-4655.
• Combinaciones: mezclas individuales y rangos, del estilo 4698, 4700-4702, 4650-4655.
• Excluir uno concreto de un rango: añadiendo un guion delante, por ejemplo 4698-4702, -4699.

Además, puedes limitar la visualización a ciertas categorías de tarea, usar palabras clave predeterminadas y, si te interesa, mostrar solo eventos relacionados con usuarios o equipos concretos (lista separada por comas).

Cuando hayas ajustado el filtro, puedes guardarlo como vista personalizada. Al hacerlo, eliges un nombre (por ejemplo, “Errores de inicio de sesión”), una descripción opcional y la carpeta donde se guardará, normalmente dentro de “Vistas personalizadas”. También decides si esa vista será visible solo para tu usuario o para todos los usuarios del equipo.

Más adelante, bastará con hacer clic en el nombre de la vista personalizada para recuperar los eventos filtrados con esos criterios. La lista se mantiene siempre actualizada: si se generan nuevos eventos que cumplan el filtro, aparecen automáticamente cada vez que abras la vista.

Mover los archivos de log del Visor de eventos a otra ubicación

En servidores (y también en algunos equipos de escritorio muy usados) es habitual que los logs empiecen a crecer y ocupen demasiado espacio en la unidad del sistema. En Windows Server 2016 y 2019, y por extensión en entornos avanzados, tiene mucho sentido mover esos archivos .evtx a otra ruta, siempre que se respeten permisos y configuración.

Por defecto, todos los registros del Visor se almacenan como .evtx bajo %SystemRoot%\System32\winevt\Logs. El propio Registro de Windows guarda, para cada log, la ruta y nombre de fichero. Si cambias esa ruta ahí o desde el propio Visor, Windows empezará a escribir en la nueva ubicación.

El procedimiento recomendado consiste en crear primero una carpeta específica para los registros, por ejemplo C:\EventLogs, y después replicar los permisos adecuados:

• Crea la carpeta en la unidad de destino.
• Abre sus propiedades, pestaña Seguridad, y entra en Opciones avanzadas.
• Cambia el propietario de la carpeta a SYSTEM.
• Deshabilita la herencia y elige “Convertir permisos heredados en permisos explícitos”.
• Ajusta los permisos avanzados para que coincidan con los de %SystemRoot%\System32\winevt\Logs, asegurando que los usuarios autenticados solo tengan lectura sobre la carpeta y sus subcarpetas.

Hecho esto, puedes usar el propio Visor para mover el log de un registro concreto: botón derecho sobre el nombre del registro (por ejemplo, “Sistema”) → Propiedades → en “Ruta de acceso del registro”, cambia la ruta a algo como C:\EventLogs\System.evtx, manteniendo el mismo nombre de archivo al final.

Conviene a continuación pulsar en “Borrar registro” y elegir “Guardar y borrar”, de forma que guardas una copia del log antiguo y comienzas desde cero en la nueva ruta. Tras aplicar y aceptar, puedes comprobar el cambio en el Registro, por ejemplo bajo:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System

Si prefieres automatizar el proceso, puedes recurrir a PowerShell. Un script típico para mover el log de Seguridad a C:\Logs podría:

• Leer los permisos ACL originales de %SystemRoot%\system32\winevt\Logs.
• Aplicar esos mismos ACL a la nueva carpeta de destino, limpiando directivas de acceso central si procede.
• Configurar como propietario a SYSTEM.
• Añadir en el Registro valores como AutoBackupLogFiles y Flags en la clave HKLM:\SYSTEM\CurrentControlSet\Services\EventLog\Security.
• Actualizar el valor File con la nueva ruta C:\Logs\Security.evtx.

Así mantienes permisos coherentes y copias de seguridad automáticas del log, algo crucial en entornos auditados.

Eventos de Microsoft Defender para punto de conexión (MDE) y cómo interpretarlos

Si usas Microsoft Defender para punto de conexión en Windows 11 o en equipos cliente/servidor, verás una enorme cantidad de eventos relacionados con el servicio “Sense” y otros componentes. Estos sucesos describen la incorporación del dispositivo, su comunicación con la nube, el estado de telemetría, errores internos, límites de cuota y mucho más.

Podemos agruparlos en varias categorías lógicas para que tenga sentido todo el listado:

Arranque, parada e incorporación del servicio

Hay eventos que simplemente indican operación normal del servicio:

• El servicio de Microsoft Defender para punto de conexión se ha iniciado (varias versiones posibles): aparece en arranque, apagado o durante la incorporación; no requiere acción.
• El servicio se apaga al apagar el dispositivo o retirarlo: de nuevo, funcionamiento normal.
• La incorporación o el “reenlazamiento” se han completado correctamente: el dispositivo se ha integrado en el portal, aunque puede tardar varias horas en aparecer.
• Se ha calculado un Id. de dispositivo de Defender: solo informativo; se usa para identificar de forma única el equipo que envía telemetría.

También hay eventos ligados a la OOBE (pantalla de bienvenida de Windows): algunos indican que OOBE se ha completado y que el servicio empezará a funcionar tras terminar de instalar las actualizaciones; otros avisan de que OOBE sigue pendiente o que no se ha podido esperar a que finalice (con un código de error). Si esos avisos persisten tras reiniciar, conviene comprobar que todas las actualizaciones de Windows estén completamente instaladas.

En cuanto al proceso de incorporación en sí, existen eventos que relatan paso a paso lo que hace el servicio: desde comprobar si hay parámetros de onboarding, hasta escribir y leer blobs de incorporación, cambiar tipos de inicio, limpiar configuración al retirar el dispositivo, etc.

Cuando algo falla en esa cadena, aparecen eventos del estilo:

• El servicio no está incorporado y no se encontraron parámetros de incorporación: el dispositivo no reporta al portal; hay que revisar scripts y paquetes de onboarding.
• No se han podido leer los parámetros de incorporación o retirada, a veces con descripción detallada del error o con el tipo y código de error.
• No se ha podido conservar la información de incorporación, ni limpiar la configuración, ni cambiar el tipo de inicio del servicio durante onboarding o offboarding.

En todos esos casos el patrón de solución es similar: verificar que los scripts de incorporación se han desplegado bien, que los paquetes de configuración no han caducado y, si hace falta, volver a desplegarlos. También se suele recomendar revisar conectividad a Internet cuando los parámetros de retirada se descargan desde la nube.

Conectividad con la nube y canal de comandos

Otro bloque de eventos clave tiene que ver con la conectividad entre el servicio de Defender y los servidores de procesamiento externos (la parte cloud de MDE). Algunos ejemplos típicos:

• El servicio se ha conectado con el servidor en una URL concreta: corresponde a direcciones que deberías ver reflejadas en el firewall o en los logs de red.
• El servicio no ha podido conectarse con el servidor en esa URL: requiere comprobar conectividad, configuración de proxy y reglas de firewall.
• No puede iniciar el canal de comandos con una URL determinada: implica que el canal de respuesta de MDE no se puede establecer.

También aparecen avisos de problemas de conectividad para escenarios específicos, por ejemplo la clasificación DLP (prevención de pérdida de datos). Cuando la red falla, se registra un evento indicando que hay problemas para llegar a la nube en el escenario DLP; cuando se restaura, otro evento lo notifica y confirma que el flujo puede continuar.

Más en general, hay eventos que informan del estado de la conexión de red y del nivel de batería del dispositivo: si la conexión se considera “de uso medido” o la batería está baja, el servicio reduce la frecuencia con la que se comunica con el servidor (por ejemplo, cada X minutos) para ahorrar recursos. Cuando la red o la batería vuelven a ser “normales”, se restablece la frecuencia estándar.

También se controlan las cuotas de comunicación y de datos: ciertos eventos avisan de que un módulo está a punto de superar su cuota diaria, o de que se ha detenido temporalmente el envío de “datos cibernéticos” por haber llegado al máximo permitido. Otros eventos confirman cuando se reanuda el envío de datos después de haber pasado el periodo de cuota.

Telemetría, diagtrack y servicios relacionados

Microsoft Defender para punto de conexión depende mucho del servicio de Experiencias del usuario y telemetría asociadas (diagtrack) para enviar datos a la nube. Por eso aparecen bastantes eventos que hablan de registro y anulación de registro de ese servicio, así como de errores al iniciarlo.

Si ves mensajes del tipo “no se ha podido iniciar el servicio de Experiencias del usuario y telemetría asociadas” o “error del servicio de telemetría de Windows”, hay que asegurarse de que el servicio de datos de diagnóstico está habilitado y de revisar el registro de eventos específico “Microsoft-Windows-UniversalTelemetryClient/Operational” para más detalles.

En esa misma línea, el servicio intenta registrarse como dependencia de diagtrack y, si falla, se producen errores de incorporación. Generalmente, las recomendaciones pasan por revisar scripts y paquetes de onboarding y comprobar telemetría.

Otro grupo de eventos describe la gestión de configuración en la nube de Defender: cuando se recibe un archivo de configuración válido, se registra que la nueva configuración se ha aplicado correctamente y se indica su versión. Si el archivo es inválido, se genera un evento de “configuración de nube no válida recibida y omitida”.

Si no se puede aplicar una nueva configuración, el servicio intenta aplicar la última válida conocida; si tampoco puede, vuelve a la configuración predeterminada y lo registra. En estos casos, si no aparece posteriormente un evento indicando que la nueva configuración se ha aplicado bien, se recomienda contactar con soporte técnico.

ETW, sensores, comandos y problemas internos

La recopilación de datos de Defender se basa en sesiones de ETW (Event Tracing for Windows) y en varios ejecutables de sensor, como senseCE (para telemetría principal) o SenseNdr (detección y respuesta de red). El Visor de eventos refleja tanto su arranque como posibles fallos.

Por ejemplo, se registran eventos cuando:

• No se ha podido registrar o iniciar una sesión de seguimiento de eventos (falta de recursos, demasiadas sesiones activas, etc.).
• Después de varios intentos, la sesión ETW consigue iniciarse y se registra la recuperación correcta.
• No se puede agregar un proveedor concreto a una sesión ETW; como consecuencia, no se notifican los eventos de ese proveedor.

También hay eventos sobre creación y eliminación de “registradores automáticos” ETW seguros. Si no se pueden crear o quitar, se sugiere reiniciar el dispositivo y, si el error persiste, contactar con soporte.

En cuanto a los sensores, se registran eventos cuando se inicia o termina el ejecutable senseCE, cuando se llama a la inicialización de MCE, o cuando falla el arranque de senseCE (por ejemplo, por no poder cargar el DLL MsSense o por problemas de módulo). En esos casos se suele indicar un código de error y la recomendación de reiniciar y, si no se resuelve, abrir un caso con soporte técnico.

Lo mismo pasa con SenseNdr (detección y respuesta de red): se loguea tanto su inicio como su finalización, así como problemas al poner en cola descargas de controladores relacionados durante el proceso de retirada.

Además, aparecen eventos de comandos de respuesta enviados desde el portal: se registra cuándo se inician, si se ejecutan bien, si los parámetros son inválidos o si fallan. Cuando hay fallos persistentes al ejecutar comandos, de nuevo la recomendación es escalar al soporte oficial.

System Guard Runtime Monitor y registro (Sgrm)

Windows integra un componente llamado System Guard Runtime Monitor (Sgrm) que envía datos de atestación a la nube. Defender registra cuando no puede configurar este monitor para conectarse a la región geográfica correspondiente o cuando no puede eliminar información de esa región.

En esos casos, el propio texto del evento suele indicar que hay que revisar los permisos del Registro en HKLM\Software\Microsoft\Windows\CurrentVersion\Sgrm. Si después de ajustar permisos el error sigue, toca contactar con soporte técnico.

Autenticación, claves criptográficas y tokens

Otro bloque de sucesos gira alrededor del servicio de autenticación que usa Defender para punto de conexión. Entre otras cosas, el servicio genera claves criptográficas, firma mensajes, mantiene un estado de autenticación persistente y gestiona tokens.

Verás eventos que indican:

• Generación correcta de claves criptográficas.
• Fallo al generar la clave (no se pudo crear la clave criptográfica).
• Registro correcto del servicio en el servicio de autenticación.
• Errores de comunicación con el servicio de autenticación (solicitud rechazada, códigos HTTP, hresult, etc.).
• Fallos al firmar mensajes o al abrir la clave criptográfica almacenada.
• Problemas al conservar o eliminar el estado de autenticación persistente.
• Suspensión temporal de la carga de telemetría cibernética por token no válido o caducado, y posterior reanudación cuando se obtiene un token nuevo.

En general, estos eventos son más de interés en entornos corporativos. Si la máquina deja de reportar al portal, conviene revisar todos estos sucesos para saber si el problema está en la propia clave, en la firma de mensajes o en la comunicación con el servicio de autenticación.

Configuración CSP, etiquetado de dispositivos y frecuencia de telemetría

Finalmente, hay toda una serie de eventos generados por el CSP (Configuration Service Provider) que gestiona parámetros como el estado de incorporación, la última vez que el dispositivo se conectó, el Id. de organización, el uso compartido de muestras, la frecuencia de envío de telemetría o el etiquetado de dispositivos.

Estos eventos suelen tener nombres del estilo “CSP: obtener valor de nodo”, “CSP: establecer valor completado”, etc., e indican tanto lecturas (Get) como escrituras (Set) de parámetros. Algunos puntos llamativos:

• El CSP obtiene el valor del Id. de organización durante la incorporación del equipo al servicio.
• Se registran los cambios en la frecuencia de informes de telemetría (TelemetryReportingFrequency), indicando valor anterior, nuevo valor y resultado.
• Se controlan los identificadores de grupo usados para agrupar dispositivos; si se supera el máximo permitido, se genera un evento avisando de que no se pudo establecer el valor por longitud excesiva.
• El etiquetado de dispositivos incluye grupo, criticidad e incluso método de identificación. Si los valores solicitados quedan fuera de los rangos permitidos, se registran errores explícitos.

Estos logs son especialmente útiles cuando gestionas políticas de seguridad y clasificación de dispositivos via MDM o Intune, ya que te permiten validar que los cambios se han aplicado realmente en el cliente.

Como ves, el registro de eventos asociado a Defender para punto de conexión es muy abundante, pero sigue una lógica bastante clara: eventos informativos cuando todo va bien, y eventos de error con códigos específicos y recomendaciones cuando algo se rompe (conectividad, telemetría, ETW, incorporación, autenticación, etc.).

Reutilizar vistas y mantener una rutina de revisión

Una vez que tengas un par de vistas personalizadas útiles (por ejemplo, una para errores de arranque de servicios y otra para actividad sospechosa de seguridad), lo más inteligente es integrarlas en tu rutina.

En cada sesión de revisión, abre el Visor de eventos, selecciona tus vistas y mira solo lo que realmente te interesa. Así no perderás tiempo buceando entre sucesos informativos inocuos.

No olvides que las vistas personalizadas se actualizan con los nuevos sucesos, así que sirven tanto para análisis forense como para monitoreo día a día. Si mantienes esta disciplina, te será mucho más fácil detectar patrones extraños, picos de errores o repetición de fallos concretos.

Dominar el Visor de eventos en Windows 11, y en particular los registros avanzados ligados a Microsoft Defender para punto de conexión, convierte lo que antes era una pantalla llena de números incomprensibles en una fuente de información brutal para diagnosticar y asegurar tus equipos. Cuanto más te acostumbres a leer IDs, orígenes y descripciones, más rápido sabrás si un error es algo puntual, un simple aviso de conectividad o el síntoma de algo serio que hay que atajar cuanto antes.