WPR/WPA en la práctica — Introducción al análisis de rendimiento del sistema para «todo el PC va lento»

«Después de instalar una aplicación nueva, dicen que todo el PC se volvió lento. Pero al mirar el Administrador de tareas, hay margen tanto de CPU como de memoria.» «Hay un solo PC que tarda tres minutos en arrancar. No hay forma de saber qué está mal.» Este tipo de consulta relacionada con el rendimiento es extremadamente frecuente. Lo que tienen en común es que mirar un proceso concreto no da la respuesta.

Las herramientas para un proceso concreto ya existen. El acceso a archivos y al registro se puede ver con Process Monitor, y la CPU o el GC de una aplicación .NET se pueden seguir con PerfView. Pero síntomas como «todo el PC va lento» o «la CPU está ociosa y aun así va lento» empiezan sin siquiera saber qué proceso es el culpable. La lentitud de la aplicación A podría deberse a un análisis del antivirus, a una escritura masiva en disco de otro servicio, o a una cadena de bloqueos que atraviesa varios procesos. Lo que hace falta no es mirar dentro de un proceso, sino datos registrados de todo el sistema operativo en un único eje temporal.

Las herramientas para capturar y leer esos datos son Windows Performance Recorder (WPR) y Windows Performance Analyzer (WPA). WPR registra el comportamiento de todo el sistema operativo basándose en ETW (Event Tracing for Windows), y WPA analiza ese registro mediante gráficos y tablas. Quién usó la CPU y con qué pila de llamadas, a quién estaba esperando cada subproceso, qué proceso emitió E/S de disco sobre qué archivo: todos estos hechos, uno o dos niveles por debajo de lo que muestra el Administrador de tareas, quedan registrados por completo con marca de tiempo.

Este artículo se dirige a los responsables de sistemas de pequeñas y medianas empresas y a los desarrolladores de aplicaciones Windows, y organiza, con base en fuentes primarias vigentes en agosto de 2026, la práctica de la captura con WPR y la forma de leer WPA — en particular, la diferencia entre investigar «cuando la CPU está alta» e investigar «cuando la CPU está baja pero el sistema va lento».

1. Conclusión por adelantado

• La opción principal para investigar el tipo «todo el PC va lento» es WPR/WPA, capturando y leyendo una traza ETW de todo el sistema operativo. Incluso los problemas que no se pueden identificar con herramientas centradas en un proceso (Administrador de tareas, Procmon, PerfView) se pueden rastrear si se observan todos los procesos y el kernel en un único eje temporal.¹²
• La herramienta de captura wpr.exe viene integrada de serie en Windows 8.1 y versiones posteriores. Se puede usar sin instalar nada adicional. La versión gráfica (WPRUI) y la herramienta de análisis WPA forman parte del Windows ADK.¹²
• El procedimiento básico son tres líneas. Con permisos de administrador: wpr -start GeneralProfile -filemode → reproducir el evento → wpr -stop C:\temp\trace.etl. Basta con memorizar esto para empezar a capturar.³
• El reparto básico en el terreno es «en el entorno del cliente solo se captura con wpr.exe, y la lectura se hace con el WPA propio». Esto permite capturar incluso en servidores donde no se puede instalar software. Es la misma idea que en la captura de paquetes: «se captura con la herramienta estándar, se lee con Wireshark».¹
• El punto de partida para leer WPA es clasificar entre «CPU, espera o E/S». Si la CPU está al límite, se usa CPU Usage (Sampled); si la CPU está ociosa pero el sistema va lento, se usa el análisis de esperas de CPU Usage (Precise); si se sospecha del disco, se usa Disk Usage. El camino se bifurca desde el primer paso.⁴⁵
• CPU Usage (Sampled) muestrea aproximadamente cada milisegundo y muestra «qué función usó la CPU». Permite descomponer ese «50 %» del Administrador de tareas descendiendo desde el proceso hasta el subproceso, la pila de llamadas y la función.⁶
• CPU Usage (Precise) es el registro completo de los cambios de contexto y permite saber «a quién estaba esperando cada subproceso». Seguir la cadena de Waits (tiempo de espera), ReadyingProcess (quién lo despertó) y ReadyThreadStack (la pila de quien lo despertó) es la técnica que este artículo más quiere transmitir.⁴⁷
• Para leer las pilas de llamadas hace falta configurar los símbolos. De forma predeterminada, WPA consulta el servidor público de símbolos de Microsoft. Para ver también los nombres de función de la aplicación propia, hay que añadir la ruta a sus PDB.⁸
• El archivo ETL contiene información interna del sistema, como nombres de proceso y rutas de archivo. Limite la captura a lo estrictamente necesario y decida de antemano cómo se tratará si va a entregarse fuera de la organización.

2. El papel de cada herramienta — WPR captura, WPA lee

Windows Performance Toolkit (WPT) es el conjunto de herramientas de investigación de rendimiento incluido en el Windows ADK (Windows Assessment and Deployment Kit), cuyo núcleo son WPR y WPA.² Sus funciones están claramente diferenciadas.

• WPR (Windows Performance Recorder) = captura. Agrupa los proveedores de ETW en unidades llamadas «perfiles», inicia y detiene el registro, y genera el archivo ETL. La versión de línea de comandos, wpr.exe, viene integrada de serie en Windows 8.1 y versiones posteriores, sin necesidad de instalación adicional. La versión gráfica (WPRUI.exe) forma parte del ADK.¹
• WPA (Windows Performance Analyzer) = análisis. Abre el archivo ETL y lo analiza mediante gráficos y tablas. Requiere instalar el ADK.²

Es decir, no hace falta instalar nada en el entorno del cliente. Se captura con el wpr.exe estándar del sistema operativo, se lleva el archivo ETL y se lee con el WPA del propio equipo — el mismo reparto que en la captura de paquetes: «se captura con pktmon y se lee con Wireshark».

flowchart LR
    accTitle: Reparto entre capturar con WPR y leer con WPA
    accDescr: En el entorno del cliente se registra con el wpr.exe estándar del sistema para crear el archivo ETL, que se lleva luego para analizarlo con WPA instalado mediante el ADK en el propio equipo
    subgraph customer["Entorno del cliente (sin instalación adicional)"]
        wpr["wpr -start → reproducir el evento → wpr -stop"] --> etl["Archivo ETL"]
    end
    subgraph office["Equipo propio (WPA instalado con el ADK)"]
        wpa["Análisis con gráficos y tablas en WPA"]
    end
    etl -->|"se lleva"| wpa

Antes de continuar, conviene aclarar cómo diferenciar estas herramientas de otras similares.

Si Procmon es el registro de operaciones de «qué se hizo» y PerfView es «qué ocurrió dentro de .NET», WPA es la herramienta que audita, de forma transversal a todos los procesos, «dónde se consumió el tiempo». Por su parte, el funcionamiento del propio ETW y la forma de instrumentar una aplicación propia con ETW se tratan en «Introducción al registro de eventos de Windows y ETW». Si la aplicación propia emite eventos ETW, esos hitos quedan registrados junto con la traza, lo que facilita enormemente el cruce de información. Sin embargo, WPR solo registra los eventos de los proveedores habilitados en el perfil de registro elegido. Como GeneralProfile no incluye el proveedor propio, si se quiere combinarlos hay que preparar un perfil de registro personalizado (.wprp) que habilite el proveedor propio y usarlo junto al anterior indicando el nombre del perfil dentro del archivo .wprp con !, como en wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile³.

3. La práctica de la captura (WPR) — iniciar, reproducir, detener

Estos son los pasos básicos en una terminal con permisos de administrador.

:: Lista de los perfiles integrados disponibles
wpr -profiles

:: 1. Iniciar la captura (perfil general, modo archivo)
wpr -start GeneralProfile -filemode

:: 2. Reproducir el evento (para consultar el estado durante la captura, use wpr -status)

:: 3. Detener y guardar (se puede adjuntar una descripción del problema).
::    Cree de antemano la carpeta de destino (si no existe, -stop falla al guardar)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproducción del evento: todo el PC se vuelve lento mientras arranca la aplicación X"

:: Si se cancela a mitad de camino, se descarta sin guardar
wpr -cancel

Lo que se indica en -start es el perfil, un conjunto de proveedores de ETW necesarios para esa investigación.³ Basta con recordar los que se usan con más frecuencia.⁹

Se pueden indicar varios perfiles a la vez encadenando -start (por ejemplo, wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: Flujo de captura con WPR y cómo elegir el modo
    accDescr: Los eventos que se pueden reproducir a voluntad se capturan en modo archivo, de forma corta y segura. Los eventos que pueden ocurrir en cualquier momento se esperan con el búfer circular del modo memoria (predeterminado). Los eventos durante el arranque o el inicio de sesión usan la traza de arranque. En todos los casos el procedimiento de iniciar, reproducir y detener es el mismo
    q{"¿Cuándo ocurre el evento?"}
    q -->|"Se puede reproducir a voluntad"| file["Captura corta y segura con -filemode"]
    q -->|"No se sabe cuándo ocurrirá"| mem["Espera con el modo memoria (predeterminado, búfer circular, apartado 3.1)"]
    q -->|"Durante el arranque o el inicio de sesión"| boot["Traza de arranque (capítulo 8)"]
    file --> s1["wpr -start → reproducir el evento → wpr -stop"]
    mem --> s1

3.1. Modo Memory y modo File — ¿se puede reproducir o hay que esperar?

WPR tiene dos modos de destino para el registro, y el predeterminado es el modo Memory (búfer circular en memoria). Al ser un búfer circular donde se sobrescriben primero los eventos más antiguos, es adecuado para dejar la captura corriendo a la espera de un evento que puede ocurrir en cualquier momento y detenerla cuando ocurre. Al añadir -filemode se pasa al modo File, en el que todo se registra en un archivo continuo. A cambio de no perder nada por sobrescritura, su único límite es el espacio libre en disco, por lo que el archivo puede crecer sin límite.¹⁰

flowchart LR
    accTitle: Cómo registran los eventos el modo Memory y el modo File
    accDescr: El modo Memory graba en un búfer circular en memoria, donde se sobrescriben los eventos más antiguos y solo queda lo más reciente, por lo que es adecuado para esperar. El modo File conserva todo en un archivo, con el espacio libre en disco como único límite, y es adecuado para reproducciones cortas y seguras
    ev["Flujo de eventos ETW"] --> ring["Modo Memory: búfer circular (se sobrescribe del más antiguo → solo queda lo más reciente)"]
    ev --> filem["Modo File: todo queda en un archivo (límite = espacio libre en disco)"]
    ring -.-> use1["Adecuado para esperar un evento que puede ocurrir en cualquier momento"]
    filem -.-> use2["Adecuado para eventos que se pueden reproducir de forma corta y segura"]

Estos son los criterios orientativos para elegir uno u otro.

• Se puede reproducir en el momento → modo File. Iniciar justo antes de reproducirlo, detener justo después, y mantener la captura dentro de unos pocos minutos
• No se sabe cuándo ocurrirá → esperar en modo Memory (predeterminado). En cuanto ocurra, ejecutar wpr -stop de inmediato
• Incluso unos pocos minutos con GeneralProfile pueden generar un ETL de varios cientos de MB o incluso GB. Como un archivo demasiado grande puede llegar a no poder analizarse en WPA, la idea de que «cuanto más tiempo se capture, mejor» resulta contraproducente.¹⁰¹¹

Si se captura desde la interfaz gráfica, basta con iniciar WPRUI, elegir el perfil y el Logging mode, y pulsar Start/Save. El procedimiento detallado está recogido en la guía oficial How-to.¹¹ Incluso cuando se pide a un responsable del cliente que haga la captura, los tres comandos anteriores se pueden usar tal cual como instructivo.

4. Fundamentos para leer WPA — gráficos, la regla de oro de las tablas y el acotado de tiempo

Al abrir el ETL capturado en WPA, en el panel Graph Explorer de la izquierda aparecen las miniaturas de los gráficos agrupadas en categorías como System Activity, Computation, Storage y Memory.¹² Al arrastrar el gráfico que se quiere ver hacia la pestaña Analysis de la derecha, se muestra el gráfico arriba y la tabla abajo. Al principio basta con dominar tres cosas.

1. La regla de oro de las tablas — el orden de las columnas determina el agrupamiento. Las tablas de WPA tienen dos barras verticales, una dorada y otra azul: las columnas a la izquierda de la barra dorada, en el orden en que están colocadas, jerarquizan (agrupan) los datos, y las columnas a la derecha de la barra azul son los valores agregados.¹³ Si se ordena «Process → Stack» se obtiene el agregado de pilas por proceso; si se ordena «Stack → Process» se obtiene el agregado de todos los procesos que usan la misma pila: el propio hecho de arrastrar y reordenar columnas es una operación de análisis. Entender solo este punto hace que todas las tablas de WPA se lean de la misma manera.

flowchart LR
    accTitle: La regla de oro de las tablas — las dos barras y el papel de las columnas
    accDescr: El orden de las columnas a la izquierda de la barra dorada jerarquiza los datos. Entre la barra dorada y la azul están las columnas visibles, y a la derecha de la barra azul están los valores agregados. Arrastrar y reordenar columnas es en sí mismo una operación de análisis
    left["Izquierda de la barra dorada: columnas de agrupamiento (el orden = la jerarquía)"] --> gold["Barra dorada"]
    gold --> mid["Entre las barras: columnas visibles"]
    mid --> blue["Barra azul"]
    blue --> right["Derecha de la barra azul: valores agregados (Sum, %, etc.)"]
    left -.-> op["Arrastrar columnas = operación de análisis (Process→Stack da el agregado de pilas por proceso)"]

1. Acotar el rango de tiempo. Se selecciona un rango arrastrando sobre el gráfico y, con clic derecho, se elige «Zoom» para pasar a un agregado limitado a ese intervalo. El principio de la investigación de rendimiento es observar siempre únicamente el «intervalo en que ocurrió el evento» (capítulo 9).
2. Configurar los símbolos. Para leer las pilas de llamadas por nombre de función, ejecute Trace > Load Symbols en el menú.¹⁴ Como de forma predeterminada se consulta el servidor público de símbolos de Microsoft (msdl.microsoft.com), las pilas del propio Windows se pueden resolver con conexión a internet. Para ver también los nombres de función de la aplicación propia, añada la carpeta de sus PDB en Trace > Configure Symbol Paths.⁸ Qué son los PDB y por qué conviene conservarlos siempre, incluso en compilaciones de lanzamiento, se explica en «Qué es un PDB (base de datos de programa)». Para las imágenes nativas NGen de .NET Framework, WPR genera durante la captura un PDB para NGen (.ngenpdb) y lo coloca en una carpeta junto a la traza, que WPA consulta automáticamente.⁸ Este es un mecanismo exclusivo para las imágenes NGen; no cubre el código propio de una aplicación .NET normal que se ejecuta con JIT. La correspondencia entre las direcciones de código JIT y los nombres de función se resuelve a partir de los eventos JIT que emite el CLR, así que, al investigar una aplicación .NET, prepare un perfil de registro (.wprp) que habilite el proveedor del CLR (Microsoft-Windows-DotNETRuntime y su Rundown) y combínelo del mismo modo que el proveedor propio del capítulo 3, con la forma wpr -start GeneralProfile -start MyDotNet.wprp!NombreDePerfil, para incluir los eventos del CLR en la traza (los perfiles integrados disponibles en su WPR se pueden consultar con wpr -profiles). Además, para poder relacionar la información con las líneas de código fuente, conserve el PDB generado en la compilación y añádalo a la ruta de símbolos indicada arriba.

flowchart TB
    accTitle: Resolución de símbolos para leer las pilas por nombre de función
    accDescr: Al ejecutar Trace Load Symbols, el propio Windows se resuelve desde el servidor público de símbolos de Microsoft, y la aplicación propia desde el PDB de compilación añadido a la ruta de símbolos. Las imágenes NGen se resuelven con el PDB para NGen que genera WPR, y el código .NET JIT con los eventos JIT del CLR dentro de la traza más el PDB de compilación
    load["Trace > Load Symbols"] --> ms["Windows propio: servidor público de símbolos (msdl)"]
    load --> own["Aplicación propia: PDB de compilación añadido en Configure Symbol Paths"]
    load --> ngen["Imagen NGen de .NET Framework: .ngenpdb generado por WPR"]
    load --> jit["Código .NET JIT: eventos JIT del CLR en la traza + PDB de compilación"]

Con esto preparado, se entra en la siguiente bifurcación: en ese intervalo, ¿la CPU estuvo alta o baja? Si estuvo alta, continúe con el capítulo 5 (Sampled); si estuvo baja pero el sistema iba lento, continúe con el capítulo 6 (Precise).

flowchart TB
    accTitle: Bifurcación para elegir el gráfico de WPA según el síntoma
    accDescr: Se hace zoom en el intervalo del evento. Si la CPU está alta se va a CPU Usage Sampled. Si está baja pero el sistema va lento, se comprueba si hay un núcleo o subproceso saturado y se pasa al análisis de esperas de CPU Usage Precise. Si se sospecha del disco, se va a Disk Usage y File I/O
    zoom["Zoom en el intervalo del evento"] --> cpu{"¿Cómo está la CPU en ese intervalo?"}
    cpu -->|"Alta"| sampled["Capítulo 5: CPU Usage (Sampled) para «quién quema CPU en qué función»"]
    cpu -->|"Baja pero va lento"| core{"¿Hay un núcleo o subproceso saturado?"}
    core -->|"Sí"| sampled
    core -->|"No"| precise["Capítulo 6: CPU Usage (Precise) para «qué se estaba esperando»"]
    cpu -->|"Se sospecha del disco"| disk["Capítulo 7: identificar al culpable con Disk Usage / File I/O"]

5. Cuando la CPU está alta — quién quema CPU y en qué función, con CPU Usage (Sampled)

Si la CPU está saturada, lo que hay que mirar es CPU Usage (Sampled). Son datos de muestreo que registran, en todas las CPU y aproximadamente cada milisegundo, «qué pila de llamadas de qué proceso se está ejecutando en ese momento»; la proporción del número de muestras se convierte directamente en el desglose del tiempo de CPU.⁶

flowchart LR
    accTitle: Cómo funciona CPU Usage Sampled
    accDescr: Aproximadamente cada milisegundo se registra en todas las CPU la pila en ejecución, y la proporción agregada de muestras se convierte en el desglose del tiempo de CPU. Se lee descendiendo de proceso a subproceso, pila y función. La actividad breve que termina entre muestras no queda registrada
    tick["Interrupción aproximadamente cada 1 ms"] --> snap["Se registra la «pila en ejecución en ese momento» en todas las CPU"]
    snap --> agg["Se agregan las muestras (proporción = desglose del tiempo de CPU)"]
    agg --> drill["Se desciende: Process → Thread → Stack → función"]
    snap -.-> miss["La actividad breve que termina entre muestras no queda registrada"]

1. Arrastre CPU Usage (Sampled), desde la categoría Computation de Graph Explorer, hasta la pestaña Analysis, y elija el preajuste Utilization by Process, Stack.⁵
2. Revise los procesos en orden descendente de Weight (o Count). Así se identifica, primero a nivel de proceso, qué era en realidad ese «50 %» del Administrador de tareas.
3. Expanda la columna Stack del proceso culpable. Las pilas están agregadas en forma de árbol, y si desciende por el camino en el que el número no baja mucho en cada bifurcación, llegará a la función que está quemando CPU. Si los símbolos están resueltos, el camino lleva directamente hasta la función concreta del código propio.
4. Si expandir el árbol resulta engorroso, cambie la vista del gráfico a Flame (gráfico de llama). Como el ancho horizontal representa la proporción del tiempo de CPU, se ve de un vistazo qué ruta de llamadas domina. CPU Usage (Sampled) también incluye un preajuste llamado Flame by Process, Stack.¹³

Hay una sola advertencia. Al tratarse de un muestreo, la actividad breve que termina entre una muestra y la siguiente no queda registrada.⁶ Recuerde que es una herramienta para ver «dónde se usó la CPU en total», no para medir con precisión el tiempo de ejecución de cada evento individual.

6. Cuando la CPU está baja pero el sistema va lento — CPU Usage (Precise) y el análisis de esperas

Aquí está el núcleo de este artículo. Sin embargo, antes de pasar al análisis de esperas hay algo que conviene comprobar: «que el uso global de CPU sea bajo» no significa «que la CPU no sea el cuello de botella». En un PC de 16 núcleos, un procesamiento en serie saturado en un solo núcleo (por ejemplo, un único subproceso de interfaz de usuario girando a máxima velocidad) apenas se ve como un 6 % en el total. Primero compruebe, con el Sampled del capítulo 5 (o con Utilization by CPU de CPU Usage (Precise)), si hay algún núcleo o subproceso concreto saturado; si tampoco es el caso, pase a este capítulo — el procesamiento no es que no pueda avanzar, es que está esperando. Lo que indica qué se está esperando es CPU Usage (Precise).

Mientras que Sampled es un muestreo, Precise es el registro completo de los cambios de contexto (cambios de subproceso). El subproceso entra en espera, alguien lo despierta (Ready) y pasa a la CPU: este ciclo queda registrado línea por línea, y se pueden leer las siguientes columnas.⁷⁴

flowchart LR
    accTitle: Un ciclo de espera y su correspondencia con cada columna
    accDescr: El subproceso entra en espera con la pila que queda en NewThreadStack y espera durante el tiempo de Waits. Cuando alguien lo despierta, ese responsable queda registrado en ReadyingProcess y ReadyThreadStack, y espera el tiempo de Ready por la disputa de la CPU antes de volver a ejecutarse
    run1["En ejecución"] -->|"Entra en espera (queda en NewThreadStack)"| waitst["Espera (Waits (us))"]
    waitst -->|"Alguien lo despierta (ReadyingProcess / ReadyThreadStack)"| ready["Ready (espera por la disputa de la CPU)"]
    ready -->|"Pasa a la CPU"| run2["Vuelve a ejecutarse"]

El patrón de lectura es el siguiente.⁴

1. Aplique el preajuste Utilization by Process, Thread y añada las columnas NewThreadStack y ReadyThreadStack.
2. Primero identifique el subproceso que ejecutaba la operación que se retrasó (el subproceso de interfaz de usuario, el que procesaba la solicitud en cuestión). Si simplemente se ordena por el total de Waits de mayor a menor, resulta confuso, porque los primeros puestos los ocupan subprocesos que «esperan deliberadamente todo el tiempo», como los de la bomba de mensajes o los temporizadores. Una vez localizado el subproceso objetivo, si su CPU Usage (ms) es alto, es un problema de CPU del capítulo 5; si predomina Waits, es un problema de espera.
3. Expanda NewThreadStack para ver qué estaba haciendo cuando se detuvo. Si es WaitForSingleObject o EnterCriticalSection, es espera de un bloqueo; si está dentro de una E/S síncrona como ReadFile, es espera de E/S; si está dentro de la recepción de un socket, es espera de la respuesta del otro extremo.
4. A continuación, vea quién resolvió la espera. Expanda ReadyThreadStack y consulte ReadyingProcess / ReadyingThreadId. Si lo despertó KiTimerExpiration del kernel, se confirma que era un temporizador (es decir, estuvo dormido hasta el tiempo de espera); si lo despertó el procesamiento de finalización de E/S, se confirma que era una espera de E/S.⁴
5. Si quien lo despertó es otro subproceso o otro proceso, ahora investigue ese subproceso con el mismo procedimiento. «A esperaba a que B liberara el bloqueo, B esperaba la respuesta RPC de C, y C esperaba una E/S de disco»: seguir esta cadena hasta la raíz es lo que constituye la ruta crítica del retraso.⁷

flowchart LR
    accTitle: Cadena de la ruta crítica que se sigue en el análisis de esperas
    accDescr: Se observa en NewThreadStack del subproceso A retrasado qué estaba haciendo cuando se detuvo, se identifica en ReadyThreadStack y ReadyingProcess quién lo despertó (B), y se investiga B con el mismo procedimiento hasta llegar a la E/S de disco en la raíz
    a["Subproceso A (operación retrasada)"] -->|"NewThreadStack: detenido esperando un bloqueo"| b["Subproceso B (mantiene el bloqueo)"]
    b -->|"NewThreadStack: esperando respuesta RPC"| c["Proceso C"]
    c -->|"NewThreadStack: esperando E/S síncrona"| d["E/S de disco (raíz)"]
    d -.->|"la finalización despierta a C"| c
    c -.->|"la respuesta despierta a B"| b
    b -.->|"la liberación del bloqueo despierta a A (aparece en ReadyThreadStack)"| a

Por ejemplo, en un caso de «se paralelizó con múltiples subprocesos pero no se aceleró», este procedimiento muestra directamente cómo todos los workers están en fila esperando un mismo bloqueo. Cómo evitar la contención de bloqueos mediante el diseño se explica en «Buenas prácticas de multithreading en la práctica: edición .NET», y el mecanismo de Windows que, en lugar de esperar con E/S síncrona, funciona mediante notificaciones de finalización, se describe en «Puertos de finalización de E/S (IOCP) y el pool de subprocesos de .NET». Identificar «a quién se esperaba» con WPA y corregirlo con estas ideas de diseño forman un mismo flujo continuo.

7. Disco y E/S de archivos — identificar «quién está saturando el disco»

El culpable clásico de «todo el PC va lento» no es la CPU, sino el disco. Se investiga con Disk Usage y File I/O, de la categoría Storage.¹⁵

Disk Usage es el registro de la E/S de disco y tiene dos columnas importantes. Disk Service Time es el tiempo que la unidad de disco tardó realmente en procesar esa E/S, e IO Time es el tiempo desde que la E/S entra en la cola del sistema operativo hasta que se completa. Como IO Time siempre es igual o mayor que Service Time —la diferencia es el tiempo en cola—, si IO Time es considerablemente mayor que Service Time se sabe que esa E/S «estuvo esperando en la cola».⁶ Sin embargo, esto por sí solo no determina si el culpable de haber formado la cola fue otro proceso, o si simplemente se acumuló el propio volumen de E/S sobre una unidad lenta. No saque la conclusión aquí: confírmela con el Service Time (la respuesta de la propia unidad) y con el desglose por proceso, ruta y pila que viene a continuación.

Para ello, con el preajuste Utilization by Process, Path Name, Stack se revisa, en orden descendente de IO Time o Size, qué proceso emitió E/S sobre qué archivo y desde qué pila de llamadas.¹⁵ Las dos respuestas que aparecen con más frecuencia en la práctica son estas.

• El antivirus estaba escaneando todos los archivos. Se ve como el proceso del antivirus emitiendo una gran cantidad de lecturas justo en la franja en que la aplicación tarda en arrancar. Esto proporciona directamente las pruebas —nombre del proceso, ruta y volumen— para plantear una exclusión.
• Otro proceso estaba realizando escrituras masivas. Copias de seguridad, indexadores, un exceso de escritura de logs, etc. Como el Cache Manager interviene en cuándo llega realmente una escritura al disco, el hecho de que «el momento de escribir» y «el momento en que el disco está ocupado» puedan no coincidir se explica en «El Cache Manager — cuándo llega realmente su WriteFile al disco».

File I/O es una capa más arriba: el registro de las operaciones de archivo que emite la aplicación (Create/Read/Write, etc.), y con preajustes como Duration by Process, Thread, Type se puede agregar el tiempo por nombre de archivo o por tipo de operación.¹⁵ Los casos en que el tiempo se consume en el sistema de archivos o en un filtro de controlador antes de llegar al disco no aparecen en Disk Usage, así que la propia discrepancia de «Disk Usage está tranquilo pero File I/O va lento» ya es una pista. Quien quiera profundizar en el mecanismo de la E/S síncrona y asíncrona puede consultar «E/S síncrona y asíncrona — el verdadero significado de OVERLAPPED».

flowchart TB
    accTitle: Diferencia entre las capas que observan File I/O y Disk Usage
    accDescr: La operación de archivo de la aplicación pasa por el sistema de archivos y los filtros de controlador antes de llegar, desde la cola de E/S del sistema operativo, a la unidad de disco. File I/O registra la operación de la capa superior y Disk Usage la E/S que llega al disco. La diferencia entre IO Time y Disk Service Time indica el tiempo en cola
    app["Aplicación: ReadFile / WriteFile"] --> fio["Sistema de archivos y filtros de controlador (capa que observa File I/O)"]
    fio --> queue["Cola de E/S del sistema operativo"]
    queue --> dev["Unidad de disco (capa que observa Disk Usage)"]
    fio -.-> n1["Si el tiempo se consume aquí, no aparece en Disk Usage"]
    queue -.-> n2["IO Time − Disk Service Time = tiempo en cola"]
    dev -.-> n3["Disk Service Time = tiempo de procesamiento de la unidad"]

Por otro lado, la hipótesis de que «quizá esté haciendo swap por falta de memoria» se puede descartar en una primera aproximación con el Administrador de tareas y el Monitor de recursos antes de pasar a WPA. Pero no la descarte mirando solo la memoria comprometida (committed): aunque haya margen en lo comprometido, es posible que la presión sobre la memoria física reduzca el conjunto de trabajo (working set) y se sucedan fallos de página duros. Compruebe también la memoria física disponible y el valor de «Fallos duros/seg.» del Monitor de recursos. Para cómo leer estos datos, consulte «Qué representa realmente el «uso de memoria» de Windows».

8. Arranque e inicio de sesión lentos — introducción a la traza de arranque

En el tipo de caso «tarda tres minutos en arrancar», el problema termina antes de que se pueda ejecutar wpr -start a mano. WPR cuenta con la traza de arranque, que se puede configurar para que el sistema operativo inicie el registro automáticamente en el próximo arranque.³

:: 1. Configurar el registro automático para el próximo arranque
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Reiniciar (para reproducir la lentitud de arranque)

:: 3. Tras arrancar, detener el registro y guardarlo (esto también anula la configuración)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Evento: el arranque tarda 3 minutos"

flowchart LR
    accTitle: Flujo de la traza de arranque
    accDescr: Al configurar con addboot el registro automático para el próximo arranque y reiniciar, el sistema operativo inicia el registro automáticamente durante el arranque. Al guardar con stopboot tras iniciar sesión, la configuración también se anula. Para cancelarla se usa cancelboot
    add["Configurar con wpr -boottrace -addboot"] --> rebootpc["Reiniciar (para reproducir la lentitud de arranque)"]
    rebootpc --> auto["El sistema operativo inicia el registro automáticamente durante el arranque"]
    auto --> stop2["Tras iniciar sesión, guardar con -stopboot (también anula la configuración)"]
    add -.-> cancel["Para cancelar, usar -cancelboot"]

La medición de arranque y apagado que antes realizaba xbootmgr se puede hacer también en el WPR actual con opciones como -onoffscenario Boot.³ La traza capturada se lee con el mismo conjunto de herramientas de los capítulos anteriores: se observa en el gráfico Processes, en orden cronológico, cuándo nació cada proceso; se hace zoom en la franja donde el arranque se atasca, y se clasifica entre CPU, espera o disco. Así empiezan a verse formas como una aplicación de inicio esperando algo en serie, o el inicio de un servicio detenido por una E/S concreta. El análisis de arranque es en sí mismo un área de especialización profunda, así que este artículo llega solo hasta la puerta de entrada: «incluso los eventos que no se pueden capturar a mano, WPR los puede capturar». Empiece primero por hacerse una idea general con la traza de arranque de GeneralProfile.

9. El patrón de trabajo en la práctica — clasificar, hacer zoom y repasar la pila, en bucle

Una vez conocidas las herramientas, resumamos el patrón general de la investigación.

1. Determine la hora exacta del fenómeno. No se quede en «iba lento», sino precise algo como «entre las 10:23:40 y las 10:24:10 iba lento». Sirve cualquier fuente: el log de la aplicación, el registro de eventos, las notas de la persona que operaba el sistema. Si la aplicación propia registra hitos en ETW o en el registro de eventos, esos eventos dentro de la traza sirven directamente como mojones temporales.
2. Haga zoom únicamente en ese intervalo. El agregado de toda la traza se diluye por el promedio y disimula la anomalía que realmente importa. El análisis en WPA es siempre una comparación entre el «intervalo anómalo» y el «intervalo normal».
3. Clasifique primero entre «CPU, espera o E/S». Si al mirar CPU Usage (Sampled) está al límite, vaya al capítulo 5. Si no lo está, vaya a Waits de CPU Usage (Precise) (capítulo 6). Si el IO Time de Disk Usage está inflado, vaya al capítulo 7. Pasar primero por esta bifurcación de tres caminos evita perderse.
4. Repita el ciclo de hipótesis → zoom → pila. Si sospecha «¿será el antivirus?», acótelo a ese proceso y confírmelo con la pila de llamadas. Si se equivoca, pase a la siguiente hipótesis. No sacar conclusiones antes de bajar hasta la pila y confirmarlas es la disciplina de este tipo de investigación.

flowchart LR
    accTitle: Bucle iterativo de la investigación de rendimiento
    accDescr: Se determina la hora del fenómeno y se hace zoom en el intervalo, se clasifica entre CPU, espera o E/S, se plantea una hipótesis y se acota, y se confirma con la pila de llamadas. Si se confirma, la causa queda determinada. Si no, se repite con la siguiente hipótesis
    time["Determinar la hora del fenómeno"] --> zoomstep["Zoom en ese intervalo"]
    zoomstep --> triage["Clasificar entre CPU, espera o E/S"]
    triage --> hypo["Plantear una hipótesis y acotar"]
    hypo --> stack["Confirmar con la pila de llamadas"]
    stack -->|"Confirmada"| fix["Causa determinada → a las medidas"]
    stack -->|"Descartada"| hypo

Por último, el tratamiento del archivo de captura. El archivo ETL refleja ampliamente el interior del sistema: los nombres de todos los procesos, las rutas de los archivos abiertos, los módulos cargados y, según el perfil, incluso nombres de claves del registro. La captura estándar de GeneralProfile no incluye el contenido propiamente dicho de las comunicaciones, pero si se habilita un proveedor personalizado, la carga útil de esos eventos (por ejemplo, cadenas registradas por la aplicación) entra tal cual. Compruebe también qué emite el proveedor habilitado y, si el archivo va a salir fuera de la organización, trátelo como suficientemente confidencial. Igual que con la captura de paquetes, incorpore al procedimiento la captura mínima necesaria, el acuerdo con la persona receptora, y un plazo de conservación con su eliminación.

flowchart LR
    accTitle: Qué queda reflejado en el archivo ETL y cómo tratarlo
    accDescr: El ETL refleja los nombres de todos los procesos, las rutas de archivos abiertos, los módulos y, según el perfil, nombres de claves del registro. Al habilitar un proveedor personalizado también entra su payload. Se debe tratar como archivo confidencial, con captura mínima necesaria, acuerdo con el receptor, y plazo de conservación con eliminación
    etl["Archivo ETL"] --> a1["Nombres de todos los procesos, rutas de archivo, módulos"]
    etl --> a2["Nombres de claves del registro (según el perfil)"]
    etl --> a3["Payload de proveedores personalizados (cadenas registradas por la aplicación)"]
    a1 -.-> rule["Tratar como confidencial: captura mínima necesaria, acuerdo con el receptor, plazo de conservación y eliminación"]
    a2 -.-> rule
    a3 -.-> rule

10. Resumen

• Un «todo el PC va lento» que el Administrador de tareas no explica se investiga con una traza ETW de todo el sistema operativo: se captura con WPR y se lee con WPA. Como wpr.exe viene integrado de serie en Windows 8.1 y versiones posteriores, es viable el reparto de capturar en el entorno del cliente, llevarse el ETL y leerlo con el WPA propio.
• La captura consta de tres pasos: wpr -start GeneralProfile -filemode → reproducir → wpr -stop trace.etl. Si se puede reproducir, use el modo File dentro de unos pocos minutos; si hay que esperar, use el modo Memory (búfer circular). No es cierto que cuanto más tiempo se capture, mejor.
• Para empezar a leer WPA basta con dominar tres puntos: la regla de oro de las tablas (izquierda de la barra dorada = agrupamiento), el zoom del rango de tiempo, y la configuración de símbolos (PDB para la aplicación propia).
• Si la CPU está alta, use CPU Usage (Sampled) y descienda de proceso a pila y a función. Si la CPU está baja pero el sistema va lento, use CPU Usage (Precise) y siga hasta la raíz la cadena de NewThreadStack (qué estaba haciendo cuando se detuvo) → Waits (cuánto esperó) → ReadyingProcess y ReadyThreadStack (quién lo despertó).
• En el disco, la diferencia entre IO Time y Service Time de Disk Usage revela el «tiempo que pasó en la cola», y la causa —si la propia unidad es lenta o quién formó la cola— se identifica con Service Time y el desglose por proceso, ruta y pila. La lentitud de arranque se puede capturar con wpr -boottrace.
• El patrón de trabajo en la práctica es: ① determinar la hora, ② hacer zoom en el intervalo, ③ clasificar entre CPU, espera o E/S, y ④ repetir el ciclo de hipótesis → zoom → pila. Trate el ETL como confidencial, ya que contiene información interna.

WPA tiene una pantalla intimidante, y cualquiera se pierde en la primera hora. Pero con solo interiorizar dos ideas centrales —«la izquierda de la barra dorada es el agrupamiento» y «Sampled muestra dónde se quemó CPU, Precise muestra a quién se esperó»— el resto es repetir las mismas operaciones. La próxima vez que llegue una consulta del tipo «tengo CPU de sobra pero va lento», cierre el Administrador de tareas y pruebe a capturar una traza.

Artículos relacionados

• Identificar la lentitud con PerfView y dotnet-trace — introducción práctica al análisis de rendimiento en .NET
• Guía práctica de Process Monitor (ProcMon) — identificar en 10 minutos «la configuración no se lee» o «ACCESS DENIED»
• Introducción al registro de eventos de Windows y ETW — integrar el log de las aplicaciones empresariales en el mecanismo estándar del sistema operativo
• Qué representa realmente el «uso de memoria» de Windows — cómo leer correctamente Working Set, Private Bytes, Commit y el archivo de paginación
• La configuración de programación del procesador en Windows — servicios en segundo plano y núcleos P/E
• Qué es un PDB (base de datos de programa) — entender la información de depuración, los símbolos y Source Link

Áreas de consultoría relacionadas

KomuraSoft LLC se encarga de investigar problemas de rendimiento de todo el sistema, como «todo el PC se volvió lento y no se sabe por qué», «la aplicación va lenta aunque hay margen de CPU» o «el arranque es extremadamente lento solo en un entorno concreto». Cubrimos de forma continua desde el diseño de la captura con WPR/WPA (en qué entorno, con qué perfil y cuánto capturar) hasta el análisis de la traza y la corrección, ya sea en la propia aplicación o en la configuración, de la causa identificada.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Dónde se obtienen WPR y WPA? ¿Se pueden usar en un entorno de cliente donde no se puede instalar nada?

La herramienta de captura wpr.exe (versión de línea de comandos) viene integrada de serie en Windows 8.1 y versiones posteriores, por lo que se puede usar sin instalar nada adicional. La versión gráfica WPRUI y la herramienta de análisis WPA (Windows Performance Analyzer) forman parte del Windows ADK (Windows Assessment and Deployment Kit) y requieren una instalación aparte. En la práctica, conviene repartir el trabajo así: en el entorno del cliente se captura el archivo ETL únicamente con el wpr.exe que ya trae el sistema operativo, y luego se lleva ese archivo para analizarlo con WPA en el propio equipo. De este modo se puede investigar el rendimiento de todo el sistema incluso en entornos donde no se puede añadir software.

¿Por qué va lento aunque el Administrador de tareas muestre margen de CPU? ¿Qué permite averiguar WPA?

Cuando el uso de CPU es bajo pero el sistema va lento, el proceso no está incapacitado para usar la CPU: está detenido «esperando» algo. Los casos típicos son la disputa por un bloqueo (lock), la espera de finalización de una operación de E/S síncrona o la espera de respuesta de otro proceso. El Administrador de tareas solo muestra el resultado, es decir, el porcentaje de uso, pero el gráfico CPU Usage (Precise) de WPA, al registrar cada cambio de contexto, muestra dónde empezó a esperar el subproceso (NewThreadStack), cuánto tiempo esperó (Waits) y quién lo despertó (ReadyingProcess y ReadyThreadStack). Siguiendo esa cadena de «quién hizo esperar a quién» es posible identificar al «culpable de la lentitud» a nivel de función.

¿Cuánto tiempo conviene capturar la traza? ¿No se vuelve enorme el archivo?

Si el problema se puede reproducir a voluntad, lo básico es iniciar la captura justo antes de reproducirlo y detenerla justo después, manteniéndola dentro de unos pocos minutos. De forma predeterminada, WPR usa el modo Memory, que graba en un búfer circular en memoria donde los eventos más antiguos se sobrescriben; por eso es adecuado para quedarse a la espera de un evento que puede ocurrir en cualquier momento. El modo File, que se activa con -filemode, conserva todo en un archivo continuo, pero su único límite es el espacio libre en disco, y un archivo demasiado grande puede llegar a no poder analizarse en WPA. Use el modo Memory para esperas largas y el modo File para reproducciones cortas y seguras.

¿Cómo se elige entre PerfView y WPA?

Ambas herramientas trabajan con trazas ETW, pero cada una tiene su fuerte. PerfView entiende en profundidad el runtime de .NET y destaca en investigaciones propias de aplicaciones administradas: GC, asignaciones de memoria, JIT, etc. WPA está pensado para leer de forma transversal, con gráficos y tablas, la CPU, el disco, la E/S de archivos y la energía de todo el sistema operativo, y es la opción principal cuando «no es una aplicación concreta la que va lenta, sino todo el PC», cuando «intervienen varios procesos» o cuando «se sospecha de algo externo a la aplicación (antivirus, controladores, otros procesos)». Como referencia: para la lentitud de una aplicación .NET propia, use PerfView; para la lentitud de todo el sistema, use WPR/WPA.

¿Es seguro ejecutar WPR en el entorno de producción de un cliente?

Las capturas cortas son una práctica habitual, pero no son seguras de forma incondicional. Aunque ETW es ligero, registra una gran cantidad de eventos con su pila de llamadas, por lo que consume una cantidad determinada de CPU y memoria. Aplique al procedimiento el mismo proceso de aprobación que a cualquier otro cambio, con precauciones como iniciar la captura justo antes de la operación que reproduce el problema y detenerla justo después, mantenerla dentro de unos pocos minutos y realizarla en una franja horaria con poco impacto en la operación. Además, como el archivo ETL contiene información interna del sistema —nombres de proceso, rutas de archivo, información de ejecutables, etc.—, conviene decidir de antemano cómo tratarlo si se va a sacar fuera de la organización (minimización, plazo de conservación, eliminación).

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.