Visor de eventos para humanos: encuentra errores reales en 5 minutos

La mentalidad de cinco minutos (a qué estás realmente buscando)

Tu trabajo en el Visor de eventos no es leer registros. Es tomar una decisión bajo incertidumbre. Específicamente, intentas responder cuatro preguntas:

1. ¿Qué cambió? (Actualización, controlador, certificado, directiva, ruta de almacenamiento, sincronización de tiempo, derechos de cuentas.)
2. ¿Cuándo empezó? (Correlaciona con despliegue/reinicio/backup/ventana de parches.)
3. ¿Qué componente falla primero? (Los errores de almacenamiento suelen preceder a los fallos de la app; los fallos de autenticación preceden a las caídas del servicio.)
4. ¿Es esto un error real o una queja de fondo? (Algunos “errores” son solo Windows siendo dramático.)

El Visor de eventos falla a la gente porque tratan todos los iconos rojos como iguales. No lo hagas. Prioriza señales que sean:

• Correlacionadas en el tiempo con el inicio del incidente.
• Repetidas (mismo Event ID + source que se repite).
• Transversales (System + Application + un registro operativo concreto coinciden).
• Accionables (apuntan a un dispositivo, archivo, cuenta, certificado o nombre de servicio).

Además: deja de hacer capturas de pantalla del Visor de eventos como si fuera un ave rara. Exporta los eventos. Consúltalos. Compáralos. Es 2026, no 2006.

Broma #1: El Visor de eventos es donde las advertencias se jubilan—cómodamente, ruidosamente y sin pagar nunca renta.

Una cita para mantenerte honesto:

Idea parafraseada — W. Edwards Deming: sin datos, eres solo otra persona con una opinión.

Guion de diagnóstico rápido: primeras/segundas/terceras comprobaciones

Minuto 0–1: Define la ventana de fallo

• ¿Cuál es la marca de tiempo del primer síntoma visible por el usuario?
• ¿Ocurrió un reinicio? ¿Un parche? ¿Un cambio de certificado? ¿Un failover de almacenamiento?
• Elige una ventana: 15 minutos antes del inicio del síntoma hasta 15 minutos después.

Decisión: si no puedes acotar el tiempo, no puedes acotar la realidad. Obtén la hora primero.

Minuto 1–2: Registro System para la verdad a nivel plataforma

Empieza en Windows Logs → System. ¿Por qué? Porque cuando el suelo se está hundiendo, los muebles (aplicaciones) se quejan después.

Filtra por niveles: Critical, Error. Ordena por Date and Time. Enfócate en fuentes como:

• Kernel-Power (reinicios inesperados)
• Disk / storahci / nvme / iaStorAC (ruta de almacenamiento)
• Ntfs (sistema de archivos)
• Service Control Manager (servicios que no arrancan)
• WHEA-Logger (errores de hardware)
• Schannel (TLS/handshake de certificados)

Decisión: si el log System muestra reinicios de disco, timeouts de controladora, WHEA o eventos de energía, deja de culpar a la app. Arregla la plataforma primero.

Minuto 2–3: Registro Application para “quién murió primero”

Ve a Windows Logs → Application y filtra de forma similar. Busca:

• Application Error (Event ID 1000)
• .NET Runtime (Event ID 1026)
• SQL Server, IIS, VSS, MSExchange*, fuentes de terceros
• SideBySide (problemas de manifiesto / CRT)

Decisión: identifica el primer crash en la ventana, luego correlaciona hacia atrás: ¿qué lo precedió en System?

Minuto 3–4: Registros operativos para el subsistema que sospechas

La mayoría de las respuestas reales no están en “Application” o “System”. Están en:

• Applications and Services Logs → Microsoft → Windows → (componente) → Operational
• Ejemplos: WindowsUpdateClient/Operational, TaskScheduler/Operational, WinRM/Operational, GroupPolicy/Operational, Security-Kerberos/Operational

Decisión: si la falla está relacionada con actualizaciones, autenticación o directivas, los registros operativos te darán el código de error real y contexto.

Minuto 4–5: Pruébalo con una consulta y luego exporta

Los clics en el Visor de eventos están bien para orientarse. Para la prueba, usa Get-WinEvent o wevtutil y exporta un paquete ajustado.

Decisión: si no puedes reproducir el mismo conjunto de eventos mediante una consulta, probablemente estés persiguiendo lo equivocado.

Introducción a los registros de eventos para adultos

El Visor de eventos es un navegador de base de datos, no un panel

El eventing de Windows es un sistema de registro estructurado con canales, providers, IDs, niveles, tasks, opcodes, keywords y payloads XML. El Visor de eventos te muestra una vista aplanada. Eso ayuda, pero oculta las mejores partes: los campos estructurados que puedes consultar.

Piensa en “canales” y “providers”

Channel es donde viven los eventos (System, Application, Security y cientos de canales operativos). Provider es quién escribió el evento (Service Control Manager, Disk, Schannel, WindowsUpdateClient).

Cuando alguien dice “busca Event ID 41”, tu pregunta de seguimiento debería ser: “¿Event ID 41 de qué provider?” Porque los números de Event ID no son globalmente únicos entre providers.

Los niveles son políticos

“Error” no siempre significa error. Algunos providers registran condiciones transitorias como errores porque es la única forma de que alguien note. Otros subregistran porque a los proveedores no les gustan los tickets de soporte.

Confía en los patrones, no en los colores.

La correlación vence a la interpretación

La misma causa raíz frecuentemente aparece como una cadena:

• Contratiempo de almacenamiento (Disk/Ntfs)
• Timeout de servicio (Service Control Manager)
• Fallo de aplicación (.NET Runtime/Application Error)
• Queja del usuario (“Está lento”)

Si comienzas por el crash de la app, ya llegaste tarde.

El registro Security es especial (y a menudo irrelevante)

Los registros de Security están controlados, son verbosos y a veces enormes. Son invaluables para fallos de autenticación y auditoría de directivas, pero también pueden consumir tus cinco minutos completos. Úsalos cuando tengas una hipótesis: Kerberos, NTLM, derechos de inicio de sesión, cuentas de servicio o cambios de GPO que afecten accesos.

Datos interesantes e historia (las partes que importan)

• Windows NT introdujo el servicio Event Log en los años 90 como un mecanismo central de auditoría; por eso la división “System/Application/Security” aún define flujos de trabajo hoy.
• Event Tracing for Windows (ETW) se convirtió en la columna vertebral de alto rendimiento para la telemetría moderna de Windows; muchos registros “Operational” están respaldados por ETW.
• Los Event IDs son scoped por provider, no universales. Dos providers diferentes pueden usar el mismo ID con significados totalmente distintos.
• Los cambios de la era Vista ampliaron los canales masivamente (Applications and Services Logs), por eso los registros más útiles a menudo están enterrados bajo Microsoft → Windows.
• Los eventos Schannel se volvieron el canario para fallos TLS/certificados a medida que las empresas endurecieron las bases criptográficas y deshabilitaron protocolos antiguos.
• WHEA (Windows Hardware Error Architecture) hizo visibles los machine check y errores hardware corregidos de forma más estandarizada, por eso WHEA-Logger es tu fuente de “el hardware está descontento”.
• Windows Update se movió hacia la componentización (CBS, servicing stack), por lo que las fallas de actualización suelen requerir revisar múltiples canales más allá de los mensajes básicos de “WindowsUpdateClient”.
• VSS (Volume Shadow Copy Service) es anterior a muchos proveedores de backup que lo usan; cuando falla, tus backups “suceden” hasta que pruebas la restauración. Los logs dicen la verdad primero.
• Los valores predeterminados de retención de registros suelen ser pequeños en servidores, lo que destruye silenciosamente tu capacidad de hacer análisis “¿cuándo empezó esto?”.

12+ tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas prácticas que puedes ejecutar de inmediato. Cada una incluye: un comando, qué significa una salida típica y la decisión que tomas. Los comandos se muestran como si estuvieras en un host Windows con PowerShell disponible; el prompt es solo un prompt.

Tarea 1 — Lista de los logs más grandes (encuentra quién se está comiendo tu historial)

cr0x@server:~$ wevtutil el
Application
Security
System
Microsoft-Windows-WindowsUpdateClient/Operational
Microsoft-Windows-GroupPolicy/Operational
...

cr0x@server:~$ wevtutil gl System
name: System
enabled: true
type: Admin
owningPublisher:
isolation: Application
channelAccess: O:BAG:SYD:(A;;0x5;;;SY)(A;;0x1;;;BA)(A;;0x1;;;SO)
logging:
  logFileName: %SystemRoot%\System32\Winevt\Logs\System.evtx
  retention: false
  autoBackup: false
  maxSize: 20971520

Qué significa: El tamaño máximo del log System es ~20 MB. En servidores ocupados, eso puede ser horas o días de historial, no semanas.

Decisión: Si te falta contexto, aumenta el tamaño del log (y configura la política de retención apropiada para tu entorno). Logs pequeños equivalen a memoria corta.

Tarea 2 — Extrae los últimos 50 errores de System rápido (sin GUI, sin desplazamiento)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 50 | Format-Table TimeCreated,Id,ProviderName,Message -AutoSize"
TimeCreated            Id ProviderName           Message
-----------            -- ------------           -------
02/05/2026 02:11:03    7 Disk                   The device, \Device\Harddisk2\DR2, has a bad block.
02/05/2026 02:11:07 129 storahci                Reset to device, \Device\RaidPort0, was issued.
02/05/2026 02:11:15 7000 Service Control Manager The SQLSERVERAGENT service failed to start due to the following error: ...
...

Qué significa: Bloques malos en disco y resets de controladora son upstream. La falla del SQL Agent es daño colateral downstream.

Decisión: Deja la optimización a nivel app. Empieza el triage de almacenamiento/hardware: comprueba SMART, firmware de controladora, cableado, ruta SAN, latencia de almacenamiento en VM.

Tarea 3 — Acota la ventana de tiempo (el truco de “cinco minutos”)

cr0x@server:~$ powershell -NoProfile -Command "$start=(Get-Date).AddMinutes(-30); $end=Get-Date; Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start; EndTime=$end; Level=1,2} | Sort-Object TimeCreated | Select-Object TimeCreated,Id,ProviderName -First 20"
TimeCreated            Id ProviderName
-----------            -- ------------
02/05/2026 01:49:52  6006 EventLog
02/05/2026 01:50:10    2 Kernel-General
02/05/2026 02:11:03    7 Disk
02/05/2026 02:11:07  129 storahci

Qué significa: En los últimos 30 minutos, los primeros eventos serios ocurren a las 02:11. Ese es tu inicio de incidente, incluso si los usuarios lo notaron a las 02:15.

Decisión: Alinea todos los demás logs a las 02:11 y trabaja hacia afuera. No persigas ruido antiguo no relacionado.

Tarea 4 — Verifica reinicio inesperado vs “alguien lo reinició”

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 01:49:51
Message     : The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Qué significa: Kernel-Power 41 es “apagado no limpio”. No te dice por qué; te dice que el SO no llegó a despedirse.

Decisión: Empareja con eventos BugCheck, advertencias WHEA, resets de disco o eventos de hipervisor. Trátalo como síntoma, no como causa raíz.

Tarea 5 — Encuentra fallos de inicio de servicios (porque dependencias rotas parecen “la app está caída”)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:11:15 7000 The SQLSERVERAGENT service failed to start due to the following error: The service did not start due to a logon failure.
02/05/2026 02:11:16 7009 A timeout was reached (30000 milliseconds) while waiting for the SQLSERVERAGENT service to connect.

Qué significa: El fallo de logon sugiere un problema de credenciales (cambio de contraseña, problema con gMSA, derechos eliminados), no CPU o memoria.

Decisión: Valida la cuenta de servicio, cambios recientes de contraseña y los derechos de “Log on as a service”. No lo reinicies 20 veces y lo declares “arreglado”.

Tarea 6 — Identifica firmas de crash (Event ID 1000) y el módulo con fallo

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error'; Id=1000} -MaxEvents 10 | Select-Object TimeCreated,Message | Format-Table -Wrap"
TimeCreated            Message
-----------            -------
02/05/2026 02:12:02  Faulting application name: w3wp.exe, version: ...
                       Faulting module name: ntdll.dll, version: ...
                       Exception code: 0xc0000374
                       Fault offset: ...

Qué significa: Tienes un crash con un código de excepción. El “faulting module” no siempre es el culpable (ntdll a menudo solo reporta el crash).

Decisión: Correlaciona con logs específicos de la app y cambios recientes (actualizaciones, DLL nuevas, inyección de antivirus). Si es repetible, captura un dump y deja de adivinar.

Tarea 7 — Excepciones del runtime .NET (a menudo más legibles que logs del proveedor)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='.NET Runtime'; Id=1026} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 02:12:01
Message     : Application: MyService.exe
              Framework Version: v4.0.30319
              Description: The process was terminated due to an unhandled exception.
              Exception Info: System.IO.IOException: The network path was not found.

Qué significa: La excepción incluye un fallo concreto (camino de red no encontrado). Eso apunta a SMB, DNS, firewall o un recurso compartido faltante, no a “.NET está roto”.

Decisión: Verifica la resolución de nombres y la disponibilidad del recurso compartido; busca errores de red en System alrededor de la misma marca de tiempo.

Tarea 8 — Errores de almacenamiento y sistema de archivos: Disk, Ntfs, y “sorpresa, es el SAN”

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Ntfs'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:11:10   55 The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume.

Qué significa: NTFS reporta corrupción. Esto puede ser fallo real de disco, un problema en la ruta de almacenamiento o un problema del host/VM que provoca desórdenes en el orden de escritura.

Decisión: Si estás en una VM, revisa la salud del almacenamiento del host y cadenas de snapshot raras. Si es físico, comprueba la salud del disco y logs de la controladora. Planifica una ventana controlada para chkdsk; no lo ejecutes “a la ligera” en un volumen de base de datos crítico sin evaluar impacto.

Tarea 9 — Eventos hardware WHEA (errores corregidos siguen siendo errores)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
02/05/2026 02:10:58   17 Warning          A corrected hardware error has occurred. Component: PCI Express Root Port...

Qué significa: Errores corregidos significan que el sistema se recuperó, pero tu hardware se está degradando o el bus está inestable (a menudo NIC/HBA/PCIe).

Decisión: Trátalo como indicador adelantado. Escala al equipo de hardware/proveedor, revisa firmware/controladores y correlaciona con resets de disco/red.

Tarea 10 — Fallos TLS y de certificados vía Schannel (cuando “la API está caída” es criptografía)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Schannel'; Level=2} -MaxEvents 10 | Format-Table TimeCreated,Id,Message -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 02:08:44 36874 An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server.

Qué significa: Cliente y servidor no comparten suites de cifrado. Es común después de cambios de hardening o librerías cliente antiguas.

Decisión: Identifica el cliente (a menudo en logs de la app o trazas de red) y arregla la superposición de cifrados/protocolos. Evita “re-habilitar TLS 1.0” a menos que tu apetito de riesgo sea “recreación histórica”.

Tarea 11 — Fallos de Windows Update con detalle operativo (deja de fiarte de la GUI)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; Level=2} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated            Id Message
-----------            -- -------
02/05/2026 01:40:12   20 Installation Failure: Windows failed to install the following update with error 0x800f081f: ...
02/05/2026 01:40:13   25 Windows Update failed to download an update. Error: 0x8024401c

Qué significa: Tienes códigos de error reales. 0x800f081f suele ser problemas con el component store/origen de archivos; 0x8024401c suele relacionarse con conectividad/WSUS/proxy.

Decisión: Separa problemas de “servicing stack/component store” de problemas de “red/WSUS”. Propietarios diferentes, soluciones diferentes.

Tarea 12 — Consulta por provider + ID usando XPath (la precisión importa)

cr0x@server:~$ wevtutil qe System /q:"*[System[(Provider[@Name='Disk'] and (EventID=7))]]" /f:text /c:3
Event[0]:
  Log Name: System
  Source: Disk
  Date: 2026-02-05T02:11:03.0000000Z
  Event ID: 7
  Task: N/A
  Level: Error
  Opcode: Info
  Keyword: Classic
  User: N/A
  User Name: N/A
  Computer: server01
  Description:
  The device, \Device\Harddisk2\DR2, has a bad block.

Qué significa: Extracción limpia y específica por provider. Esto es lo que pegas en las notas del incidente sin vergüenza.

Decisión: Usa consultas XPath cuando necesites evidencia repetible y menos ambigüedad de la GUI.

Tarea 13 — Exporta un paquete de evidencia ajustado (para escalado o postmortem)

cr0x@server:~$ wevtutil epl System C:\Temp\System.evtx
The operation completed successfully.

cr0x@server:~$ wevtutil epl Application C:\Temp\Application.evtx
The operation completed successfully.

cr0x@server:~$ wevtutil epl Microsoft-Windows-WindowsUpdateClient/Operational C:\Temp\WindowsUpdate-Operational.evtx
The operation completed successfully.

Qué significa: Ahora tienes archivos EVTX portátiles que preservan estructura y pueden abrirse en otro lugar.

Decisión: Siempre exporta EVTX, no CSV, cuando quieras que los ingenieros hagan filtrado y correlación reales después.

Tarea 14 — Encuentra eventos de “log cleared” (porque a veces el misterio es sabotaje o pánico)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -MaxEvents 5 | Format-List TimeCreated,Message"
TimeCreated : 02/05/2026 01:10:22
Message     : The audit log was cleared.

Qué significa: Alguien (o algo) limpió el log de Security. Podría ser una acción de mantenimiento legítima. Podría ser un atacante. Podría ser un admin que entró en pánico e intentó “reducir el ruido”.

Decisión: Trátalo como un evento de seguridad y gobernanza. Valida registros de cambio, acceso privilegiado y por qué ocurrió. Limpiar logs no es troubleshooting; es destruir evidencia.

Tarea 15 — Detecta problemas de sincronización horaria (cuando auth y TLS fallan “sin razón”)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; Level=2,3} -MaxEvents 20 | Format-Table TimeCreated,Id,LevelDisplayName,Message -Wrap"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
02/05/2026 02:05:01   36 Warning          The time service has not synchronized the system time for 86400 seconds because no time data was available.

Qué significa: La deriva de tiempo puede romper Kerberos, certificados, tareas programadas y comportamiento “aleatorio” de aplicaciones.

Decisión: Arregla la jerarquía NTP/fuentes de tiempo. No lo soluciones aflojando políticas de autenticación; volverás aquí la próxima semana.

Tres micro-historias corporativas (porque la realidad es más rara)

Historia 1: El incidente causado por una suposición equivocada

El ticket decía: “La base de datos está lenta después del parche”. El DBA insistía en que era una regresión del plan de consultas. El equipo de Windows insistía en que era una configuración de SQL. Todos estaban seguros. Nadie tenía razón.

En el servidor afectado, el log System mostró intermitentes resets de storahci y advertencias de Disk. El timing encajaba perfectamente con la ventana de “lentitud”, pero el equipo lo descartó porque el dashboard del array de almacenamiento estaba en verde y el host VM no mostraba alertas.

La suposición equivocada fue sutil: “Si el SAN está sano, Windows no registraría resets de disco”. En la práctica, Windows registra lo que el guest ve. Un problema transitorio en la ruta, un controlador HBA inestable o una configuración multipath defectuosa puede hacer que el guest experimente timeouts mientras el array permanece “saludable”. Los dashboards verdes no prueban I/O verde.

La solución no fue una configuración de base de datos. Fue un alineamiento de driver/firmware en la ruta de almacenamiento del host. Una vez que la ruta se estabilizó, la latencia de consultas volvió a la normalidad sin tocar SQL.

Lo que salvó la respuesta al incidente no fue una profunda pericia en almacenamiento. Fueron cinco minutos de correlación disciplinada de logs: resets de disco primero, demoras de servicio segundo, quejas de aplicación tercero. La plataforma dijo la verdad; a la gente simplemente no le gustó la respuesta.

Historia 2: La optimización que salió mal

Un equipo quería inicios de sesión más rápidos y menos escrituras “innecesarias”. Redujeron tamaños de logs y activaron sobreescritura agresiva porque “ya enviamos logs a un sistema central”. Se presentó como higiene de rendimiento. Incluso pasó una revisión de cambios, porque nadie quiere ser la persona que defiende archivos de log más grandes.

Tres semanas después, un controlador de dominio empezó a mostrar fallos de autenticación esporádicos. Los usuarios se quejaron durante días: “A veces funciona, a veces no”. Incidente intermitente clásico: dolor máximo, prueba mínima.

Cuando el equipo finalmente miró en el Visor de eventos, los registros de Security y System contenían solo unas pocas horas de historial. Las fallas habían ocurrido “ayer”, pero “ayer” ya no existía. El logging central existía en el papel; el servicio conector había estado fallando silenciosamente, y por supuesto sus propios logs se habían sobreescrito también.

Reconstruyeron la línea de tiempo usando otras evidencias (logs de cliente, logs de firewall y lo poco que quedaba en el DC). La causa raíz resultó ser deriva de tiempo en la ruta NTP de un sitio, causando fallos de Kerberos en determinadas ventanas. Arreglar la sincronización de tiempo solucionó el problema. Pero el tiempo de resolución estuvo dominado por una herida autoinfligida de retención de datos.

Lección: optimizar logging reduciendo retención es como ahorrar en detectores de humo quitando las pilas. Sí, el pitido para. También, el edificio sigue incendiándose.

Historia 3: La práctica aburrida pero correcta que salvó el día

Un servicio relacionado con pagos empezó a fallar en los handshakes TLS tras una rutina de hardening baseline. El equipo de la app juraba que nada había cambiado en su despliegue. El equipo de seguridad juraba que la baseline era segura. El servicio estaba caído y todos preparaban su historia preferida de culpables.

Un SRE hizo algo dolorosamente aburrido: exportó los logs relevantes (System, Application y eventos relacionados con Schannel) para una ventana de dos horas, y luego los comparó con la ventana conocida-buena de la semana anterior del mismo host.

La diferencia fue obvia: Schannel empezó a registrar errores de incompatibilidad de cipher suites justo después de una actualización de políticas. Eso ancló el “qué cambió” a una hora y un subsistema específico. Luego los logs operativos en la pila de la app mostraron la versión de la librería cliente que fallaba, que era más antigua y no soportaba los cipher suites restantes.

La solución fue dirigida: actualizar la librería cliente y mantener la baseline hardened. Sin rollback. Sin re-habilitar protocolos antiguos. Sin discusiones nocturnas de “solo haz que funcione”.

La práctica aburrida gana: mantiene suficiente historial de logs, exporta evidencia EVTX estructurada y compara con una baseline conocida-buena. No es glamuroso, pero es como conservas tus fines de semana.

Broma #2: La forma más rápida de mejorar tu MTTR es dejar de usar “un reinicio más” como tu herramienta de diagnóstico principal.

Errores comunes: síntoma → causa raíz → solución

1) “Todo está en rojo” en el Visor de eventos

Síntoma: Cientos de errores; no sabes por dónde empezar.

Causa raíz: Sin ventana de tiempo, sin correlación, y mezclas ruido crónico con fallo agudo.

Solución: Define una ventana de 30 minutos alrededor del inicio del síntoma. Filtra a Critical+Error. Ordena por tiempo. Identifica el primer par provider/ID que se repite.

2) Kernel-Power 41 y pánico

Síntoma: Aparece Kernel-Power Event ID 41; la gente concluye “fuente de alimentación” o “bug de Windows”.

Causa raíz: 41 es un marcador genérico de apagado no limpio; normalmente es downstream de un crash, hang, pérdida de energía o reinicio del hipervisor.

Solución: Empareja con BugCheck events, advertencias WHEA, resets de disco/controladora y logs del hipervisor. Trátalo como una migaja, no como diagnóstico.

3) Application Error 1000 culpando a “ntdll.dll”

Síntoma: El crash muestra ntdll.dll; los equipos culpan a Windows.

Causa raíz: ntdll frecuentemente es el reportero, no el culpable. La causa real suele ser corrupción de memoria, un módulo incompatible, una herramienta de seguridad inyectada o un fallo de I/O upstream.

Solución: Correlaciona con .NET Runtime (1026), logs del proveedor y cambios recientes. Captura dumps de crash si es repetible. Revisa errores de almacenamiento/red previos al crash.

4) Service Control Manager 7000/7009 ignorados

Síntoma: El servicio no arranca; la gente sigue reiniciándolo.

Causa raíz: Fallo de logon de la cuenta de servicio, fallo de dependencia o I/O lento que causa timeouts.

Solución: Lee el mensaje exacto de SCM. Valida credenciales/derechos. Si son timeouts, investiga latencia de disco y cadena de dependencias, no el binario del servicio.

5) Errores Schannel “arreglados” habilitando protocolos antiguos

Síntoma: Fallo en el handshake TLS; alguien propone habilitar TLS 1.0/cifras débiles.

Causa raíz: La librería cliente no puede hablar TLS moderno o las suites de cifrado; el hardening quitó opciones legadas.

Solución: Actualiza la pila cliente o configura una superposición de cifrados soportada de forma segura. Solo re-habilita cripto débil con una excepción explícita y un plan de salida.

6) Fallos de actualización tratados como “Windows siendo Windows”

Síntoma: Las actualizaciones fallan intermitentemente; los equipos posponen el parcheo indefinidamente.

Causa raíz: Problemas del component store, roturas de proxy/WSUS o mismatch en el servicing stack; los detalles están en los logs operativos, no en la GUI.

Solución: Usa los eventos de WindowsUpdateClient/Operational y los códigos de error. Separa red vs problemas de servicing y asigna al dueño correcto.

7) Logs faltantes en el peor momento posible

Síntoma: No puedes encontrar eventos de la semana pasada cuando empezó el problema.

Causa raíz: Tamaño de log muy pequeño, sobreescritura habilitada o logs limpiados.

Solución: Aumenta tamaños de logs; monitoriza la salud del forwarding; alerta sobre eventos de log clear; exporta evidencia durante incidentes.

8) Deriva de tiempo causando fallos “aleatorios” de auth y TLS

Síntoma: Fallos de Kerberos, errores de certificados, tareas programadas que no se disparan.

Causa raíz: Configuración errónea de la jerarquía NTP/fuente de tiempo bloqueada o confusión de sincronización entre VM y host.

Solución: Valida eventos del Windows Time Service; corrige fuentes de tiempo; asegúrate de respetar la jerarquía de tiempo del dominio.

Listas de verificación / plan paso a paso (trageo repetible)

Lista A — Triage del Visor de eventos en cinco minutos (velocidad humana)

1. Anota la ventana de fallo (estimación de inicio, servicios afectados, último estado conocido bueno).
2. System log primero: filtra Critical+Error, enfócate en Disk/Ntfs/stor*; WHEA; Kernel-Power; SCM; Schannel.
3. Identifica el primer error repetido “nuevo” en la ventana. Nuevo importa más que ruidoso.
4. Application log segundo: encuentra el primer crash/excepción; anota nombre del proceso y código de error.
5. Operational log tercero: elige el canal del subsistema (WindowsUpdateClient, GroupPolicy, Kerberos, WinRM, TaskScheduler, etc.).
6. Correlaciona timestamps: construye una secuencia de 5–10 eventos. Los incidentes son narrativas.
7. Prueba con una consulta (Get-WinEvent/wevtutil) y exporta evidencia EVTX.
8. Toma una decisión: problema de plataforma vs aplicación vs identidad/política vs update/regresión.

Lista B — Si sospechas almacenamiento o sistema de archivos

1. Busca en System eventos de Disk, storahci/nvme/iaStor*, Ntfs, volsnap en la ventana.
2. Busca patrones: resets (129), bad blocks (7), corrupción NTFS (55), fallos de escritura diferida.
3. Comprueba si las fallas se alinean con backups, snapshots o trabajos intensivos.
4. Decide: problema al nivel guest vs host/SAN path vs mismatch driver/firmware.
5. Escala con logs exportados y una ventana de tiempo precisa, no “ha estado lento”.

Lista C — Si sospechas identidad/autenticación/política

1. System log: advertencias del Time-Service, problemas Netlogon, logs operativos de Kerberos.
2. Errores SCM: “logon failure” en arranque de servicio suele ser identidad/política.
3. Security log solo cuando tengas un ID/provider objetivo; de lo contrario es un pozo de tiempo.
4. Confirma cambios recientes de GPO y si coinciden con el inicio del evento.

Lista D — Si sospechas actualizaciones

1. WindowsUpdateClient/Operational: captura los códigos de error y el contexto exacto de la actualización.
2. System/Application: busca errores relacionados con servicing stack y component store alrededor del mismo tiempo.
3. Decide: red/WSUS/proxy vs component store.
4. Documenta los códigos de error exactos en el registro del incidente. Importan.

Preguntas frecuentes

1) ¿Por qué veo eventos “Error” en servidores saludables?

Porque algunos providers registran condiciones transitorias y recuperables como errores (especialmente timeouts de red y servicios). Juzga por correlación: mismo tiempo que el inicio del síntoma, repetido y con confirmación cross-log.

2) ¿Cuál es el mejor log para empezar?

System. Captura hardware, drivers, almacenamiento, energía y arranque de servicios—cosas que hacen fallar aplicaciones después.

3) ¿Debería enfocarme en Event IDs o en sources?

En ambos, pero empieza con provider/source más Event ID. Los Event IDs solos son ambiguos entre providers. “Event ID 41” es Kernel-Power; “Event ID 41” en otro lugar puede significar otra cosa.

4) ¿Hasta cuánto tiempo debería conservar logs?

Suficiente para responder “¿cuándo empezó esto?”. Para muchos servidores eso significa semanas, no días. Si centralizas logs, aún conserva retención local suficiente para sobrevivir outages del forwarding.

5) ¿Kernel-Power 41 es siempre hardware?

No. Es un marcador de apagado no limpio. Puede ser pérdida de energía, bugcheck, hang, reinicio del hipervisor o alguien manteniendo el botón de encendido (sí, pasa). Empáralo con otros eventos.

6) ¿Cómo sé si un crash fue causado por problemas de almacenamiento?

Mira resets de disco/controladora, errores NTFS, fallos de escritura diferida o problemas de volsnap antes del crash. Si los errores de almacenamiento preceden a fallos de aplicación en la misma ventana, trata almacenamiento como sospechoso.

7) ¿Por qué a veces el Visor de eventos “se congela” al hacer clic en un log?

Logs grandes + renderizado costoso + acceso remoto pueden ser lentos. Usa Get-WinEvent para extraer una ventana de tiempo acotada o un número pequeño de eventos. Las consultas escalan mejor que los clics.

8) ¿Cuándo debo exportar EVTX vs copiar/pegar texto?

Exporta EVTX cuando necesites filtrado estructurado, correlación o compartir con otro ingeniero. Copiar/pegar texto está bien para un solo evento en una línea de tiempo del incidente, pero pierde estructura.

9) ¿Es seguro limpiar logs como “mantenimiento”?

Rara vez. Limpiar logs destruye la continuidad forense y hace imposible el análisis de tendencias. Si debes hacerlo, hazlo bajo control de cambios, exporta primero y registra quién/por qué/cuándo.

10) ¿Qué hago si no encuentro nada en System o Application?

Entonces probablemente estés en un canal operativo (WindowsUpdateClient, GroupPolicy, Kerberos, TaskScheduler, Defender, WinRM) o el problema es externo (dispositivo de red, dependencia upstream). Pasa a logs del subsistema y verifica la ventana de tiempo.

Siguientes pasos (qué hacer después de “encontrarlo”)

Encontrar el error no es lo mismo que arreglar el sistema. El movimiento profesional es convertir tu descubrimiento de cinco minutos en confiabilidad durable:

1. Exporta evidencia (EVTX) de System, Application y el canal operativo relevante para la ventana del incidente.
2. Escribe una línea de tiempo corta del incidente con 5–10 eventos clave en orden. Incluye provider, Event ID y timestamp.
3. Clasifica la falla: plataforma/almacenamiento, identidad/política, update/regresión, bug de aplicación o dependencia externa.
4. Arregla la causa upstream primero. Los resets de almacenamiento causan fallos “misteriosos” de apps; la deriva de tiempo causa fallos “aleatorios” de autenticación.
5. Haz los logs sobrevivibles: aumenta retención, monitoriza el forwarding y alerta sobre eventos de log clear.
6. Automatiza la consulta que usaste hoy. Si te salvó una vez, te salvará otra vez—probablemente a las 02:17.

Si no te llevas otra cosa: deja de leer el Visor de eventos como una novela. Consúltalo como un sistema. Tu uptime te lo agradecerá.