Error Kernel‑EventTracing ID 2 en Windows Server: causas y solución definitiva

El evento Kernel‑EventTracing, ID 2 suele inundar los registros de sistema en entornos Windows Server. Aunque a menudo es benigno, impide iniciar nuevas sesiones ETW y compromete la visibilidad de diagnóstico. A continuación encontrarás una guía exhaustiva para erradicarlo de forma definitiva.

Índice

Descripción del Error Kernel‑EventTracing

Cuando una aplicación, servicio o componente del sistema intenta crear una nueva sesión de Event Tracing for Windows (ETW) con un nombre que ya existe, el subsistema de trazas devuelve el código 0xC0000035 (STATUSOBJECTNAME_COLLISION). Windows registra entonces el evento con origen Kernel‑EventTracing y identificador de evento 2. El mensaje típico es:

Session "SensorFramework-{d61722cd-d3ce-0897-1694-d917cab88c2a}" failed to start with the following error: 0xC0000035

El nombre de la sesión puede variar —por ejemplo, DiagLog, NvidiaUWP o PerfDiagLogger—, pero la causa subyacente es la misma: una sesión previa con ese nombre no se cerró de forma correcta, o bien una directiva, tarea o controlador intenta iniciarla mientras sigue activa.

Causas Frecuentes

Servicios de sensores deshabilitados incorrectamente que dejan huérfanas las sesiones ETW asociadas.
Controladores anticuados o incompatibles que registran de manera persistente sesiones con nombre fijo.
Tareas programadas o scripts de diagnóstico que lanzan sesiones sin comprobar su existencia previa.
Actualizaciones de Windows incompletas que no limpian trazas temporales tras reinicio.
Errores de WMI que interrumpen el cierre de las sesiones durante la detención del servicio.

Efectos en el Entorno

El error no suele provocar caídas ni reinicios, pero sus implicaciones no son triviales:

Pérdida de datos de telemetría y sensores (IoT, salud del hardware, XDR).
Ruido en los registros, dificultando la detección de incidentes críticos.
Consumo de identificadores de kernel (handles) y posibles fugas de memoria en sistemas con alta carga de trazado.
En aplicaciones que dependen de ETW para rendimiento (p. ej. SQL Server Extended Events), pueden generarse bloqueos al no poder iniciar sus propias sesiones.

Metodología de Solución Paso a Paso

El siguiente procedimiento resuelve de forma sistemática la colisión de nombres de sesión.

Paso	Acción	Herramienta / Comando	Objetivo
1	Listar las sesiones ETW activas y detener duplicados	`logman query` `logman stop "NombreDeSesión" -ets`	Eliminar la colisión para liberar el nombre.
2	Reiniciar el servicio WMI	`net stop winmgmt` `net start winmgmt`	Restablecer dependencias de trazas vinculadas a WMI.
3	Limpiar registros huérfanos en el Visor de eventos	`wevtutil el` `wevtutil cl "NombreDeRegistro"`	Borrar restos de sesiones que impiden iniciar una nueva.
4	Actualizar controladores de sensores o marcos de trabajo	Administrador de dispositivos → Actualizar controlador	Prevenir la reaparición del problema por drivers obsoletos.
5	Revisar directivas de grupo y tareas programadas	`gpedit.msc` y Programador de tareas	Detectar políticas o tareas que creen sesiones conflictivas.
6	Analizar más eventos relacionados	Visor de eventos → Microsoft ▸ Windows ▸ Kernel‑EventTracing	Obtener pistas adicionales si el error persiste.

Comandos Esenciales

A continuación se detallan los comandos clave con ejemplos prácticos:

:: Enumerar sesiones ETW
logman query -ets

:: Detener una sesión específica
logman stop "DiagLog" -ets

:: Búsqueda de sesiones colisionadas mediante findstr
logman query -ets | findstr /I "SensorFramework DiagLog"

:: Limpiar registro de eventos huérfanos
wevtutil cl "Microsoft-Windows-Kernel-EventTracing/Admin"

Automatización con PowerShell

En entornos de múltiples servidores resulta útil automatizar la detección y eliminación de sesiones conflictivas. El siguiente fragmento recorre cada servidor de una lista, identifica sesiones duplicadas y las detiene de forma segura:

# Requires&nbsp;PowerShell&nbsp;5.1&nbsp;+
$servers = @("SRV01","SRV02","SRV03")
$targetSessions = @("SensorFramework","DiagLog")

foreach ($srv in $servers) {
    Write-Host "➜&nbsp;Conectando a $srv..."
    Invoke-Command -ComputerName $srv -ScriptBlock {
        param($targetSessions)
        $active = logman query -ets
        foreach ($name in $targetSessions) {
            if ($active -match $name) {
                Write-Host " &nbsp;Deteniendo sesión $name"
                logman stop $name -ets
            }
        }
    } -ArgumentList $targetSessions -ErrorAction SilentlyContinue
}

Guarda el script como Clear-ETW.ps1 y prográmalo mediante schtasks para ejecutarse al reiniciar.

Buenas Prácticas y Prevención

Desactivar servicios innecesarios de sensores en hardware de servidor que no los utilice (GPOS, acelerómetros, etc.).
Incluir comprobaciones de existencia (Idempotency) cuando scripts de monitorización lancen sesiones ETW.
Aplicar la política “Start with Boot” solo a las sesiones críticas y evitar nombres genéricos.
Actualizar el sistema con los cumulative updates mensuales; muchos proveedores corrigen colisiones en controladores.
Auditar directivas de grupo que habiliten Device Health Attestation o Windows Defender Application Control, pues crean sus propias sesiones de diagnóstico.
Centralizar los registros en Log Analytics, Splunk u otra solución para simplificar la detección temprana.

Preguntas Frecuentes

¿Puedo simplemente deshabilitar Kernel‑EventTracing?
No es viable: forma parte del kernel y muchos subsistemas dependen de ETW. La estrategia correcta es evitar colisiones de nombre.

¿Eliminar el registro de eventos borra la sesión?
No; wevtutil cl limpia archivos .evtx, pero la sesión sigue viva mientras algún proceso la mantenga abierta.

¿Es mejor reiniciar el servidor?
Un reinicio borra las sesiones, pero es una solución temporal. Si la causa persiste (tarea, controlador), el error volverá.

¿Cómo diagnostico el proceso responsable?
Activa el canal Microsoft-Windows-Kernel-EventTracing/Diagnostic, incrementa el nivel a Verbose y usa Get-WinEvent o Event Viewer para identificar el PID que llama a StartTrace.

Conclusión

Resolver el evento Kernel‑EventTracing (ID 2) pasa por comprender cómo Windows gestiona las sesiones ETW, identificar la colisión y aplicar acciones correctivas permanentes: detener la sesión duplicada, reiniciar servicios de soporte, limpiar registros residuales y mantener controladores y políticas actualizados. Con la práctica recomendada y la automatización adecuada, evitarás que estos eventos saturen tus registros y mantendrás la capacidad de diagnóstico de la plataforma intacta.