WPR/WPA en pratique — Introduction à l'analyse des performances à l'échelle du système pour « tout le PC est lent »

« Tout le PC est devenu lent après que nous avons installé une application, mais le Gestionnaire des tâches montre de la marge à la fois en CPU et en mémoire. » « Une seule machine met 3 minutes à démarrer. » Ce qui rend ces consultations difficiles, c’est que vous ne savez même pas quel processus regarder.

Même lorsque l’application A est celle qui est lente, la cause peut être un scan antivirus, des écritures massives d’un autre service, ou une chaîne de verrous qui traverse plusieurs processus. Ce dont vous avez besoin, c’est d’enregistrer l’activité de l’OS tout entier sur une seule chronologie et de suivre où le temps a disparu.

Les outils pour cela sont Windows Performance Recorder (WPR) et Windows Performance Analyzer (WPA). WPR capture l’enregistrement avec ETW (Event Tracing for Windows), et WPA lit cet enregistrement en graphiques et tableaux. Vous examinez, le long de la chronologie, quels processus et quelles piles ont utilisé le CPU, ce qu’attendait chaque thread, et quel processus a émis des E/S disque vers quel fichier.

La question à laquelle cet article répond est « comment enregistrer une lenteur à l’échelle du système, et lequel du CPU, du temps d’attente et des E/S examine-t-on ? ». Cet article s’adresse aux responsables informatiques des PME et aux développeurs d’applications Windows. Il couvre, à partir des sources primaires en août 2026, tout le chemin de la pratique de la capture jusqu’à l’analyse. Lisez-le avec comme axe directeur la différence entre « le CPU est élevé » et « le CPU est bas mais c’est encore lent ».

En quoi cela diffère de Process Monitor, qui examine l’accès aux fichiers et au registre, et de PerfView, qui suit le CPU et le GC d’une application .NET, est exposé au chapitre 2.

1. D’abord la conclusion

Le flux de base est « capturer avec WPR → restreindre à l’intervalle du problème dans WPA → isoler CPU, attentes ou E/S ». Même un problème qu’un seul processus n’explique pas peut s’investiguer en suivant tous les processus et le noyau sur la même chronologie.¹²

Séparer le lieu de capture du lieu de lecture

L’outil de capture wpr.exe est fourni avec Windows 8.1 et versions ultérieures, donc aucune installation supplémentaire n’est nécessaire. L’édition graphique, WPRUI, et l’outil d’analyse WPA sont inclus dans le Windows ADK. Parce que vous pouvez scinder le travail ainsi — « dans l’environnement client, uniquement capturer avec wpr.exe ; la lecture se fait dans WPA sur votre propre machine » —, vous pouvez capturer même sur un serveur où aucun logiciel ne peut être ajouté.¹²

Pour un incident que vous pouvez reproduire, les trois étapes de base sont, avec des privilèges d’administrateur, wpr -start GeneralProfile -filemode → reproduire l’incident → wpr -stop C:\temp\trace.etl.³ Préparez le dossier de destination, obtenez l’approbation de la capture, et décidez comment l’ETL sera traité avant d’exécuter. L’attente d’un incident et les problèmes pendant le démarrage appellent d’autres méthodes de capture ; voir le chapitre 3 et le chapitre 8.

Le premier graphique à ouvrir dans WPA

Restreignez d’abord à l’intervalle de l’incident, puis choisissez la direction d’investigation dans le tableau suivant.⁴⁵

Sampled montre la décomposition du temps CPU à partir d’échantillons pris environ toutes les millisecondes.⁶ Precise suit les attentes à partir d’un enregistrement complet des commutations de contexte. Suivre la partie qui a levé une attente, en prenant Waits → ReadyingProcess → ReadyThreadStack comme indices, est la technique que cet article veut le plus transmettre.⁴⁷

Comment lire cet article selon l’objectif

Si vous êtes chargé de la capture, commencez par le chapitre 2 et le chapitre 3 ; si vous lisez une ETL déjà capturée, commencez par le chapitre 4. Lire les piles par nom de fonction exige une configuration des symboles, et pour votre propre application vous ajoutez le chemin de ses PDB.⁸ Lorsque vous investiguez du code JIT .NET, les événements CLR au moment de la capture sont également requis, donc consultez les notes .NET du chapitre 4 avant de capturer.

Le déroulement global de l’investigation et le traitement de l’ETL sont résumés au chapitre 9. Une ETL contient des informations internes telles que les noms de processus et les chemins de fichiers, donc limitez la capture au minimum nécessaire et décidez à l’avance les conditions de sa remise hors de l’entreprise.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (16 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. La place des outils — WPR capture, WPA lit

Windows Performance Toolkit (WPT) est l’ensemble d’outils d’investigation des performances inclus dans le Windows ADK (Windows Assessment and Deployment Kit), et son cœur est le couple WPR et WPA.² Leurs rôles sont clairement séparés.

WPR capture, WPA analyse

• WPR (Windows Performance Recorder) = capture. Il regroupe des fournisseurs ETW en unités appelées « profils », démarre et arrête l’enregistrement, et produit un fichier ETL. L’édition en ligne de commande, wpr.exe, est fournie avec Windows 8.1 et versions ultérieures, sans installation supplémentaire. L’édition graphique (WPRUI.exe) est incluse dans l’ADK.¹
• WPA (Windows Performance Analyzer) = analyse. Il ouvre un fichier ETL et l’analyse en graphiques et tableaux. L’installation de l’ADK est requise.²

Autrement dit, si tout ce que vous faites est de capturer en ligne de commande, vous n’avez pas besoin d’installer de logiciel supplémentaire dans l’environnement client. Capturez avec le wpr.exe standard de l’OS, ramenez le fichier ETL, et lisez-le dans WPA sur votre propre PC — la même scission que « capturer avec pktmon, lire dans Wireshark » dans la capture de paquets.

flowchart LR
    accTitle: La scission entre capturer avec WPR et lire avec WPA
    accDescr: Dans l'environnement client, enregistrer avec le wpr.exe standard de l'OS pour produire un fichier ETL, le ramener, et l'analyser dans WPA installé via l'ADK sur votre propre PC
    subgraph customer["Environnement client (sans installation supplémentaire)"]
        wpr["wpr -start → reproduire l'incident → wpr -stop"] --> etl["Fichier ETL"]
    end
    subgraph office["Votre propre PC (WPA installé via l'ADK)"]
        wpa["Analyse en graphiques et tableaux dans WPA"]
    end
    etl -->|"Ramener"| wpa

Choisir entre Procmon, PerfView et WPR/WPA

Classons d’abord aussi en quoi cela diffère d’outils voisins.

Si Procmon est le journal d’opérations de « ce qu’il a fait » et PerfView « ce qui s’est passé à l’intérieur de .NET », WPA est l’outil qui audite « où le temps a disparu » à travers tous les processus.

Lorsque vous voulez aussi enregistrer les événements de votre propre application

Le fonctionnement d’ETW lui-même et la façon d’instrumenter votre propre application avec ETW sont traités dans « Introduction au journal des événements Windows et à ETW ». Si votre application émet des événements ETW, ses jalons sont enregistrés dans la même trace, ce qui rend la corrélation bien plus facile.

Notez toutefois que WPR n’enregistre que les événements des fournisseurs activés par le profil d’enregistrement que vous avez choisi. GeneralProfile n’inclut pas votre propre fournisseur. Pour les enregistrer ensemble, préparez un profil d’enregistrement personnalisé (.wprp) qui active votre fournisseur et combinez-le comme dans wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, en indiquant le nom de profil à l’intérieur du fichier .wprp après !³.

3. La capture en pratique (WPR) — start, reproduire, stop

Ce qu’il faut décider avant d’exécuter

Dans un environnement de production, ne supposez pas que même une capture courte est inconditionnellement sûre. ETW est léger, mais enregistrer un grand volume d’événements avec des piles consomme une certaine quantité de CPU et de mémoire. Choisissez un moment à faible impact métier, et faites-le passer par le même processus d’approbation que n’importe quel changement ordinaire.

Si vous pouvez reproduire l’incident, démarrez juste avant, arrêtez juste après, et restez dans quelques minutes. Préparez le dossier de destination, et décidez à l’avance qui reçoit l’ETL, combien de temps elle est conservée, et comment elle est supprimée. Les précautions sur son contenu sont au chapitre 9.

Ce qui suit est un exemple de capture, en mode File, d’un incident que vous pouvez reproduire sur place. Pour un incident dont le moment est inconnu, allez au mode Memory dans la section 3.1 ; pour les problèmes pendant le démarrage ou l’ouverture de session, allez au chapitre 8.

Une capture normale est « start → reproduire → stop »

Exécutez ceci dans une invite de commandes ouverte en tant qu’administrateur. -profiles liste les profils disponibles au préalable, et -status vérifie l’état pendant la capture. Le -cancel à la fin ne sert qu’à abandonner en cours de route et à jeter ; il ne fait pas partie de la procédure normale de sauvegarde.

:: Lister les profils intégrés que vous pouvez utiliser
wpr -profiles

:: 1. Démarrer la capture (profil polyvalent, mode fichier)
wpr -start GeneralProfile -filemode

:: 2. Reproduire l'incident (vérifier l'état de la capture avec wpr -status)

:: 3. Arrêter et enregistrer (vous pouvez joindre une description du problème).
::    Créer le dossier de destination à l'avance (sans lui, -stop échoue à enregistrer)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduit : tout le PC devient lent pendant le démarrage de l'application X"

:: Pour abandonner en cours de route, jeter sans enregistrer
wpr -cancel

Choisir ce qu’on enregistre avec un profil

Ce que vous passez à -start est un profil, un lot des fournisseurs ETW dont l’investigation a besoin.³ Se souvenir seulement de ceux qu’on utilise souvent suffit.⁹

Vous pouvez spécifier plusieurs profils à la fois en répétant -start (par exemple wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: Flux de capture WPR et choix du mode
    accDescr: Un incident reproductible localement se capture brièvement et de façon fiable en mode fichier ; un incident dont le moment est inconnu s'attend dans le tampon circulaire du mode mémoire par défaut. Un incident pendant le démarrage ou l'ouverture de session utilise une trace de démarrage. Dans tous les cas, la procédure start, reproduire, stop est la même
    q{"Quand l'incident se produit-il ?"}
    q -->|"Reproductible localement"| file["Capturer brièvement et de façon fiable avec -filemode"]
    q -->|"Moment inconnu"| mem["L'attendre en mode Memory (défaut, tampon circulaire) (section 3.1)"]
    q -->|"Pendant le démarrage ou l'ouverture de session"| boot["Trace de démarrage (chapitre 8)"]
    file --> s1["wpr -start → reproduire ou attendre l'incident → wpr -stop"]
    mem --> s1

3.1. Mode Memory et mode File — pouvez-vous le reproduire, ou l’attendez-vous ?

WPR a deux modes de destination d’enregistrement, et le défaut est le mode Memory (un tampon circulaire en mémoire).

Le mode Memory sert à attendre qu’un incident se produise. Parce que c’est un tampon circulaire qui écrase d’abord les événements les plus anciens, il convient pour laisser la capture tourner pendant que vous attendez un incident dont le moment est inconnu, et arrêter une fois qu’il se produit.

Le mode File sert aux incidents que vous pouvez reproduire de façon fiable en peu de temps. Ajouter -filemode bascule en mode File, et tout est enregistré dans un fichier continu. Rien n’est perdu par écrasement, mais en échange le seul plafond est l’espace disque libre, et le fichier croît sans borne.¹⁰

flowchart LR
    accTitle: Comment le mode Memory et le mode File enregistrent
    accDescr: Le mode Memory enregistre dans un tampon circulaire en mémoire où les événements les plus anciens sont écrasés et seuls les plus récents restent, donc il convient à l'attente. Le mode File conserve tout dans un fichier, mais le seul plafond est l'espace disque libre, donc il convient à une reproduction courte et fiable
    ev["Flux d'événements ETW"] --> ring["Mode Memory : tampon circulaire (les plus anciens écrasés en premier → seuls les plus récents restent)"]
    ev --> filem["Mode File : tout est conservé dans un fichier (le plafond est l'espace disque libre)"]
    ring -.-> use1["Convient pour attendre un incident dont le moment est inconnu"]
    filem -.-> use2["Convient pour un incident que vous pouvez reproduire de façon fiable en peu de temps"]

La règle empirique pour choisir est la suivante.

• Reproductible sur place → mode File. Démarrer juste avant la reproduction, arrêter juste après, et garder la capture dans quelques minutes
• Moment inconnu → Attendre en mode Memory (le défaut). Dès que cela se produit, exécuter wpr -stop
• Même quelques minutes de GeneralProfile peuvent produire une ETL de l’ordre de centaines de Mo à des Go. Un fichier trop grand peut devenir inanalysable dans WPA, donc « plus la capture est longue, mieux c’est » est contre-productif¹⁰¹¹

Capturer depuis l’interface graphique

Pour capturer depuis l’interface graphique, démarrez WPRUI, choisissez un profil et un Logging mode, puis cliquez sur Start puis Save. Les détails de la procédure sont dans les rubriques How-to officielles.¹¹ Lorsque vous demandez à un contact chez le client de capturer, vous pouvez aussi rédiger une procédure centrée sur les étapes start, reproduire et stop, avec les prérequis et l’opération d’abandon présentés à part.

4. Les bases de la lecture de WPA — graphiques, règle d’or des tableaux, et restriction de la plage de temps

Lorsque vous ouvrez l’ETL capturée dans WPA, le Graph Explorer à gauche liste des miniatures de graphiques dans des catégories telles que System Activity, Computation, Storage et Memory.¹² Faites glisser le graphique voulu sur l’onglet Analysis à droite, et le graphique apparaît en haut avec un tableau en dessous.

Les trois choses à maîtriser sont l’ordre des colonnes, la restriction de la plage de temps, et la configuration des symboles. Plutôt que de réapprendre les opérations pour chaque graphique, partez de cette façon commune de lire.

4.1. L’ordre des colonnes décide de l’agrégation

Un tableau WPA a deux barres verticales, une dorée et une bleue : les colonnes à gauche de la barre dorée hiérarchisent (groupent) les données dans cet ordre, et les colonnes à droite de la barre bleue sont des valeurs agrégées.¹³

Les ordonner « Process → Stack » donne une agrégation de piles par processus ; « Stack → Process » une agrégation sur tous les processus qui utilisent la même pile. Faire glisser les colonnes pour les réordonner est lui-même l’acte d’analyse. Une fois ce point compris, tous les tableaux WPA se lisent de la même façon.

flowchart LR
    accTitle: La règle d'or des tableaux — les deux barres et les rôles des colonnes
    accDescr: L'ordre des colonnes à gauche de la barre dorée hiérarchise les données, les colonnes entre les barres dorée et bleue sont des colonnes d'affichage, et les colonnes à droite de la barre bleue sont des valeurs agrégées. Faire glisser les colonnes pour les réordonner est lui-même l'acte d'analyse
    left["À gauche de la barre dorée : colonnes de groupement (ordre = hiérarchie)"] --> gold["Barre dorée"]
    gold --> mid["Entre les barres : colonnes d'affichage"]
    mid --> blue["Barre bleue"]
    blue --> right["À droite de la barre bleue : valeurs agrégées (Sum, %, etc.)"]
    left -.-> op["Faire glisser une colonne = un acte d'analyse (Process → Stack donne une agrégation de piles par processus)"]

4.2. Restreindre à l’intervalle où l’incident s’est produit

Faites glisser sur le graphique pour sélectionner une plage, puis cliquez droit et choisissez « Zoom », et l’agrégation passe à cet intervalle seulement. Le principe de l’investigation de performances est de toujours regarder uniquement « l’intervalle où l’incident se produisait » (chapitre 9).

4.3. Charger les symboles et voir les piles par nom de fonction

Pour lire les piles par nom de fonction, exécutez Trace > Load Symbols dans le menu.¹⁴ Par défaut, il se réfère au serveur public de symboles de Microsoft (msdl.microsoft.com), donc les piles de Windows lui-même se résolvent tant que vous avez une connexion Internet.

Pour voir aussi les noms de fonctions de votre propre application, ajoutez le dossier contenant les PDB de l’application dans Trace > Configure Symbol Paths.⁸ Ce qu’est un PDB, et pourquoi vous devriez toujours en conserver un même pour les builds de publication, est résumé dans « Qu’est-ce qu’un PDB (Program Database) ? ».

Pour .NET, traiter séparément les images NGen et le code JIT

Pour les images natives NGen de .NET Framework, WPR génère des PDB NGen (.ngenpdb) au moment de la capture, les place dans un dossier à côté de la trace, et WPA s’y réfère automatiquement.⁸ Ce mécanisme est propre aux images NGen ; votre propre code dans une application .NET ordinaire qui s’exécute sous le JIT n’est pas couvert.

La correspondance entre adresses de code JIT et noms de fonctions se résout à partir des événements JIT que la CLR émet. Donc, lorsque vous investiguez une application .NET, préparez un profil d’enregistrement (.wprp) qui active les fournisseurs CLR (Microsoft-Windows-DotNETRuntime et son homologue Rundown), combinez-le sous la forme wpr -start GeneralProfile -start MyDotNet.wprp!ProfileName, comme pour votre propre fournisseur au chapitre 2, afin que les événements CLR soient inclus dans la trace (vous pouvez vérifier quels profils intégrés votre WPR local propose avec wpr -profiles).

Par-dessus cela, conservez les PDB générés par la compilation pour la correspondance avec les lignes source, et ajoutez-les au chemin de symboles décrit plus haut.

flowchart TB
    accTitle: Résolution des symboles pour lire les piles par nom de fonction
    accDescr: Lorsque vous exécutez Trace Load Symbols, Windows lui-même se résout depuis le serveur public de symboles de Microsoft et votre propre application depuis les PDB de compilation ajoutés au chemin de symboles. Les images NGen se résolvent depuis les PDB NGen que WPR génère, et le code .NET JIT depuis les événements JIT CLR dans la trace plus les PDB de compilation
    load["Trace > Load Symbols"] --> ms["Windows lui-même : serveur public de symboles (msdl)"]
    load --> own["Votre propre application : PDB de compilation ajoutés dans Configure Symbol Paths"]
    load --> ngen["Images NGen de .NET Framework : .ngenpdb générés par WPR"]
    load --> jit["Code .NET JIT : événements JIT CLR dans la trace + PDB de compilation"]

4.4. Décider d’investiguer le CPU, les attentes ou les E/S

Une fois prêt, regardez si le CPU était élevé ou bas pendant l’intervalle de l’incident. S’il était élevé, allez à Sampled au chapitre 5. S’il était bas, vérifiez d’abord si un cœur ou un thread particulier est saturé ; sinon, suivez les attentes avec Precise au chapitre 6. Si le disque est suspecté, allez au chapitre 7.

flowchart TB
    accTitle: Choisir un graphique WPA d'après le symptôme
    accDescr: Zoomer sur l'intervalle de l'incident ; si le CPU est élevé aller à CPU Usage Sampled ; s'il est bas mais que c'est lent, vérifier un cœur saturé puis faire l'analyse d'attente dans CPU Usage Precise ; si le disque est suspecté aller à Disk Usage et File IO
    zoom["Zoomer sur l'intervalle de l'incident"] --> cpu{"CPU dans cet intervalle ?"}
    cpu -->|"Élevé"| sampled["Chapitre 5 : CPU Usage (Sampled) pour « qui consomme du CPU dans quelle fonction »"]
    cpu -->|"Bas mais lent"| core{"Un cœur ou un thread saturé ?"}
    core -->|"Oui"| sampled
    core -->|"Non"| precise["Chapitre 6 : CPU Usage (Precise) pour « ce qu'il attendait »"]
    cpu -->|"Disque suspecté"| disk["Chapitre 7 : Disk Usage / File I/O pour identifier le coupable"]

5. Lorsque le CPU est élevé — « qui consomme du CPU dans quelle fonction » avec CPU Usage (Sampled)

Ce que ce chapitre cherche, c’est le chemin d’appel qui utilise une grande part du temps CPU.

Si le CPU est saturé, ce que vous regardez est CPU Usage (Sampled). Ce sont des données d’échantillonnage qui enregistrent, environ toutes les millisecondes sur chaque CPU, « la pile de quel processus s’exécute en ce moment », et le rapport des nombres d’échantillons est directement la décomposition du temps CPU.⁶

flowchart LR
    accTitle: Fonctionnement de CPU Usage Sampled
    accDescr: Environ toutes les millisecondes, la pile en cours d'exécution sur chaque CPU est enregistrée, et le rapport des échantillons agrégés est la décomposition du temps CPU. Lire en descendant du processus au thread, à la pile et à la fonction. Une activité courte qui se termine entre les échantillons n'est pas capturée
    tick["Interruption environ toutes les 1 ms"] --> snap["Enregistrer la « pile en cours d'exécution » sur chaque CPU"]
    snap --> agg["Agréger les échantillons (rapport = décomposition du temps CPU)"]
    agg --> drill["Descendre Process → Thread → Stack → fonction"]
    snap -.-> miss["Une activité courte qui se termine entre les échantillons n'est pas capturée"]

Descendre du processus à la pile puis à la fonction

1. Depuis Computation dans Graph Explorer, placez CPU Usage (Sampled) sur l’onglet Analysis et sélectionnez le préréglage Utilization by Process, Stack.⁵
2. Regardez les processus par Weight (ou Count) décroissant. Ce qui était « 50 % » dans le Gestionnaire des tâches s’identifie d’abord au niveau du processus.
3. Dépliez la colonne Stack du processus coupable. Les piles sont agrégées en arbre, et descendre le long du chemin où les chiffres ne chutent pas beaucoup à chaque branche vous mène à la fonction qui consomme du CPU. Si les symboles sont résolus, c’est une ligne droite jusqu’à la fonction exacte dans votre propre code.
4. Si déplier l’arbre est fastidieux, basculez l’affichage du graphique sur Flame (graphique en flammes). La largeur est dessinée comme la part de temps CPU, donc le chemin d’appel dominant saute aux yeux. CPU Usage (Sampled) propose aussi un préréglage Flame by Process, Stack.¹³

Sampled ne peut pas mesurer la durée exacte d’une seule exécution

Parce que c’est de l’échantillonnage, une activité courte qui se termine entre les échantillons n’est pas capturée.⁶ Retenez que c’est un outil pour voir « où le CPU a été utilisé au total », pas un outil pour mesurer le temps d’exécution exact de chaque passage.

6. Lorsque le CPU est bas mais que c’est encore lent — CPU Usage (Precise) et analyse d’attente

6.1. Avant l’analyse d’attente, vérifier un cœur saturé

« L’utilisation globale du CPU est faible » ne signifie pas « le CPU n’est pas le goulet d’étranglement ». Sur un PC à 16 cœurs, un travail sériel saturé sur un cœur (un seul thread d’interface qui tourne à fond) n’apparaît qu’à environ 6 % au global.

Vérifiez d’abord, avec Sampled du chapitre 5 ou avec Utilization by CPU dans CPU Usage (Precise), si un cœur ou un thread particulier est saturé. Si rien n’est saturé non plus, partez du principe que le travail n’est pas incapable d’utiliser le CPU mais attend quelque chose, et passez à l’analyse d’attente. À partir d’ici, l’outil est CPU Usage (Precise).

6.2. Séparer « le temps passé à attendre » de « l’attente d’un CPU après le réveil »

Là où Sampled est de l’échantillonnage, Precise est un enregistrement complet des commutations de contexte (changements de thread). Un thread entre en attente, est réveillé par quelqu’un (Ready), et monte sur un CPU — chaque aller-retour de ce type est conservé comme une ligne, et vous pouvez lire les colonnes suivantes.⁷⁴

flowchart LR
    accTitle: Un aller-retour d'attente et les colonnes correspondantes
    accDescr: Un thread entre en attente sur la pile conservée dans NewThreadStack et attend pendant le temps Waits. Quand quelqu'un le réveille, cette partie est conservée dans ReadyingProcess et ReadyThreadStack, et le thread attend le temps Ready pour la contention de CPU avant de s'exécuter à nouveau
    run1["En cours d'exécution"] -->|"Entre en attente (conservé dans NewThreadStack)"| waitst["Attente (Waits (us))"]
    waitst -->|"Quelqu'un le réveille (ReadyingProcess / ReadyThreadStack)"| ready["Ready (attente de contention de CPU)"]
    ready -->|"Monte sur un CPU"| run2["À nouveau en cours d'exécution"]

6.3. Depuis le thread retardé, suivre chaque réveilleur tour à tour

L’ordre de lecture est le suivant.⁴

1. Préparer le graphique et les colonnes

Appliquez le préréglage Utilization by Process, Thread et ajoutez NewThreadStack et ReadyThreadStack aux colonnes.

2. Sélectionner le thread de l’opération retardée

Identifiez d’abord le thread qui exécutait l’opération retardée, par exemple le thread d’interface ou le thread qui traite la requête en cause. Si vous ne regardez que par Waits totaux décroissants, des threads sains qui attendent volontairement, comme une pompe à messages ou un minuteur, arrivent en tête.

Si le CPU Usage (ms) du thread cible est élevé, c’est un problème CPU du chapitre 5 ; si les Waits dominent, c’est un problème d’attente.

3. Voir dans NewThreadStack « ce qu’il faisait quand il s’est arrêté »

Dépliez NewThreadStack. WaitForSingleObject ou EnterCriticalSection signifie une attente de verrou ; à l’intérieur d’une E/S synchrone telle que ReadFile, une attente d’E/S ; à l’intérieur d’une réception de socket, l’attente de la réponse du pair.

4. Voir dans ReadyThreadStack « qui a levé l’attente »

Dépliez ReadyThreadStack et vérifiez ReadyingProcess / ReadyingThreadId. S’il a été réveillé depuis le KiTimerExpiration du noyau, c’était un minuteur (il dormait jusqu’au délai d’attente) ; s’il a été réveillé depuis le traitement d’achèvement d’E/S, cela confirme une attente d’E/S.⁴

5. Répéter la même investigation sur le réveilleur

Si le réveilleur est un autre thread ou un autre processus, investiguez ensuite ce thread avec la même procédure.

Par exemple, une chaîne telle que A attendait que B libère un verrou, B attendait une réponse RPC de C, et C attendait une E/S disque. Suivre cette chaîne jusqu’à sa racine donne le chemin critique du retard.⁷

flowchart LR
    accTitle: La chaîne du chemin critique suivie dans l'analyse d'attente
    accDescr: Voir dans NewThreadStack du thread A retardé ce qu'il faisait quand il s'est arrêté, identifier le réveilleur B depuis ReadyThreadStack et ReadyingProcess, investiguer B avec la même procédure, et suivre jusqu'à l'E/S disque à la racine
    a["Thread A (l'opération retardée)"] -->|"NewThreadStack : arrêté dans une attente de verrou"| b["Thread B (détient le verrou)"]
    b -->|"NewThreadStack : attente d'une réponse RPC"| c["Processus C"]
    c -->|"NewThreadStack : attente d'E/S synchrone"| d["E/S disque (la racine)"]
    d -.->|"L'achèvement réveille C"| c
    c -.->|"La réponse réveille B"| b
    b -.->|"La libération du verrou réveille A (apparaît dans ReadyThreadStack)"| a

Faire de la cause de l’attente une revue de conception

Dans un projet où « nous l’avons rendu multithread mais ça n’a pas accéléré », par exemple, cette procédure montre tous les workers alignés derrière un seul verrou tel quel. Éviter la contention de verrou par la conception est traité dans « Bonnes pratiques de multithreading en pratique : édition .NET », et le mécanisme Windows qui tourne sur des notifications d’achèvement au lieu d’attendre dans une E/S synchrone dans « Les ports d’achèvement d’E/S (IOCP) et le pool de threads .NET ». Épingler dans WPA « qui il attendait » puis le corriger avec ces principes de conception est un flux continu.

7. Disque et E/S de fichiers — identifier « quelqu’un scanne le disque »

Le coupable classique de « tout le PC est lent » n’est pas le CPU mais le disque. Investiguez avec Disk Usage et File I/O dans la catégorie Storage.¹⁵

7.1. Séparer dans Disk Usage « le traitement du périphérique » de « la file d’attente »

Disk Usage est l’enregistrement des E/S disque. Commencez par distinguer les deux colonnes suivantes.⁶

IO Time est toujours au moins égal à Service Time, la différence étant le temps passé dans la file. Si IO Time est beaucoup plus long que Service Time, cette E/S attendait dans la file.⁶

Ne concluez toutefois pas la cause à partir de la seule différence de temps. Qu’un autre processus ait constitué la file, ou que les E/S massives du processus lui-même se soient alignées sur un périphérique lent, n’est pas encore tranché. Regardez la réponse du périphérique lui-même dans Service Time, puis tranchez avec la décomposition par processus, chemin et pile.

7.2. Quel processus a émis des E/S vers quel fichier

Donc, avec le préréglage Utilization by Process, Path Name, Stack, regardez quel processus a émis des E/S vers quel fichier depuis quelle pile, par IO Time ou Size décroissant.¹⁵ Les deux réponses qui reviennent le plus souvent sur le terrain sont celles-ci.

• Le logiciel antivirus scannait chaque fichier. Cela apparaît comme le processus antivirus qui émet un grand volume de lectures pendant l’intervalle où l’application était lente à démarrer. Le nom de processus, le chemin et le volume sont des preuves prêtes à servir dans une discussion sur les paramètres d’exclusion.
• Un autre processus écrivait massivement. Sauvegarde, un indexeur, une journalisation excessive, etc. Le moment où une écriture atteint le disque implique le gestionnaire de cache, donc le fait que « l’instant de l’écriture » et « l’instant où le disque est occupé » peuvent diverger est aussi expliqué dans « Le gestionnaire de cache — quand votre WriteFile atteint-il vraiment le disque ? ».

7.3. Voir la lenteur avant le disque avec File I/O

File I/O est une couche au-dessus : l’enregistrement des opérations sur fichiers que l’application a émises (Create, Read, Write, etc.), et des préréglages tels que Duration by Process, Thread, Type agrègent le temps par nom de fichier et par opération.¹⁵

Un cas où du temps est consommé dans le système de fichiers ou un pilote de filtre avant d’atteindre le disque n’apparaît pas dans Disk Usage, donc l’écart lui-même, « Disk Usage est calme mais File I/O est lent », est un indice. Si vous voulez partir du fonctionnement des E/S synchrones et asynchrones, voir « E/S synchrones et asynchrones — ce que signifie vraiment OVERLAPPED ».

flowchart TB
    accTitle: Les couches différentes vues par File IO et Disk Usage
    accDescr: Une opération fichier de l'application traverse le système de fichiers et les pilotes de filtre et atteint le périphérique disque depuis la file d'E/S de l'OS. File IO enregistre les opérations de la couche supérieure, Disk Usage enregistre les E/S qui ont atteint le disque, et la différence entre IO Time et Disk Service Time montre le temps en file
    app["Application : ReadFile / WriteFile"] --> fio["Système de fichiers et pilotes de filtre (la couche que File I/O voit)"]
    fio --> queue["File d'E/S de l'OS"]
    queue --> dev["Périphérique disque (la couche que Disk Usage voit)"]
    fio -.-> n1["Le temps consommé ici n'apparaît pas dans Disk Usage"]
    queue -.-> n2["IO Time − Disk Service Time = temps en file d'attente"]
    dev -.-> n3["Disk Service Time = temps de traitement du périphérique"]

7.4. Lorsque vous suspectez un manque de mémoire, vérifiez aussi la mémoire physique

Le raisonnement « peut-être qu’il manque de mémoire et qu’il pagine » peut recevoir un premier triage dans le Gestionnaire des tâches et le Moniteur de ressources avant de passer à WPA.

N’écartez pas un manque de mémoire en ne regardant que la mémoire validée. Même avec de la marge en commit, une pression sur la mémoire physique peut rogner les working sets et entretenir les défauts graves. Vérifiez aussi la mémoire physique disponible et « Défauts graves/s » dans le Moniteur de ressources. Pour la façon de les lire, voir l’article Que représente réellement la « mémoire utilisée » sous Windows ?.

8. Démarrage et ouverture de session lents — l’entrée dans la trace de démarrage

Avec le type « le démarrage prend 3 minutes », le problème est fini avant que vous puissiez exécuter wpr -start à la main. WPR a une trace de démarrage, que vous pouvez configurer pour que l’OS commence à enregistrer automatiquement au prochain démarrage.³

Configurer l’enregistrement pour le prochain démarrage, puis enregistrer après le redémarrage

Comme au chapitre 3, décidez l’approbation de la capture et le traitement de l’ETL, puis opérez depuis une invite de commandes ouverte en tant qu’administrateur.

:: 1. Configurer l'enregistrement automatique au prochain démarrage
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Redémarrer (reproduire le démarrage lent)

:: 3. Après le démarrage, arrêter l'enregistrement et sauvegarder (cela lève aussi la configuration)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Le démarrage prend 3 minutes"

flowchart LR
    accTitle: Flux de la trace de démarrage
    accDescr: Configurer l'enregistrement automatique au prochain démarrage avec addboot, puis redémarrer ; l'OS commence à enregistrer automatiquement au démarrage. Sauvegarder avec stopboot après l'ouverture de session lève aussi la configuration. Pour abandonner, lever avec cancelboot
    add["Configurer avec wpr -boottrace -addboot"] --> rebootpc["Redémarrer (reproduire le démarrage lent)"]
    rebootpc --> auto["L'OS commence à enregistrer automatiquement au démarrage"]
    auto --> stop2["Sauvegarder avec -stopboot après l'ouverture de session (lève aussi la configuration)"]
    add -.-> cancel["Pour abandonner, -cancelboot"]

Après la capture, le même triage « CPU, attente ou E/S »

La mesure du démarrage et de l’arrêt que xbootmgr prenait en charge peut aussi s’exécuter dans le WPR actuel avec des options telles que -onoffscenario Boot.³

La trace capturée se lit avec le même outillage que les chapitres précédents. Regardez quel processus a été créé quand, dans l’ordre chronologique, dans le graphique Processes ; zoomez sur l’intervalle où le démarrage est coincé ; et classez-le en CPU, attente ou disque. Des motifs tels que des applications de démarrage qui attendent quelque chose en série, ou un démarrage de service bloqué sur une E/S particulière, apparaissent.

L’analyse de démarrage est une spécialité profonde en elle-même, donc cet article s’arrête à l’entrée : « un incident que vous ne pouvez pas attraper à la main peut tout de même se capturer avec WPR ». Commencez par vous faire une vue d’ensemble avec une trace de démarrage GeneralProfile.

9. Le schéma de travail — classer, zoomer, pile, répéter

Maintenant que les outils sont clairs, voici le schéma de l’investigation dans son ensemble. L’ordre fixer l’heure et restreindre l’intervalle, classer, puis suivre la pile est le même pour chaque symptôme.

De la fixation de l’heure à la vérification de l’hypothèse

1. Fixez l’heure du phénomène. Pas « c’était lent » mais « c’était lent de 10:23:40 à 10:24:10 ». Journaux de l’application, journal des événements, une note de la personne qui opérait — tout convient. Si votre propre application écrit des jalons dans ETW ou le journal des événements, les événements à l’intérieur de la trace servent directement de piquets de temps.
2. Zoomez uniquement sur cet intervalle. Une agrégation sur toute la trace est lissée en moyennes, et l’anomalie qui compte se dilue. L’analyse WPA est toujours une comparaison de « l’intervalle qui était anormal » contre « l’intervalle qui était normal ».
3. Classez d’abord « CPU, attente ou E/S ». Regardez CPU Usage (Sampled) ; s’il brûle, allez au chapitre 5. S’il ne brûle pas, allez aux Waits de CPU Usage (Precise) (chapitre 6). Si IO Time dans Disk Usage est gonflé, allez au chapitre 7. Passer d’abord par cette fourche à trois voies évite de se perdre.
4. Répétez hypothèse → zoom → pile. Si vous pensez « antivirus ? », restreignez à ce processus et confirmez avec la pile. Si cela ne tient pas, passez à l’hypothèse suivante. Ne pas tirer de conclusion avant d’être descendu jusqu’à la pile et de l’avoir confirmée est la discipline de ce type d’investigation.

flowchart LR
    accTitle: La boucle itérative d'une investigation de performances
    accDescr: Fixer l'heure du phénomène, zoomer sur l'intervalle, classer CPU, attente ou E/S, former une hypothèse et restreindre, et confirmer avec la pile. Si elle tient, la cause est confirmée ; sinon, répéter avec l'hypothèse suivante
    time["Fixer l'heure du phénomène"] --> zoomstep["Zoomer sur cet intervalle"]
    zoomstep --> triage["Classer CPU, attente ou E/S"]
    triage --> hypo["Former une hypothèse et restreindre"]
    hypo --> stack["Confirmer avec la pile"]
    stack -->|"Confirmé"| fix["Cause identifiée → corriger"]
    stack -->|"N'a pas tenu"| hypo

Décidez comment traiter l’ETL avant de capturer

Un fichier ETL capture une vue large de l’intérieur du système : les noms de tous les processus, les chemins des fichiers ouverts, les modules chargés, et (selon le profil) les noms de clés de registre.

Une capture standard GeneralProfile n’inclut pas de corps de données tels que le contenu des communications, mais si vous avez activé un fournisseur personnalisé, la charge utile de ses événements (par exemple des chaînes que l’application a enregistrées) entre telle quelle.

Confirmez ce que les fournisseurs que vous avez activés émettent, puis traitez-le comme un fichier suffisamment confidentiel pour justifier des précautions avant qu’il ne quitte l’entreprise. Comme pour la capture de paquets, intégrez dans la procédure une capture minimale, un accord avec le destinataire, et une durée de conservation et une suppression.

flowchart LR
    accTitle: Ce qu'un fichier ETL capture et comment le traiter
    accDescr: Une ETL capture tous les noms de processus, les chemins des fichiers ouverts, les modules, et selon le profil les noms de clés de registre ; activer un fournisseur personnalisé y ajoute aussi sa charge utile. Traitez-la comme confidentielle, et intégrez dans la procédure une capture minimale, un accord avec le destinataire, et une durée de conservation et une suppression
    etl["Fichier ETL"] --> a1["Tous les noms de processus, chemins de fichiers, modules"]
    etl --> a2["(Selon le profil) noms de clés de registre"]
    etl --> a3["Charges utiles de fournisseurs personnalisés (chaînes enregistrées par l'application)"]
    a1 -.-> rule["Traiter comme confidentiel : capture minimale, accord avec le destinataire, durée de conservation et suppression"]
    a2 -.-> rule
    a3 -.-> rule

10. Résumé

Une investigation WPR/WPA peut s’organiser en trois étapes.

1. Capturez l’intervalle dont vous avez besoin. Capturez avec wpr.exe, fourni avec Windows 8.1 et versions ultérieures, et lisez l’ETL dans WPA sur votre propre machine. La base est wpr -start GeneralProfile -filemode → reproduire → wpr -stop trace.etl. Si vous pouvez le reproduire, mode File dans quelques minutes ; si vous l’attendez, mode Memory. Pour une lenteur pendant le démarrage, utilisez wpr -boottrace. Plus long n’est pas mieux, et les informations internes de l’ETL se traitent comme confidentielles.
2. Restreignez la plage de temps et choisissez la direction d’investigation. Dans WPA, à gauche de la barre dorée se trouve le groupement et à droite de la barre bleue les valeurs agrégées. Maîtrisez l’ordre des colonnes, le zoom sur l’intervalle et la configuration des symboles, puis isolez CPU, attentes ou E/S. Fournissez des PDB pour votre propre application, et pour du code JIT .NET vérifiez aussi les événements CLR au moment de la capture.
3. Suivez jusqu’à la pile et vérifiez l’hypothèse. Si le CPU est élevé, descendez du processus à la fonction dans Sampled. Même si le CPU global est bas, vérifiez d’abord un cœur ou un thread saturé, et s’il n’y en a pas, suivez les attentes dans Precise. Pour le disque, ne décidez pas la cause à partir de la seule différence de temps ; regardez la réponse du périphérique et la décomposition de qui a émis les E/S.

Ce que vous suivez dans l’analyse d’attente est NewThreadStack (ce qu’il faisait quand il s’est arrêté) → Waits (combien de temps il a attendu) → ReadyingProcess et ReadyThreadStack (qui l’a réveillé). Investiguez le réveilleur de la même façon, et vous pouvez suivre la chaîne des retards jusqu’à sa racine.

WPA peut au début vous submerger par la quantité d’information à l’écran. Pourtant, une fois que vous tenez « l’ordre des colonnes est le mode d’agrégation » et « Sampled est où le CPU a été utilisé, Precise est qui il attendait », le reste est la répétition de fixer l’heure, zoomer, classer et vérifier la pile. La prochaine fois qu’une consultation arrive en disant « le CPU a de la marge mais c’est encore lent », capturez une trace dans cet ordre et lisez-la.

Articles connexes

• Identifier précisément les lenteurs avec PerfView et dotnet-trace — Introduction pratique à l’analyse des performances .NET
• Guide pratique de Process Monitor (ProcMon) — identifier en 10 minutes un « paramètre non pris en compte » ou un ACCESS DENIED
• Introduction au journal des événements Windows et à ETW — placer les journaux de votre application métier sur les mécanismes standard de l’OS
• Que représente réellement la « mémoire utilisée » sous Windows ── Bien lire Working Set, Private Bytes, Commit et le fichier d’échange
• Réglages de planification du processeur sous Windows - Services d’arrière-plan et cœurs P/E
• Qu’est-ce qu’un PDB (Program Database) ? — Comprendre les informations de débogage, les symboles et Source Link

Domaines de conseil associés

KomuraSoft LLC prend en charge les investigations de problèmes de performances à l’échelle du système tels que « tout le PC est devenu lent et nous ne trouvons pas la cause », « le CPU a de la marge mais l’application est lente », et « un seul environnement particulier est extrêmement lent à démarrer ». Nous traitons le tout comme une mission continue, de la conception de la capture avec WPR/WPA (quel environnement, quel profil, et combien capturer) à l’analyse de la trace jusqu’à la correction de la cause côté application ou côté paramètres.

• Développement d’applications Windows
• Enquête de bogue et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Où obtenir WPR et WPA ? Peut-on les utiliser dans un environnement client où rien ne peut être installé ?

L'outil de capture wpr.exe (l'édition en ligne de commande) est fourni avec Windows 8.1 et versions ultérieures, donc il s'utilise sans installation supplémentaire. L'édition graphique, WPRUI, et l'outil d'analyse WPA (Windows Performance Analyzer) sont inclus dans le Windows ADK (Windows Assessment and Deployment Kit) et exigent une installation séparée. En pratique, si vous scindez le travail ainsi — « dans l'environnement client, capturer uniquement un fichier ETL avec le wpr.exe standard de l'OS, le ramener, et l'analyser dans WPA sur votre propre machine » —, vous pouvez investiguer les performances à l'échelle du système même sur un site où aucun logiciel ne peut être ajouté.

Pourquoi est-ce lent alors que le Gestionnaire des tâches montre du CPU de reste ? Que montre WPA ?

Lorsque l'utilisation du CPU est faible et que c'est encore lent, le travail n'est pas incapable d'utiliser le CPU ; il est arrêté « en attendant quelque chose ». Les cas typiques sont la contention de verrou, l'attente de la fin d'une E/S synchrone et l'attente de la réponse d'un autre processus. Le Gestionnaire des tâches ne montre que le résultat, le chiffre d'utilisation, mais CPU Usage (Precise) dans WPA montre, à partir d'un enregistrement par commutation de contexte, où un thread a commencé à attendre (NewThreadStack), combien de temps il a attendu (Waits) et qui l'a réveillé (ReadyingProcess et ReadyThreadStack). En suivant tour à tour la partie qui l'a fait attendre, vous pouvez identifier « le coupable de la lenteur » au niveau de la fonction.

Combien de temps dois-je capturer une trace ? Le fichier ne va-t-il pas devenir énorme ?

Si vous pouvez reproduire l'incident, la base est de démarrer juste avant la reproduction, d'arrêter juste après, et de rester dans quelques minutes. Le défaut de WPR est le mode Memory, qui enregistre dans un tampon circulaire en mémoire ; les événements plus anciens sont écrasés en premier, donc il convient pour attendre un incident dont le moment est inconnu. Le mode File, activé avec -filemode, conserve tout dans un fichier continu, mais le seul plafond est l'espace disque libre, et un fichier trop grand peut devenir inanalysable dans WPA. Utilisez le mode Memory pour une longue attente et le mode File pour une reproduction courte et fiable.

Quand utiliser PerfView, et quand WPA ?

Les deux outils traitent des traces ETW, mais leurs forces diffèrent. PerfView a une compréhension profonde du runtime .NET et est fort pour les investigations propres aux applications managées, telles que le GC, les allocations et le JIT. WPA convient pour lire le CPU, le disque, les E/S de fichiers, l'alimentation et le reste à l'échelle de l'OS à travers des graphiques et des tableaux, et c'est le premier choix lorsque « ce n'est pas une application spécifique mais tout le PC qui est lent », « plusieurs processus sont impliqués », ou « quelque chose en dehors de l'application (antivirus, un pilote, un autre processus) est suspecté ». Comme règle empirique : lenteur de votre propre application .NET seule, PerfView ; lenteur de tout le système, WPR/WPA.

Est-il acceptable d'exécuter WPR dans l'environnement de production d'un client ?

Une capture courte est courante en pratique, mais ce n'est pas inconditionnellement sûr. ETW est léger, mais il enregistre un grand volume d'événements avec des piles, donc il consomme une certaine quantité de CPU et de mémoire. Intégrez des considérations telles que démarrer juste avant l'étape de reproduction et arrêter juste après, garder la capture dans quelques minutes, et l'exécuter à un moment à faible impact métier, dans le même processus d'approbation que n'importe quel changement ordinaire. Aussi, un fichier ETL contient des informations internes du système telles que les noms de processus, les chemins de fichiers et les détails d'exécutables, donc vous devez décider à l'avance comment il sera traité s'il quitte l'entreprise (minimisation, durée de conservation, suppression).

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.