Tutorial completo de netsh trace en Windows

Si trabajas con Windows y te toca pelearte con problemas de red, el comando netsh trace es una de esas herramientas que merece la pena tener siempre a mano. Permite capturar tráfico, registrar eventos internos del sistema y generar informes muy completos sin instalar nada extra, algo perfecto para entornos corporativos o equipos bloqueados donde no puedes usar Wireshark o herramientas similares.

A lo largo de este tutorial vamos a ver, con bastante detalle, cómo funciona netsh trace en Windows, qué hace cada subcomando, cómo usar los escenarios predefinidos, qué parámetros son realmente importantes para el día a día, cómo reducir el tamaño de los archivos de seguimiento con filtros y cómo sacar partido a los ficheros ETL y CAB que genera. La idea es que termines el artículo sabiendo no solo qué escribir en la consola, sino también por qué se usan determinadas opciones y qué esperar de cada una.

Qué es exactamente netsh trace y para qué sirve

El comando netsh trace forma parte de la utilidad de línea de comandos netsh.exe, presente en Windows desde hace muchos años. Dentro de netsh, el contexto trace se apoya en la infraestructura de Event Tracing for Windows (ETW) para registrar eventos muy detallados del sistema y, opcionalmente, capturar paquetes de red. Esto te da una visión muy profunda de lo que está ocurriendo en la pila de red y en otros componentes relacionados.

Con este comando puedes iniciar y detener sesiones de seguimiento, convertir los archivos ETL resultantes a otros formatos (TXT, CSV, XML, EVTX…), correlacionar varios seguimientos, exportar escenarios a perfiles de Windows Performance Recorder y mucho más. Todo lo hace sin instalar agentes ni herramientas adicionales, lo que lo convierte en un recurso clave para soporte, análisis forense o troubleshooting en servidores de producción.

En sistemas como Windows 7 y Windows Server 2008 R2 y versiones posteriores, esto significa que ya no es obligatorio montar herramientas como WireShark o Network Monitor para hacer una captura decente: puedes tirar de netsh trace desde una consola con privilegios de administrador y obtener tanto tráfico de red como un contexto amplio del estado del sistema durante la incidencia.

Sintaxis general del comando netsh trace

Subcomandos: netsh trace

El contexto de trazas de netsh expone una serie de subcomandos, todos ellos accesibles con una sintaxis base muy sencilla. A nivel general, la forma de invocarlo es algo así como netsh trace <subcomando> . Estos son los subcomandos más importantes que ofrece:

Convertir: netsh trace convert tracefilename.etl filename CSV|XML|EVTX|TXT|No yes|no yes|no yes|no pathname pathname

Correlación: netsh trace correlate tracefilename.etl newtracefilename.etl Activity_ID yes|no yes|no yes|no yes|no

Diagnóstico: netsh trace diagnose <scenarioname> <attributeValue> <yes|no> <yes|no> <yes|no>

Volcado: netsh trace dump

Exportar: netsh trace export <scenarioname> <filename>

Combinar: netsh trace merge

Restaurar: netsh trace postreset

Mostrar: netsh trace show <capturefilterhelp> <globalkeywordsandlevels> <helperclass> <helperclassname> <interfaces> <provider> <providerIdOrName> <providerfilerhelp> <providers> <scenario> <scenarioname> <scenarios> <status>

Inicio: netsh trace start =<sessionname> <scenario1,scenario2> keywords level yes|no] physical|vmswitch|both yes|no|disabled yes|no path\filename filemaxsize single|circular|append yes|no yes|no|disabled providerIdOrName keywordMaskOrSet level <bufferSize> provider2IdOrName yes|no keyword2MaskOrSet yes|no level2 ...

Con esto en mente, vamos a ir desgranando qué hace cada comando y qué parámetros te interesan realmente en el día a día, sin perder de vista los detalles avanzados que a veces marcan la diferencia cuando el problema es serio.

Subcomando convert: transformar archivos ETL a otros formatos

El comando netsh trace convert sirve para transformar un archivo de trazas ETL en otros formatos más fáciles de consultar o analizar con scripts. Además, puede generar un informe HTML completo y añadir metadatos extra si los necesitas para depuración avanzada.

La sintaxis base ya la hemos visto, pero merece la pena repasar qué significa cada parámetro importante de convert y cómo afecta al resultado final de la conversión.

input: indica el archivo ETL de entrada que quieres procesar. Es el fichero de traza generado previamente por una sesión de netsh trace start. Sin este parámetro no hay nada que convertir.

output: define el nombre y ruta del archivo de salida. Si no indicas nada, el comando utiliza el mismo nombre del archivo de entrada, con la extensión correspondiente al tipo de volcado que hayas elegido.

dump: especifica el formato del volcado que quieres generar: puedes elegir entre CSV, XML, EVTX, TXT o No. Si dejas el valor por defecto, el comando genera un volcado de texto estándar, muy útil para una revisión rápida o para cargar en herramientas sencillas.

report: determina si se genera o no un informe HTML a partir de la traza. Si lo pones a yes, obtendrás un archivo HTML con gráficos e información agregada que ayuda mucho en tareas de diagnóstico.

overwrite: controla si se pueden sobrescribir archivos existentes. Si lo fijas en yes, el comando reemplazará el archivo de salida si ya existía con el mismo nombre; con no se evitará esa sobrescritura.

metadata: indica si quieres incluir en el resultado seguimientos de metadatos. Al activarlo (yes) se añaden trazas adicionales de contexto que son útiles cuando trabajas con decodificación avanzada o con proveedores de tipo WPP.

tmfpath: aquí defines la ruta a los archivos TMF (Trace Message Format) que sirven para descodificar seguimientos generados por WPP (Windows software trace preprocessor). Es necesario si estás analizando proveedores WPP personalizados.

manpath: similar al anterior, pero apuntando a los archivos de manifiesto que describen eventos ETW clásicos. Ayuda a mostrar los eventos de forma legible cuando el sistema no tiene ya registrada toda la información del proveedor.

Subcomando correlate: filtrar y normalizar seguimientos

El comando netsh trace correlate permite tomar uno o varios archivos ETL y generar un nuevo archivo de salida filtrado o normalizado. Es especialmente útil cuando quieres centrarte en una actividad concreta identificada por un GUID de actividad, o cuando manejas trazas muy grandes y necesitas acotar la información.

La opción más interesante es filter, que te deja indicar un Activity_ID en formato GUID (por ejemplo {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}) y genera una nueva traza que solo contiene los eventos relacionados con ese identificador. Esto reduce de forma drástica el ruido cuando investigas una petición o una sesión muy concreta.

Además del filtro de actividad, hay otros parámetros que controlan qué tipo de información se mantiene en la traza resultante y qué se elimina, algo muy relevante en escenarios donde se manejan datos personales o información global del sistema.

retaincorrelationevents: si lo defines como yes, el nuevo archivo conserva los eventos de correlación utilizados internamente para enlazar eventos entre sí. Son útiles para reconstruir la secuencia lógica de una operación compleja.

retainpii: permite decidir si se mantienen eventos con datos de carácter personal (PII). Su valor por defecto suele ser yes, lo que conserva toda la información, pero en entornos sensibles podrías establecerlo a no para evitar exponer ciertos detalles.

retainglobalevents: controla si se conservan los eventos globales del sistema. De manera predeterminada suele estar activado, lo que ayuda a tener contexto de lo que pasaba en el equipo mientras sucedía el problema de red.

Subcomando diagnose: escenarios de diagnóstico guiado

El subcomando netsh trace diagnose está pensado para lanzar sesiones de diagnóstico automatizadas basadas en escenarios preconfigurados. En lugar de tener que elegir uno a uno los proveedores ETW, niveles y filtros, seleccionas un escenario como InternetClient y dejas que Windows habilite todo lo necesario.

El parámetro clave es scenario, donde indicas el nombre del escenario de diagnóstico que quieres ejecutar. Por ejemplo, para problemas de conectividad a Internet, escogerías InternetClient; para otros problemas pueden existir escenarios específicos de LAN, WLAN, FileSharing, DirectAccess, etc.

La opción namedAttribute sirve para pasar opciones adicionales específicas del escenario, por ejemplo detalles concretos que el propio escenario pueda utilizar para enfocar el diagnóstico. El conjunto de atributos disponibles cambia según el escenario seleccionado.

Con saveSessionTrace decides si la traza generada durante el diagnóstico se guarda para su análisis posterior. Suele estar ligada al parámetro report, que controla la generación de un informe. Si report=yes, lo habitual es que saveSessionTrace se active por defecto a yes para que tengas tanto el informe como la traza bruta.

El parámetro report permite activar la creación de un informe de diagnóstico al finalizar el escenario. Si lo pones a no, el sistema no generará ese informe, aunque la traza ETL se haya guardado según lo indicado en saveSessionTrace.

Finalmente, la opción capture decide si además del registro de eventos ETW quieres capturar tráfico de red real durante el diagnóstico. Con capture=yes conseguirás paquetes de red en el ETL, a costa de generar un archivo más voluminoso y potencialmente más sensible.

Otros subcomandos clave: dump, export, merge, postreset, show y help

Más allá de los comandos de inicio de sesión, conversión y diagnóstico, netsh trace incluye otros subcomandos que conviene conocer porque facilitan la administración de la configuración de trazas o el análisis posterior de los datos.

Uso dump: netsh trace dump

Uso export: netsh trace export

Uso merge: netsh trace merge

Uso postreset: netsh trace postreset

Detalles show: netsh trace show

El clásico help o ? dentro del contexto trace muestra la lista de comandos y sus descripciones en ese contexto concreto, algo que siempre viene bien cuando no recuerdas la sintaxis exacta de un parámetro o quieres ver qué opciones nuevas hay en la versión de Windows que estás usando.

Subcomando start: iniciar una sesión de seguimiento de red

El corazón de todo el sistema es netsh trace start, que se encarga de poner en marcha una sesión de trazas. Aquí es donde eliges escenario, activas o no la captura de paquetes, defines el archivo de salida, el tamaño máximo, el modo de archivo y un montón de opciones avanzadas para ajustar el nivel de detalle.

Uno de los parámetros clave es sessionname, que te permite asignar un nombre identificativo a la sesión. No es obligatorio, pero ayuda a distinguir entre distintas sesiones cuando revisas la configuración o el estado con netsh trace show status.

Con scenario puedes seleccionar uno o varios escenarios predefinidos de diagnóstico, como LAN, InternetClient, FileSharing o DirectAccess. Un escenario no es más que un conjunto de proveedores ETW y configuraciones pensadas para un tipo de problema concreto, y te ahorra tener que ir proveedor a proveedor.

Los parámetros globalKeywords y globalLevel controlan el filtro global de eventos que se aplicará a todos los proveedores. globalKeywords define qué «palabras clave» ETW se tienen en cuenta, mientras que globalLevel fija el nivel mínimo de severidad o detalle que quieres registrar.

El valor de globalLevel suele ir de 1 a 5, cada uno con un significado bastante claro:

• 1 (Crítico): solo se registran eventos críticos, típicamente fallos graves.
• 2 (Error): incluye eventos críticos y errores.
• 3 (Advertencia): añade advertencias a los críticos y errores.
• 4 (Informativo): añade eventos de tipo informativo.
• 5 (Detallado): registra absolutamente todos los eventos, incluido el detalle de depuración.

Si activas capture a yes, la sesión no solo grabará eventos ETW, sino también paquetes de red reales. Puedes controlar el ámbito de esa captura con capturetype, que acepta valores como physical (adaptadores físicos), vmswitch (switches virtuales de Hyper-V) o both si quieres abarcarlo todo.

Con el parámetro report decides si el sistema debe generar un informe HTML al finalizar la sesión. Los valores típicos son yes, no o disabled, según si quieres siempre informe, nunca, o dejar esta funcionalidad completamente desactivada.

La opción persistent es especialmente interesante en diagnósticos largos, porque permite que la sesión de seguimiento sobreviva a un reinicio del equipo. Si la activas con persistent=yes, la traza continuará tras el reinicio hasta que la detengas de forma explícita con netsh trace stop.

Con traceFile estableces la ruta y nombre del archivo ETL donde se va a almacenar la traza, por ejemplo traceFile=C:\Logs\networktrace.etl. Si no lo indicas, se utilizan nombres por defecto como nettrace.etl en el directorio de trabajo actual.

El parámetro maxSize fija el tamaño máximo en MB del archivo ETL. Está muy ligado al parámetro fileMode, que define cómo se comporta el archivo cuando se alcanza ese tamaño máximo: single (un único archivo hasta llegar al límite), circular (se sobrescriben los datos más antiguos, actuando como un buffer circular) o append (se van añadiendo datos al final de un archivo ya existente).

La opción overwrite controla si se puede sobrescribir un archivo ETL ya existente. Si quieres asegurarte de no perder trazas antiguas por error, puedes dejarla en no; si prefieres que siempre se use el mismo nombre de archivo y se reemplace cuando toque, la pones en yes.

Con correlation decides si se habilita o no la correlación de eventos dentro de la traza, lo que puede ayudar a reconstruir cadenas de llamadas o flujos de trabajo complejos. Los valores posibles son yes, no o disabled, según el grado de soporte que quieras.

Las capturefilters permiten aplicar filtros específicos a los paquetes capturados, por ejemplo para limitar el tráfico a una dirección IP, un puerto TCP, un protocolo concreto, etc. Esto reduce el volumen de datos y centra el análisis en lo que realmente te interesa.

Los parámetros provider, keywords y level te dejan afinar aún más la traza a nivel de proveedor ETW individual. Puedes indicar un proveedor concreto por GUID o por nombre, asignarle un conjunto de palabras clave y un nivel de detalle distinto al global, y repetir esta combinación para varios proveedores dentro de la misma sesión.

El ajuste bufferSize determina el tamaño del buffer de seguimiento en memoria. Un buffer pequeño puede provocar pérdidas de eventos en escenarios de alta carga, mientras que un buffer demasiado grande puede consumir más memoria de la cuenta, así que conviene ajustarlo según el entorno.

Por último, providerFilter y perfMerge añaden un extra de control: el primero activa filtros específicos de proveedor (cuando los hay disponibles), y el segundo indica si se deben combinar los datos de rendimiento con la traza principal, lo cual es muy útil al analizar cuellos de botella o problemas de rendimiento de red.

Ejemplos prácticos de uso de netsh trace

Para ver en la práctica cómo se aplican todos estos parámetros, merece la pena revisar algunos comandos reales que puedes usar como plantilla. A partir de ellos, es fácil ajustar pequeñas cosas para adaptarlos a tu entorno.

Ejemplo Convertir: netsh trace convert input="C:\Logs\mytrace.etl" output="C:\Logs\mytrace.xml" dump=XML

Ejemplo Correlacionar: netsh trace correlate input="C:\Logs\trace1.etl,C:\Logs\trace2.etl" output="C:\Logs\correlated_trace.etl"

Crear TXT: netsh trace convert input="C:\Logs\mytrace.etl" output="C:\Logs\mytrace.txt" dump=TXT

Ejemplo Merge: netsh trace merge input="C:\Logs\trace1.etl,C:\Logs\trace2.etl" output="C:\Logs\merged_trace.etl"

Listar interfaces: netsh trace show interfaces

Iniciar sesión: netsh trace start capture=yes tracefile="C:\Logs\networktrace.etl" report=yes persistent=yes

Escenarios, persistencia y registro circular en Windows 7/2008 R2 y posteriores

En entornos como Windows 7 y Windows Server 2008 R2 ya no es imprescindible recurrir a herramientas externas para analizar el tráfico. Con una consola de administrador, basta con ejecutar algo del estilo de netsh trace start con los parámetros adecuados para tener una captura útil, incluso de forma persistente. También sirven para analizar el arranque de Windows cuando se combinan con herramientas específicas del sistema.

Ejecutar: C:\Windows\system32> netsh trace start capture=YES report=YES persistent=YES

Detener: C:\Windows\system32> netsh trace stop

Cuando ya no necesites seguir registrando información, detienes la monitorización con:

Al terminar, se generan por defecto dos archivos muy importantes: un fichero con extensión .ETL (Event Trace Log), que es donde se almacenan los eventos y paquetes, y un archivo .CAB que agrupa información adicional, como detalles del hardware, adaptadores de red, versión del sistema operativo y configuración inalámbrica.

El uso de netsh trace para «esnifar» tráfico resulta especialmente práctico en análisis forense o en equipos en los que no está permitido instalar software nuevo. Además de ser cómodo, ofrece ventajas como la posibilidad de configurar trazas persistentes que sobreviven a reinicios y la opción de usar modo de registro circular, con el que puedes dejar una sesión activa indefinidamente hasta que ocurra el evento que buscas, sin que el archivo de traza crezca sin límites.

Otro punto fuerte son los escenarios específicos predefinidos. Con comandos como netsh trace show scenarios puedes ver qué escenarios de red tienes disponibles, y después iniciar una traza orientada a un caso concreto, por ejemplo:

netsh trace start scenario=InternetClient

Si quieres ampliar aún más la información, puedes combinar varios escenarios o añadir proveedores individuales a un escenario principal. Por ejemplo, para seguir el escenario wlan y, además, el proveedor de cliente DHCP:

netsh trace start scenario=wlan provider=Microsoft-Windows-Dhcp-Client

Para profundizar en un proveedor concreto y ver qué palabras clave y niveles expone, puedes usar:

netsh trace show provider Microsoft-Windows-TCPIP

Consulta ayuda: netsh trace start /?

Archivos de salida: ETL, CAB y reportes HTML

Cuando detienes una sesión de trazas, Windows genera al menos dos tipos de archivo. Por un lado, el archivo ETL principal (por defecto nettrace.etl, a menos que hayas definido otro nombre con tracefile=), que contiene los eventos ETW y, si activaste captura, los paquetes de red.

Ese ETL puede abrirse con varias herramientas de análisis, como el antiguo Network Monitor, Windows Performance Analyzer o incluso PowerShell usando Get-WinEvent para extraer información de manera programática. Además, a través de netsh trace convert puedes obtener versiones CSV, XML, EVTX o TXT para procesarlo con otros sistemas.

Por otro lado, tienes el archivo .CAB, normalmente llamado por defecto nettrace.cab. Este archivo incluye información enriquecida del sistema, como datos de hardware, adaptadores de red, versiones de sistema operativo, parámetros inalámbricos y, en general, todo aquello que proporciona contexto al diagnóstico. Dentro de ese CAB suelen aparecer un Report.etl (copia de la información principal) y un report.html con un informe generado si activaste report=yes al iniciar la sesión.

Para obtener la mayor cantidad de detalle posible en este informe, es recomendable arrancar la traza con generación de reportes activada, algo tan sencillo como añadir report=yes al comando netsh trace start. De esa forma, al cerrar la sesión tendrás no solo la traza bruta en ETL, sino un análisis consolidado mucho más legible para una primera revisión.

Uso de filtros para reducir el tamaño y el ruido de las trazas

Cuando dejas una captura funcionando durante mucho tiempo o cuando habilitas varios proveedores ETW de golpe, el resultado suele ser un archivo ETL enorme. Esto no solo complica la revisión manual, sino que además puede provocar pérdida de eventos si los buffers de ETW se saturan. Por eso es tan importante aprender a jugar con los filtros que ofrece netsh trace.

Por un lado, tienes los niveles y palabras clave de ETW que comentábamos antes, tanto a nivel global como por proveedor. Al reducir el nivel (por ejemplo, de 5 Detallado a 3 Advertencia), o al filtrar por solo algunas palabras clave, limitas drásticamente el número de eventos registrados.

Ayuda filtros: netsh trace start /?

Un ejemplo típico de filtro avanzado sería algo como:

netsh trace start scenario=InternetClient provider=Microsoft-Windows-TCPIP level=5 keywords=ut:ReceivePath,ut:SendPath

Aquí estás diciendo al sistema que trace el escenario InternetClient, pero que, para el proveedor Microsoft-Windows-TCPIP, utilice nivel 5 (Detallado) y solo registre eventos asociados a las palabras clave ut:ReceivePath y ut:SendPath. Esto deja fuera muchos eventos de ese proveedor que no sean de recepción o envío, reduciendo ruido sin perder detalle donde interesa.

Los niveles disponibles para este y otros proveedores siguen la misma lógica general (Crítico, Errores, Advertencias, Informativo, Detallado), de modo que puedes combinarlos con palabras clave específicas para afinar aún más. La lista completa de palabras clave soportadas por un proveedor se obtiene con netsh trace show provider <nombre>.

Además del filtrado basado en eventos ETW, netsh trace también soporta filtros de paquetes, similares a los de Network Monitor, siempre que la captura de paquetes esté activada con capture=yes. Por ejemplo, para limitar la captura a tráfico IPv4 relacionado con una determinada dirección IP:

netsh trace start capture=yes ipv4.address=x.x.x.x

Con este filtro solo se registrarán paquetes IPv4 cuyo origen o destino coincida con la IP especificada, lo que viene genial cuando quieres seguir tráfico de un host concreto sin que el resto de la red «ensucie» el archivo ETL.

Si necesitas profundizar en el lenguaje de filtros de paquetes, puedes lanzarte directamente a:

Filtro ayuda: netsh trace show capturefilterHelp

Ahí encontrarás una descripción de los filtros válidos y ejemplos de uso para distintos protocolos y campos, desde filtros simples de IP o puerto hasta condiciones más complejas. Dominar estos filtros te permite dejar sesiones largas en marcha sin miedo a que el archivo se vuelva inmanejable.

Visualización y análisis avanzado de las trazas ETL

Una vez que tienes los archivos ETL y CAB generados, el siguiente paso es analizar realmente la información. Aquí entran en juego herramientas como Network Monitor, Windows Performance Analyzer o incluso Wireshark, aunque en algunos entornos puede que no tengas permiso para instalarlas.

Si tienes acceso a Network Monitor (o al analizador de tráfico integrado en algunas versiones de Windows), puedes abrir el ETL con el parser de Windows para ver los paquetes y eventos de forma más estructurada, con campos decodificados que facilitan entender qué está pasando en cada flujo de red.

En escenarios donde quieras usar Wireshark, una opción es convertir el ETL a un formato CAP compatible mediante Microsoft Message Analyzer (en su momento disponible como Beta 3). Tras la conversión, podrás cargar el archivo en Wireshark y aprovechar todos sus filtros y funcionalidades de análisis de protocolos avanzados.

Si, por el contrario, estás en entornos muy restringidos donde no puedes instalar nada, todavía te queda la opción de sacar partido a netsh trace convert y a PowerShell. Por ejemplo, puedes convertir la traza a EVTX o CSV y luego usar Get-WinEvent o cmdlets de importación de CSV para trabajar con los datos desde scripts, filtrando eventos por campos, tiempos, etc.

Es importante tener en cuenta que, si en tus análisis ves mensajes del tipo «Fragmento de paquete (54 bytes)» sin campos como IP de origen o destino, puede que el problema sea que la traza no se ha capturado con capture=yes o que el proveedor usado (como Microsoft-Windows-NDIS-PacketCapture) requiere herramientas específicas para decodificar por completo el contenido. En muchos casos, combinar capture=yes con filtros de paquetes bien definidos y después volcar a un formato adecuado (como CAP o un TXT bien estructurado) soluciona esa falta aparente de detalle.

netsh trace es una navaja suiza para diagnosticar redes en Windows: ofrece captura de paquetes sin software adicional, escenarios predefinidos para distintos tipos de problemas, opciones de persistencia y registro circular para no perder el momento crítico, filtros potentes para mantener a raya el tamaño de los archivos y comandos de conversión y correlación que facilitan el análisis posterior, ya sea con herramientas gráficas, scripts o una mezcla de ambos.