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

«Todo el PC se volvió lento después de instalar una aplicación, pero el Administrador de tareas muestra margen tanto de CPU como de memoria.» «Solo una máquina tarda 3 minutos en arrancar.» Lo que hace difíciles estas consultas es que ni siquiera se sabe qué proceso mirar.

Aunque la aplicación A sea la lenta, la causa puede ser un análisis antivirus, escrituras intensas de otro servicio o una cadena de bloqueos que atraviesa varios procesos. Lo que hace falta es registrar la actividad de todo el sistema operativo en un único eje temporal y seguir dónde se fue el tiempo.

Las herramientas para eso son Windows Performance Recorder (WPR) y Windows Performance Analyzer (WPA). WPR captura el registro con ETW (Event Tracing for Windows), y WPA lee ese registro en gráficos y tablas. A lo largo del eje temporal se examina qué procesos y qué pilas usaron CPU, a qué esperaba cada subproceso y qué proceso emitió E/S de disco hacia qué archivo.

La pregunta que responde este artículo es «¿cómo se registra la lentitud de todo el sistema, y cuál de CPU, tiempo de espera y E/S se examina?». Está dirigido a responsables de sistemas de pequeñas y medianas empresas y a desarrolladores de aplicaciones Windows, y cubre, a partir de fuentes primarias de agosto de 2026, desde la práctica de la captura hasta el análisis. Léalo con el eje de la diferencia entre «la CPU está alta» y «la CPU está baja pero aun así va lento».

En qué se diferencia de Process Monitor, que examina el acceso a archivos y al registro, y de PerfView, que sigue la CPU y el GC de una aplicación .NET, se ordena en el capítulo 2.

1. Primero la conclusión

El flujo básico es «capturar con WPR → restringir al intervalo del problema en WPA → aislar CPU, esperas o E/S». Incluso un problema que un solo proceso no explica se puede investigar siguiendo todos los procesos y el kernel en el mismo eje temporal.¹²

Separar el lugar de captura del lugar de lectura

La herramienta de captura wpr.exe viene de serie en Windows 8.1 y posteriores, así que no hace falta instalación adicional. La edición gráfica, WPRUI, y la herramienta de análisis WPA están incluidas en el Windows ADK. Como se puede repartir el trabajo así — «en el entorno del cliente, solo capturar con wpr.exe; la lectura se hace con WPA en el propio equipo» —, se puede capturar incluso en un servidor donde no se puede añadir software.¹²

Para un suceso que se puede reproducir, los tres pasos básicos son, con privilegios de administrador, wpr -start GeneralProfile -filemode → reproducir el suceso → wpr -stop C:\temp\trace.etl.³ Prepare la carpeta de destino, obtenga la aprobación de la captura y decida cómo se tratará el ETL antes de ejecutarlo. Esperar un suceso y los problemas durante el arranque piden otros métodos de captura; véanse el capítulo 3 y el capítulo 8.

El primer gráfico que abrir en WPA

Restrinja primero al intervalo del suceso y elija después la dirección de investigación en la tabla siguiente.⁴⁵

Sampled muestra el desglose del tiempo de CPU a partir de muestras tomadas aproximadamente cada milisegundo.⁶ Precise sigue las esperas a partir de un registro completo de los cambios de contexto. Seguir a quien levantó una espera, usando Waits → ReadyingProcess → ReadyThreadStack como pistas, es la técnica que este artículo más quiere transmitir.⁴⁷

Cómo leer este artículo según el objetivo

Si usted se encarga de la captura, empiece por el capítulo 2 y el capítulo 3; si lee un ETL ya capturado, empiece por el capítulo 4. Leer las pilas por nombre de función exige configurar símbolos, y para la aplicación propia se añade la ruta a sus PDB.⁸ Cuando se investiga código JIT de .NET, también hacen falta eventos CLR en el momento de la captura, así que consulte las notas sobre .NET del capítulo 4 antes de capturar.

El flujo general de la investigación y el tratamiento del ETL se resumen en el capítulo 9. Un ETL contiene información interna como nombres de proceso y rutas de archivo, así que limite la captura al mínimo necesario y decida de antemano las condiciones para entregarlo fuera de la empresa.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (16 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. El lugar de las herramientas — 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), y su núcleo es el par WPR y WPA.² Sus funciones están claramente separadas.

WPR captura, WPA analiza

• WPR (Windows Performance Recorder) = captura. Agrupa proveedores ETW en unidades llamadas «perfiles», inicia y detiene la grabación y produce un archivo ETL. La edición de línea de comandos, wpr.exe, viene de serie en Windows 8.1 y posteriores, sin instalación adicional. La edición gráfica (WPRUI.exe) está incluida en el ADK.¹
• WPA (Windows Performance Analyzer) = análisis. Abre un archivo ETL y lo analiza en gráficos y tablas. Hace falta instalar el ADK.²

Es decir, si lo único que se hace es capturar desde la línea de comandos, no hace falta instalar software adicional 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 WPA en el propio PC: el mismo reparto que «capturar con pktmon, leer con Wireshark» en la captura de paquetes.

flowchart LR
    accTitle: El 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 producir un archivo ETL, se lleva y se analiza con WPA instalado mediante el ADK en el propio PC
    subgraph customer["Entorno del cliente (sin instalación adicional)"]
        wpr["wpr -start → reproducir el suceso → wpr -stop"] --> etl["Archivo ETL"]
    end
    subgraph office["El propio PC (WPA instalado mediante el ADK)"]
        wpa["Análisis en gráficos y tablas en WPA"]
    end
    etl -->|"Llevar"| wpa

Elegir entre Procmon, PerfView y WPR/WPA

Ordenemos primero también en qué se diferencia de herramientas similares.

Si Procmon es el registro de operaciones de «qué hizo» y PerfView es «qué ocurrió dentro de .NET», WPA es la herramienta que audita «dónde se fue el tiempo» a través de todos los procesos.

Cuando se quieren registrar también los eventos de la propia aplicación

Cómo funciona ETW en sí y cómo instrumentar la propia aplicación con ETW se trata en «Introducción al registro de eventos de Windows y ETW». Si la aplicación emite eventos ETW, sus hitos quedan registrados en la misma traza, lo que facilita mucho el cruce.

Tenga en cuenta, no obstante, que WPR solo registra los eventos de los proveedores habilitados por el perfil de grabación que eligió. GeneralProfile no incluye el proveedor propio. Para registrarlos juntos, prepare un perfil de grabación personalizado (.wprp) que habilite su proveedor y combínelo como en wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, indicando el nombre de perfil dentro del archivo .wprp después de !³.

3. La captura en la práctica (WPR) — start, reproducir, stop

Qué decidir antes de ejecutarlo

En un entorno de producción, no dé por hecho que incluso una captura corta es incondicionalmente segura. ETW es ligero, pero registrar un gran volumen de eventos con pilas consume una cantidad determinada de CPU y memoria. Elija un momento de poco impacto en el negocio y trámitelo por el mismo proceso de aprobación que cualquier cambio ordinario.

Si se puede reproducir el suceso, inicie justo antes, detenga justo después y manténgalo en unos pocos minutos. Prepare la carpeta de destino y decida de antemano quién recibe el ETL, cuánto tiempo se conserva y cómo se elimina. Las precauciones sobre su contenido están en el capítulo 9.

Lo que sigue es un ejemplo de captura, en modo File, de un suceso que se puede reproducir in situ. Para un suceso cuyo momento se desconoce, vaya al modo Memory en el apartado 3.1; para problemas durante el arranque o el inicio de sesión, vaya al capítulo 8.

Una captura normal es «start → reproducir → stop»

Ejecute esto en un símbolo del sistema abierto como administrador. -profiles lista los perfiles disponibles de antemano, y -status comprueba el estado mientras se captura. El -cancel del final solo sirve para abortar a mitad de camino y descartar; no forma parte del procedimiento normal de guardado.

:: Listar los perfiles integrados que se pueden usar
wpr -profiles

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

:: 2. Reproducir el suceso (comprobar el estado de la captura con wpr -status)

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

:: Para abortar a mitad de camino, descartar sin guardar
wpr -cancel

Elegir qué se registra con un perfil

Lo que se pasa a -start es un perfil, un lote de los proveedores ETW que la investigación necesita.³ Basta con recordar los que se usan a menudo.⁹

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

flowchart TB
    accTitle: Flujo de captura de WPR y elección del modo
    accDescr: Un suceso reproducible en local se captura breve y de forma fiable en modo archivo; un suceso cuyo momento se desconoce se espera en el búfer anular del modo memoria predeterminado. Un suceso durante el arranque o el inicio de sesión usa una traza de arranque. En todos los casos el procedimiento start, reproducir, stop es el mismo
    q{"¿Cuándo ocurre el suceso?"}
    q -->|"Reproducible en local"| file["Capturar breve y de forma fiable con -filemode"]
    q -->|"Momento desconocido"| mem["Esperarlo en modo Memory (predeterminado, búfer anular) (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 o esperar el suceso → wpr -stop"]
    mem --> s1

3.1. Modo Memory y modo File — ¿se puede reproducir, o se espera?

WPR tiene dos modos de destino de grabación, y el predeterminado es el modo Memory (un búfer circular en memoria).

El modo Memory sirve para esperar a que ocurra un suceso. Como es un búfer anular que sobrescribe primero los eventos más antiguos, encaja dejar la captura en marcha mientras se espera un suceso cuyo momento se desconoce, y detenerla cuando ocurre.

El modo File sirve para sucesos que se pueden reproducir de forma fiable en poco tiempo. Añadir -filemode pasa al modo File, y todo se registra en un archivo continuo. Nada se pierde por sobrescritura, pero a cambio el único techo es el espacio libre en disco, y el archivo crece sin límite.¹⁰

flowchart LR
    accTitle: Cómo graban el modo Memory y el modo File
    accDescr: El modo Memory graba en un búfer circular en memoria donde los eventos más antiguos se sobrescriben y solo quedan los más recientes, así que sirve para esperar. El modo File conserva todo en un archivo, pero el único techo es el espacio libre en disco, así que sirve para una reproducción corta y fiable
    ev["Flujo de eventos ETW"] --> ring["Modo Memory: búfer circular (los más antiguos se sobrescriben primero → solo quedan los más recientes)"]
    ev --> filem["Modo File: todo se conserva en un archivo (el techo es el espacio libre en disco)"]
    ring -.-> use1["Sirve para esperar un suceso cuyo momento se desconoce"]
    filem -.-> use2["Sirve para un suceso que se puede reproducir de forma fiable en poco tiempo"]

La regla práctica para elegir es la siguiente.

• Reproducible in situ → modo File. Iniciar justo antes de la reproducción, detener justo después y mantener la captura en unos pocos minutos
• Momento desconocido → Esperar en modo Memory (el predeterminado). En cuanto ocurra, ejecutar wpr -stop
• Incluso unos minutos de GeneralProfile pueden producir un ETL del orden de cientos de MB a GB. Un archivo demasiado grande puede dejar de ser analizable en WPA, así que «cuanto más larga la captura, mejor» es contraproducente¹⁰¹¹

Capturar desde la interfaz gráfica

Para capturar desde la interfaz gráfica, inicie WPRUI, elija un perfil y un Logging mode, y pulse Start y después Save. Los detalles del procedimiento están en los temas How-to oficiales.¹¹ Cuando pida a un contacto en el cliente que capture, también puede redactar un procedimiento centrado en los pasos start, reproducir y stop, con los requisitos previos y la operación de aborto por separado.

4. Lo básico de leer WPA — gráficos, la regla de oro de las tablas y el recorte del intervalo de tiempo

Al abrir el ETL capturado en WPA, el Graph Explorer de la izquierda lista miniaturas de gráficos en categorías como System Activity, Computation, Storage y Memory.¹² Arrastre el gráfico que quiera a la pestaña Analysis de la derecha, y el gráfico aparece arriba con una tabla debajo.

Las tres cosas que dominar son el orden de las columnas, el recorte del intervalo de tiempo y la configuración de símbolos. En lugar de reaprender las operaciones para cada gráfico, empiece por esta forma común de leer.

4.1. El orden de las columnas decide cómo se agrega

Una tabla de WPA tiene dos barras verticales, una dorada y una azul: las columnas a la izquierda de la barra dorada jerarquizan (agrupan) los datos en ese orden, y las columnas a la derecha de la barra azul son valores agregados.¹³

Ordenarlas «Process → Stack» da una agregación de pilas por proceso; «Stack → Process» una agregación en todos los procesos que usan la misma pila. Arrastrar columnas para reordenarlas es en sí la operación de análisis. Cuando se entiende este único punto, todas las tablas de WPA se leen igual.

flowchart LR
    accTitle: La regla de oro de las tablas — las dos barras y los papeles de las columnas
    accDescr: El orden de las columnas a la izquierda de la barra dorada jerarquiza los datos, las columnas entre las barras dorada y azul son columnas de visualización, y las columnas a la derecha de la barra azul son valores agregados. Arrastrar columnas para reordenarlas es en sí la operación de análisis
    left["A la izquierda de la barra dorada: columnas de agrupación (orden = jerarquía)"] --> gold["Barra dorada"]
    gold --> mid["Entre las barras: columnas de visualización"]
    mid --> blue["Barra azul"]
    blue --> right["A la derecha de la barra azul: valores agregados (Sum, %, etc.)"]
    left -.-> op["Arrastrar una columna = una operación de análisis (Process → Stack da una agregación de pilas por proceso)"]

4.2. Recortar al intervalo en el que ocurrió el suceso

Arrastre sobre el gráfico para seleccionar un intervalo, pulse el botón derecho y elija «Zoom», y la agregación pasa solo a ese intervalo. El principio de la investigación de rendimiento es mirar siempre solo «el intervalo en el que ocurría el suceso» (capítulo 9).

4.3. Cargar símbolos y ver las pilas por nombre de función

Para leer las pilas por nombre de función, ejecute Trace > Load Symbols en el menú.¹⁴ De forma predeterminada consulta el servidor público de símbolos de Microsoft (msdl.microsoft.com), así que las pilas de Windows en sí se resuelven mientras haya conexión a Internet.

Para ver también los nombres de función de la aplicación propia, añada la carpeta con sus PDB en Trace > Configure Symbol Paths.⁸ Qué es un PDB, y por qué conviene conservarlo siempre incluso en compilaciones de publicación, se resume en «¿Qué es un PDB (Program Database)?».

En .NET, tratar por separado las imágenes NGen y el código JIT

Para las imágenes nativas NGen de .NET Framework, WPR genera PDB de NGen (.ngenpdb) en el momento de la captura, las coloca en una carpeta junto a la traza y WPA las consulta automáticamente.⁸ Este mecanismo es propio de las imágenes NGen; el código propio de una aplicación .NET ordinaria que se ejecuta bajo el JIT no está cubierto.

La correspondencia entre direcciones de código JIT y nombres de función se resuelve a partir de los eventos JIT que emite el CLR. Así que, cuando investigue una aplicación .NET, prepare un perfil de grabación (.wprp) que habilite los proveedores CLR (Microsoft-Windows-DotNETRuntime y su homólogo Rundown), combínelo en la forma wpr -start GeneralProfile -start MyDotNet.wprp!ProfileName, igual que con el proveedor propio en el capítulo 2, para que los eventos CLR queden incluidos en la traza (puede comprobar qué perfiles integrados ofrece el WPR local con wpr -profiles).

Además, conserve los PDB generados por la compilación para el mapeo a líneas de origen y añádalos a la ruta de símbolos descrita más arriba.

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

4.4. Decidir si investigar CPU, esperas o E/S

Una vez preparado, mire si la CPU estuvo alta o baja en el intervalo del suceso. Si estuvo alta, vaya a Sampled en el capítulo 5. Si estuvo baja, compruebe primero si un núcleo o un subproceso concreto está anclado; si no, siga las esperas con Precise en el capítulo 6. Si se sospecha del disco, vaya al capítulo 7.

flowchart TB
    accTitle: Elegir un gráfico de WPA a partir del síntoma
    accDescr: Zoom al intervalo del suceso; si la CPU está alta ir a CPU Usage Sampled; si está baja pero va lento, comprobar un núcleo anclado y luego el análisis de esperas en CPU Usage Precise; si se sospecha del disco ir a Disk Usage y File IO
    zoom["Hacer zoom al intervalo del suceso"] --> cpu{"¿CPU en ese intervalo?"}
    cpu -->|"Alta"| sampled["Capítulo 5: CPU Usage (Sampled) para «quién consume CPU en qué función»"]
    cpu -->|"Baja pero lento"| core{"¿Un núcleo o un subproceso anclado?"}
    core -->|"Sí"| sampled
    core -->|"No"| precise["Capítulo 6: CPU Usage (Precise) para «a qué esperaba»"]
    cpu -->|"Disco sospechoso"| disk["Capítulo 7: Disk Usage / File I/O para identificar al culpable"]

5. Cuando la CPU está alta — «quién consume CPU en qué función» con CPU Usage (Sampled)

Lo que busca este capítulo es la ruta de llamada que usa una gran parte del tiempo de CPU.

Si la CPU está anclada, lo que se mira es CPU Usage (Sampled). Son datos de muestreo que registran, aproximadamente cada milisegundo en cada CPU, «la pila de qué proceso se está ejecutando ahora», y la proporción de recuentos de muestras es directamente el desglose del tiempo de CPU.⁶

flowchart LR
    accTitle: Cómo funciona CPU Usage Sampled
    accDescr: Aproximadamente cada milisegundo se registra la pila en ejecución en cada CPU, y la proporción de las muestras agregadas es el desglose del tiempo de CPU. Leer bajando de proceso a subproceso, pila y función. La actividad corta que termina entre muestras no se captura
    tick["Interrupción aproximadamente cada 1 ms"] --> snap["Registrar la «pila en ejecución ahora» en cada CPU"]
    snap --> agg["Agregar las muestras (proporción = desglose del tiempo de CPU)"]
    agg --> drill["Bajar Process → Thread → Stack → función"]
    snap -.-> miss["La actividad corta que termina entre muestras no se captura"]

Bajar de proceso a pila y a función

1. Desde Computation en Graph Explorer, coloque CPU Usage (Sampled) en la pestaña Analysis y seleccione el valor preestablecido Utilization by Process, Stack.⁵
2. Mire los procesos en orden descendente de Weight (o Count). Lo que en el Administrador de tareas era «50 %» se identifica primero a nivel de proceso.
3. Expanda la columna Stack del proceso culpable. Las pilas se agregan como un árbol, y bajar por el camino en el que los números no caen mucho en cada ramificación lleva a la función que consume CPU. Si los símbolos se han resuelto, es una línea recta hasta la función exacta del código propio.
4. Si expandir el árbol resulta tedioso, cambie la visualización del gráfico a Flame (gráfico de llamas). El ancho se dibuja como la parte del tiempo de CPU, así que qué ruta de llamada domina se ve de un vistazo. CPU Usage (Sampled) también trae un valor preestablecido Flame by Process, Stack.¹³

Sampled no puede medir la duración exacta de una sola ejecución

Como es muestreo, la actividad corta que termina entre muestras no se captura.⁶ Recuerde que es una herramienta para ver «dónde se usó CPU en total», no una herramienta para medir el tiempo de ejecución exacto de cada pasada.

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

6.1. Antes del análisis de esperas, comprobar un núcleo anclado

«El uso global de CPU es bajo» no significa «la CPU no es el cuello de botella». En un PC de 16 núcleos, un trabajo serie anclado a un núcleo (un solo subproceso de interfaz que corre a tope) solo aparece como alrededor del 6 % en global.

Compruebe primero, con Sampled del capítulo 5 o con Utilization by CPU en CPU Usage (Precise), si un núcleo o un subproceso concreto está anclado. Si tampoco hay nada anclado, parta de que el trabajo no es incapaz de usar la CPU sino que espera algo, y pase al análisis de esperas. A partir de aquí, la herramienta es CPU Usage (Precise).

6.2. Separar «tiempo pasado esperando» de «espera de una CPU tras el despertar»

Donde Sampled es muestreo, Precise es un registro completo de los cambios de contexto (cambios de subproceso). Un subproceso entra en una espera, alguien lo despierta (Ready) y sube a una CPU: cada ida y vuelta de ese tipo se conserva como una fila, y se pueden leer las columnas siguientes.⁷⁴

flowchart LR
    accTitle: Una ida y vuelta de espera y las columnas correspondientes
    accDescr: Un subproceso entra en espera en la pila conservada en NewThreadStack y espera el tiempo de Waits. Cuando alguien lo despierta, esa parte se conserva en ReadyingProcess y ReadyThreadStack, y el subproceso espera el tiempo Ready por la contención de CPU antes de volver a ejecutarse
    run1["En ejecución"] -->|"Entra en una espera (conservado en NewThreadStack)"| waitst["Espera (Waits (us))"]
    waitst -->|"Alguien lo despierta (ReadyingProcess / ReadyThreadStack)"| ready["Ready (espera por contención de CPU)"]
    ready -->|"Sube a una CPU"| run2["Otra vez en ejecución"]

6.3. Desde el subproceso retrasado, seguir a cada despertador por turnos

El orden de lectura es el siguiente.⁴

1. Preparar el gráfico y las columnas

Aplique el valor preestablecido Utilization by Process, Thread y añada NewThreadStack y ReadyThreadStack a las columnas.

2. Seleccionar el subproceso de la operación retrasada

Identifique primero el subproceso que ejecutaba la operación retrasada, por ejemplo el subproceso de interfaz o el que atiende la petición en cuestión. Si solo se mira en orden descendente de Waits totales, suben al frente subprocesos sanos que esperan a propósito, como una bomba de mensajes o un temporizador.

Si el CPU Usage (ms) del subproceso objetivo es grande, es un problema de CPU del capítulo 5; si dominan los Waits, es un problema de espera.

3. Ver en NewThreadStack «qué hacía cuando se detuvo»

Expanda NewThreadStack. WaitForSingleObject o EnterCriticalSection significa espera de un bloqueo; dentro de E/S síncrona como ReadFile, espera de E/S; dentro de una recepción de socket, espera de la respuesta del par.

4. Ver en ReadyThreadStack «quién levantó la espera»

Expanda ReadyThreadStack y compruebe ReadyingProcess / ReadyingThreadId. Si lo despertó el KiTimerExpiration del kernel, era un temporizador (durmió hasta el tiempo de espera); si lo despertó el procesamiento de finalización de E/S, eso confirma una espera de E/S.⁴

5. Repetir la misma investigación en el despertador

Si el despertador es otro subproceso u otro proceso, investigue a continuación ese subproceso con el mismo procedimiento.

Por ejemplo, una cadena como A esperaba a que B liberara un bloqueo, B esperaba una respuesta RPC de C, y C esperaba E/S de disco. Seguir esa cadena hasta la raíz da el camino crítico del retraso.⁷

flowchart LR
    accTitle: La cadena del camino crítico que sigue el análisis de esperas
    accDescr: Ver en NewThreadStack del subproceso A retrasado qué hacía cuando se detuvo, identificar al despertador B desde ReadyThreadStack y ReadyingProcess, investigar B con el mismo procedimiento y seguir hasta la E/S de disco en la raíz
    a["Subproceso A (la operación retrasada)"] -->|"NewThreadStack: detenido en una espera de bloqueo"| b["Subproceso B (sostiene el bloqueo)"]
    b -->|"NewThreadStack: espera de una respuesta RPC"| c["Proceso C"]
    c -->|"NewThreadStack: espera de E/S síncrona"| d["E/S de disco (la 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

Convertir la causa de la espera en una revisión de diseño

En un proyecto en el que «lo hicimos multithreaded pero no se aceleró», por ejemplo, este procedimiento muestra todos los workers alineados detrás de un solo bloqueo tal cual. Evitar la contención de bloqueos por diseño se trata en «Buenas prácticas de multithreading en la práctica: edición .NET», y el mecanismo de Windows que gira sobre notificaciones de finalización en lugar de esperar en E/S síncrona en «Puertos de finalización de E/S (IOCP) y el grupo de subprocesos de .NET». Fijar en WPA «a quién esperaba» y luego corregirlo con estos principios de diseño es un flujo continuo.

7. Disco y E/S de archivos — identificar «alguien está recorriendo el disco»

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

7.1. Separar en Disk Usage «el procesamiento del dispositivo» de «la cola»

Disk Usage es el registro de la E/S de disco. Empiece por distinguir las dos columnas siguientes.⁶

IO Time es siempre al menos igual a Service Time; la diferencia es el tiempo en la cola. Si IO Time es mucho más largo que Service Time, esa E/S estaba esperando en la cola.⁶

No concluya, sin embargo, la causa solo a partir de la diferencia de tiempo. Si otro proceso formó la cola, o si la propia E/S intensa del proceso se alineó en un dispositivo lento, aún no está decidido. Mire la respuesta del dispositivo en Service Time y ciérrelo con el desglose por proceso, ruta y pila.

7.2. Qué proceso emitió E/S hacia qué archivo

Así, con el valor preestablecido Utilization by Process, Path Name, Stack, mire qué proceso emitió E/S hacia qué archivo desde qué pila, en orden descendente de IO Time o Size.¹⁵ Las dos respuestas que más salen en el terreno son estas.

• El software antivirus recorría todos los archivos. Aparece como el proceso antivirus emitiendo un gran volumen de lecturas en el intervalo en que la aplicación tardaba en arrancar. El nombre de proceso, la ruta y el volumen son pruebas listas para una conversación sobre la configuración de exclusiones.
• Otro proceso escribía de forma intensa. Copia de seguridad, un indizador, registro excesivo, etc. Cuándo una escritura llega al disco implica al administrador de caché, así que el hecho de que «el instante de la escritura» y «el instante en que el disco está ocupado» pueden divergir también se explica en «El administrador de caché: ¿cuándo llega su WriteFile al disco?».

7.3. Ver la lentitud antes del disco con File I/O

File I/O está una capa más arriba: el registro de las operaciones de archivo que emitió la aplicación (Create, Read, Write, etc.), y valores preestablecidos como Duration by Process, Thread, Type agregan el tiempo por nombre de archivo y por operación.¹⁵

Un caso en el que se consume tiempo en el sistema de archivos o en un controlador de filtro antes de llegar al disco no aparece en Disk Usage, así que la discrepancia misma, «Disk Usage está tranquilo pero File I/O es lento», es una pista. Si quiere partir de cómo funcionan la E/S síncrona y la asíncrona, véase «E/S síncrona y asíncrona: el verdadero significado de OVERLAPPED».

flowchart TB
    accTitle: Las capas distintas que ven File IO y Disk Usage
    accDescr: Una operación de archivo de la aplicación pasa por el sistema de archivos y los controladores de filtro y llega al dispositivo de disco desde la cola de E/S del sistema operativo. File IO registra las operaciones de la capa superior, Disk Usage registra la E/S que llegó al disco, y la diferencia entre IO Time y Disk Service Time muestra el tiempo en la cola
    app["Aplicación: ReadFile / WriteFile"] --> fio["Sistema de archivos y controladores de filtro (la capa que ve File I/O)"]
    fio --> queue["Cola de E/S del sistema operativo"]
    queue --> dev["Dispositivo de disco (la capa que ve Disk Usage)"]
    fio -.-> n1["El tiempo consumido aquí no aparece en Disk Usage"]
    queue -.-> n2["IO Time − Disk Service Time = tiempo en la cola"]
    dev -.-> n3["Disk Service Time = tiempo de procesamiento del dispositivo"]

7.4. Cuando se sospecha falta de memoria, comprobar también la memoria física

El razonamiento «a lo mejor falta memoria y está paginando» puede recibir un primer triaje en el Administrador de tareas y el Monitor de recursos antes de pasar a WPA.

No descarte una falta de memoria mirando solo la memoria confirmada. Aunque haya margen en commit, la presión sobre la memoria física puede recortar working sets y mantener los errores graves. Compruebe también la memoria física disponible y «Errores graves/s» en el Monitor de recursos. Para cómo leerlos, véase el artículo ¿Qué representa realmente el «uso de memoria» de Windows?.

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

Con el tipo «el arranque tarda 3 minutos», el problema termina antes de que se pueda ejecutar wpr -start a mano. WPR tiene una traza de arranque, que se puede configurar para que el sistema operativo empiece a grabar automáticamente en el siguiente arranque.³

Configurar la grabación para el siguiente arranque y guardar después del reinicio

Como en el capítulo 3, decida la aprobación de la captura y el tratamiento del ETL, y opere después desde un símbolo del sistema abierto como administrador.

:: 1. Configurar la grabación automática en el siguiente arranque
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Reiniciar (reproducir el arranque lento)

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

flowchart LR
    accTitle: Flujo de la traza de arranque
    accDescr: Configurar la grabación automática en el siguiente arranque con addboot y reiniciar; el sistema operativo empieza a grabar automáticamente al arrancar. Guardar con stopboot tras el inicio de sesión también anula la configuración. Para abandonar, anular con cancelboot
    add["Configurar con wpr -boottrace -addboot"] --> rebootpc["Reiniciar (reproducir el arranque lento)"]
    rebootpc --> auto["El sistema operativo empieza a grabar automáticamente al arrancar"]
    auto --> stop2["Guardar con -stopboot tras el inicio de sesión (también anula la configuración)"]
    add -.-> cancel["Para abandonar, -cancelboot"]

Tras la captura, el mismo triaje «CPU, espera o E/S»

La medición de arranque y apagado que antes cubría xbootmgr también se puede ejecutar en el WPR actual con opciones como -onoffscenario Boot.³

La traza capturada se lee con el mismo conjunto de herramientas que los capítulos anteriores. Mire qué proceso se creó cuándo, en orden cronológico, en el gráfico Processes; haga zoom al intervalo en el que el arranque está atascado; y clasifíquelo como CPU, espera o disco. Aparecen patrones como aplicaciones de inicio que esperan algo en serie, o el arranque de un servicio detenido en una E/S concreta.

El análisis de arranque es una especialidad profunda por sí misma, así que este artículo llega solo hasta la entrada: «un suceso que no se puede coger a mano aún se puede capturar con WPR». Empiece por hacerse una visión de conjunto con una traza de arranque de GeneralProfile.

9. El patrón de trabajo — clasificar, hacer zoom, pila, repetir

Ahora que las herramientas están claras, aquí está el patrón de la investigación en conjunto. El orden fijar la hora y recortar el intervalo, clasificar y después seguir la pila es el mismo para cada síntoma.

De fijar la hora a comprobar la hipótesis

1. Fije la hora del fenómeno. No «iba lento», sino «iba lento de 10:23:40 a 10:24:10». Registros de la aplicación, el registro de eventos, una nota de la persona que operaba: vale cualquiera. Si la aplicación propia escribe hitos en ETW o el registro de eventos, los eventos dentro de la traza sirven directamente como clavos de tiempo.
2. Haga zoom solo a ese intervalo. Una agregación sobre toda la traza se suaviza en promedios, y la anomalía que importa se diluye. El análisis en WPA es siempre una comparación de «el intervalo que era anómalo» frente a «el intervalo que era normal».
3. Clasifique primero «CPU, espera o E/S». Mire CPU Usage (Sampled); si está al límite, vaya al capítulo 5. Si no lo está, vaya a Waits de CPU Usage (Precise) (capítulo 6). Si IO Time en Disk Usage está inflado, vaya al capítulo 7. Pasar primero por esta horquilla de tres vías evita perderse.
4. Repita hipótesis → zoom → pila. Si piensa «¿antivirus?», recorte a ese proceso y confírmelo con la pila. Si no se sostiene, pase a la siguiente hipótesis. No sacar una conclusión antes de bajar hasta la pila y confirmarla es la disciplina de este tipo de investigación.

flowchart LR
    accTitle: El bucle iterativo de una investigación de rendimiento
    accDescr: Fijar la hora del fenómeno, hacer zoom al intervalo, clasificar CPU, espera o E/S, formar una hipótesis y recortar, y confirmar con la pila. Si se sostiene, la causa queda confirmada; si no, repetir con la siguiente hipótesis
    time["Fijar la hora del fenómeno"] --> zoomstep["Hacer zoom a ese intervalo"]
    zoomstep --> triage["Clasificar CPU, espera o E/S"]
    triage --> hypo["Formar una hipótesis y recortar"]
    hypo --> stack["Confirmar con la pila"]
    stack -->|"Confirmado"| fix["Causa identificada → corregir"]
    stack -->|"No se sostuvo"| hypo

Decida cómo tratar el ETL antes de capturar

Un archivo ETL captura una vista amplia del interior del sistema: los nombres de todos los procesos, las rutas de los archivos abiertos, los módulos cargados y (según el perfil) nombres de claves del registro.

Una captura estándar de GeneralProfile no incluye cuerpos de datos como el contenido de las comunicaciones, pero si habilitó un proveedor personalizado, la carga útil de sus eventos (por ejemplo cadenas que registró la aplicación) entra tal cual.

Confirme qué emiten los proveedores que habilitó y trátelo después como un archivo lo bastante confidencial como para exigir cuidado antes de que salga de la empresa. Como en la captura de paquetes, incorpore al procedimiento una captura mínima, un acuerdo con el destinatario, y un plazo de conservación y la eliminación.

flowchart LR
    accTitle: Qué captura un archivo ETL y cómo tratarlo
    accDescr: Un ETL captura todos los nombres de proceso, las rutas de archivos abiertos, los módulos y según el perfil nombres de claves del registro; habilitar un proveedor personalizado añade también su carga útil. Trátelo como confidencial e incorpore al procedimiento una captura mínima, un acuerdo con el destinatario, y un plazo de conservación y la eliminación
    etl["Archivo ETL"] --> a1["Todos los nombres de proceso, rutas de archivo, módulos"]
    etl --> a2["(Según el perfil) nombres de claves del registro"]
    etl --> a3["Cargas útiles de proveedores personalizados (cadenas que registró la aplicación)"]
    a1 -.-> rule["Tratar como confidencial: captura mínima, acuerdo con el destinatario, plazo de conservación y eliminación"]
    a2 -.-> rule
    a3 -.-> rule

10. Resumen

Una investigación con WPR/WPA se puede organizar en las tres etapas siguientes.

1. Capture el intervalo que necesita. Capture con wpr.exe, que viene de serie en Windows 8.1 y posteriores, y lea el ETL con WPA en el propio equipo. Lo básico es wpr -start GeneralProfile -filemode → reproducir → wpr -stop trace.etl. Si se puede reproducir, modo File en unos pocos minutos; si se espera, modo Memory. Para lentitud durante el arranque, use wpr -boottrace. Más largo no es mejor, y la información interna del ETL se trata como confidencial.
2. Recorte el intervalo de tiempo y elija la dirección de investigación. En WPA, a la izquierda de la barra dorada está la agrupación y a la derecha de la barra azul los valores agregados. Domine el orden de las columnas, el zoom al intervalo y la configuración de símbolos, y después aísle CPU, esperas o E/S. Proporcione PDB para la aplicación propia y, para código JIT de .NET, compruebe también los eventos CLR en el momento de la captura.
3. Siga hasta la pila y compruebe la hipótesis. Si la CPU está alta, baje de proceso a función en Sampled. Aunque la CPU global esté baja, compruebe primero un núcleo o un subproceso anclado y, si no lo hay, siga las esperas en Precise. En disco, no decida la causa solo a partir de la diferencia de tiempo; mire la respuesta del dispositivo y el desglose de quién emitió la E/S.

Lo que se sigue en el análisis de esperas es NewThreadStack (qué hacía cuando se detuvo) → Waits (cuánto tiempo esperó) → ReadyingProcess y ReadyThreadStack (quién lo despertó). Investigue al despertador del mismo modo y podrá seguir la cadena de retrasos hasta la raíz.

WPA puede al principio abrumar por la cantidad de información en pantalla. Aun así, una vez que se sostiene «el orden de las columnas es el modo de agregación» y «Sampled es dónde se usó CPU, Precise es a quién esperaba», el resto es la repetición de fijar la hora, hacer zoom, clasificar y comprobar la pila. La próxima vez que llegue una consulta que diga «la CPU tiene margen pero aun así va lento», capture una traza en este orden y léala.

Artículos relacionados

• Identificar qué es «lento» con PerfView y dotnet-trace — introducción práctica a la investigación de rendimiento en .NET
• Guía práctica de Process Monitor (ProcMon): identifica en 10 minutos por qué «no se lee la configuración» o aparece «ACCESS DENIED»
• Introducción al registro de eventos de Windows y ETW — llevar los registros de aplicaciones de negocio al mecanismo estándar del sistema operativo
• ¿Qué representa realmente el «uso de memoria» de Windows? — Cómo interpretar correctamente Working Set, Private Bytes, Commit y el archivo de paginación
• Configuración de la programación del procesador en Windows — Servicios en segundo plano y núcleos P/E
• ¿Qué es un PDB (Program Database)? — Cómo entender la información de depuración, los símbolos y Source Link

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de investigaciones de problemas de rendimiento de todo el sistema como «todo el PC se volvió lento y no encontramos la causa», «la CPU tiene margen pero la aplicación va lenta» y «solo un entorno concreto arranca de forma extremadamente lenta». Lo tratamos como un encargo continuo, desde el diseño de la captura con WPR/WPA (qué entorno, qué perfil y cuánto capturar) hasta el análisis de la traza y la corrección de la causa en la aplicación o en la configuración.

• 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 (la edición de línea de comandos) viene de serie en Windows 8.1 y posteriores, así que se puede usar sin instalación adicional. La edición gráfica, WPRUI, y la herramienta de análisis WPA (Windows Performance Analyzer) están incluidas en el Windows ADK (Windows Assessment and Deployment Kit) y requieren una instalación aparte. En la práctica, si se reparte el trabajo así — «en el entorno del cliente, capturar únicamente un archivo ETL con el wpr.exe estándar del sistema operativo, llevarlo y analizarlo con WPA en el propio equipo» —, se puede investigar el rendimiento de todo el sistema incluso en un sitio donde no se puede añadir software.

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

Cuando el uso de CPU es bajo y aun así va lento, el trabajo no es incapaz de usar la CPU; está detenido «esperando algo». Los casos típicos son la contención de un bloqueo, la espera a que termine una E/S síncrona y la espera de respuesta de otro proceso. El Administrador de tareas solo muestra el resultado, la cifra de uso, pero CPU Usage (Precise) de WPA muestra, a partir de un registro por cambio de contexto, dónde empezó a esperar un subproceso (NewThreadStack), cuánto tiempo esperó (Waits) y quién lo despertó (ReadyingProcess y ReadyThreadStack). Siguiendo por turnos a quien lo hizo esperar, se puede identificar «el culpable de la lentitud» a nivel de función.

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

Si se puede reproducir el suceso, lo básico es iniciar justo antes de la reproducción, detener justo después y mantenerlo en unos pocos minutos. El valor predeterminado de WPR es el modo Memory, que graba en un búfer circular en memoria; los eventos más antiguos se sobrescriben primero, así que sirve para esperar un suceso cuyo momento se desconoce. El modo File, activado con -filemode, conserva todo en un archivo continuo, pero su único techo es el espacio libre en disco, y un archivo demasiado grande puede dejar de ser analizable en WPA. Use el modo Memory para una espera larga y el modo File para una reproducción corta y fiable.

¿Cuándo usar PerfView y cuándo WPA?

Ambas herramientas tratan trazas ETW, pero sus fuertes difieren. PerfView entiende en profundidad el runtime de .NET y destaca en investigaciones propias de aplicaciones administradas, como GC, asignaciones y JIT. WPA conviene para leer la CPU, el disco, la E/S de archivos, la energía y más de todo el sistema operativo a través de gráficos y tablas, y es la primera opción cuando «no es una aplicación concreta la que va lenta, sino todo el PC», «intervienen varios procesos» o «se sospecha de algo externo a la aplicación (antivirus, un controlador, otro proceso)». Como regla práctica: lentitud de la propia aplicación .NET sola, PerfView; lentitud de todo el sistema, WPR/WPA.

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

Una captura corta es habitual en la práctica, pero no es incondicionalmente segura. ETW es ligero, pero registra un gran volumen de eventos con pilas, así que consume una cantidad determinada de CPU y memoria. Incluya consideraciones como iniciar justo antes del paso de reproducción y detener justo después, mantener la captura en unos pocos minutos y ejecutarla en un momento de poco impacto en el negocio, en el mismo proceso de aprobación que cualquier cambio ordinario. Además, un archivo ETL contiene información interna del sistema, como nombres de proceso, rutas de archivo y datos de ejecutables, así que conviene decidir de antemano cómo se tratará si sale de la empresa (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.