Get-WinEvent — cómo investigar errores y cuelgues en Windows

La PC se reinició sola a las tres de la madrugada. Abres el Visor de eventos de Windows y encuentras 40.000 entradas sin filtrar. Diez minutos después sigues desplazándote por la pantalla. Con el cmdlet Get-WinEvent en PowerShell, llegas a la causa en menos de un minuto — y de paso puedes automatizar el barrido para que corra cada semana.

Por qué Get-WinEvent y no el Visor de eventos

El Visor de eventos es bueno para la exploración casual. Cuando ya sabes qué buscas — un cuelgue, un servicio que se detuvo, errores de la madrugada — la interfaz gráfica se convierte en un obstáculo. Get-WinEvent filtra del lado del servidor: solo los eventos que coinciden con el criterio llegan a PowerShell, sin cargar el log entero en memoria.

Otra ventaja: Get-WinEvent funciona en remoto de forma nativa. Con un parámetro -ComputerName, consultas el log de cualquier máquina de la red que acepte WinRM — sin instalar agente, sin RDP, sin abrir la interfaz gráfica en el servidor. Para quien administra más de una PC, esto ahorra tiempo considerable.

Si estás empezando con PowerShell ahora, la guía de PowerShell para principiantes cubre los conceptos de pipeline y Select-Object que van a facilitar mucho los ejemplos siguientes.

Requisito previo: ejecutar como administrador

La mayoría de los logs del sistema exige privilegio elevado. Sin eso, Get-WinEvent devuelve un error de acceso en silencio — ves el mensaje, pero sin los eventos críticos. Para abrir PowerShell como admin: Win + X → Terminal (Admin) o clic derecho en el ícono de PowerShell → Ejecutar como administrador.

Ver los últimos errores del sistema

El log System registra eventos del propio Windows: un driver falló, un servicio no inició, el hardware reportó un problema. Para listar los 50 eventos de error más recientes (Level 2 = Error):

Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 50 |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-Table -AutoSize -Wrap

La columna ProviderName identifica quién generó el evento — driver, servicio o componente de Windows. La columna Id es el número del evento: un identificador universal que puedes poner directo en Google o en Microsoft Learn para entender qué significa ese código.

Para eventos críticos (Level 1), cambia el valor:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=1} |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-Table -AutoSize -Wrap

Cómo descubrir por qué Windows se reinició solo

¿Qué evento registra los reinicios inesperados en Windows?

El Event ID 41 del proveedor Kernel-Power indica que el sistema se apagó sin pasar por el proceso normal de shutdown — BSOD, cuelgue total, corte de energía o sobrecalentamiento. El Event ID 6008 lo complementa: registra, en el siguiente arranque, que el apagado anterior fue inesperado.

# BSOD o cuelgue — el kernel no registró un shutdown limpio
Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Microsoft-Windows-Kernel-Power'
    Id=41
} | Select-Object TimeCreated, Message | Format-List

# Confirmación de shutdown inesperado (registrado en el siguiente arranque)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=6008} |
    Select-Object TimeCreated, Message | Format-List

Usa Format-List aquí en vez de Format-Table: el mensaje completo del Event 41 muestra el BugCheckCode (código hexadecimal del BSOD), que es el dato más útil para identificar la causa — driver corrupto, RAM defectuosa, temperatura.

Diagnosticar un servicio que dejó de funcionar

El Service Control Manager registra dos situaciones distintas cuando un servicio se cae de forma inesperada:

• Event ID 7031 — el servicio terminó de forma inesperada y se disparó una acción de recuperación (reiniciar, ejecutar un programa).
• Event ID 7034 — el servicio terminó de forma inesperada, sin ninguna acción de recuperación configurada.

Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Service Control Manager'
    Id=7031,7034
} | Select-Object TimeCreated, Id, Message | Format-List

El mensaje incluye el nombre del servicio y cuántas veces falló en la sesión actual. Si ves que un servicio crítico — Windows Defender, DNS Client, RPC Server — falla repetidamente, el problema va más allá de un proceso inestable y merece atención inmediata.

Errores de aplicación en la última semana

Los crashes de aplicaciones quedan en el log Application, bajo el Event ID 1000 (Application Error). El parámetro StartTime del FilterHashtable acepta un objeto DateTime, lo que hace directo el filtro por período:

Get-WinEvent -FilterHashtable @{
    LogName='Application'
    ProviderName='Application Error'
    Id=1000
    StartTime=(Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Message | Format-List

El mensaje muestra el nombre del ejecutable que se colgó, el nombre y versión del módulo que causó la falla, y la dirección de offset. Esos tres datos juntos son suficientes para localizar el problema en el soporte del fabricante o en bases como NTDebug sin necesitar un dump completo.

Consultar el log de otra máquina en la red

Esta es la ventaja que el Visor de eventos gráfico esconde detrás de varios menús. Con WinRM habilitado en la máquina destino (Enable-PSRemoting -Force), basta una línea:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -ComputerName NOMBRE-DEL-PC |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-Table -AutoSize -Wrap

Reemplaza NOMBRE-DEL-PC por el hostname o la IP de la máquina. Se usan las credenciales del usuario actual; si la máquina está en otro dominio, agrega -Credential (Get-Credential).

Exportar a CSV

Cuando necesites compartir el resultado con otra persona o registrar los errores de un período, el pipeline va directo a un archivo:

Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddDays(-7)} |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Export-Csv -Path "$env:USERPROFILE\Desktop\errores-sistema.csv" -NoTypeInformation -Encoding UTF8

El archivo aparece en el Escritorio, listo para abrir en Excel o enviar a soporte técnico — sin necesidad de capturar la pantalla del Visor de eventos.

Combinando diagnóstico y seguridad

Get-WinEvent cubre dos universos distintos: el diagnóstico de fallas técnicas que vimos aquí, y la auditoría de seguridad — logins sospechosos, creación de servicios, ejecución de scripts. Si quieres usar los mismos logs para detectar actividad maliciosa, el post sobre PowerShell para auditar logs de seguridad en Windows cubre ese segundo ángulo con scripts listos para alertas automáticas.

Y si quieres que este barrido de errores corra automáticamente cada semana — sin depender de acordarte de abrir la terminal — la guía de schtasks muestra cómo programar cualquier script de PowerShell sin necesidad de abrir el Programador de tareas.