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

« Ils ont dit que tout le PC est devenu lent après qu’ils ont installé une nouvelle application. Mais quand je regarde le Gestionnaire des tâches, le CPU et la mémoire ont tous deux de la marge. » « Il y a un PC qui met 3 minutes à démarrer. Je n’ai aucune idée de ce qui ne va pas. » — Les consultations de performance arrivent vraiment beaucoup sous cette forme. Ce qu’elles ont en commun, c’est que regarder un processus spécifique ne donne pas de réponse.

Les outils au niveau du processus sont en place. L’accès aux fichiers et au registre se voit avec Process Monitor, et le CPU et le GC d’une application .NET se suivent avec PerfView. Mais un symptôme tel que « tout le PC est lent » ou « le CPU est inactif et c’est encore lent » commence par ne même pas savoir quel processus est le coupable. L’application A peut être lente à cause d’un scan antivirus, ou parce qu’un autre service écrit massivement sur le disque, ou à cause d’une chaîne de verrous qui traverse plusieurs processus. Ce dont vous avez besoin, c’est de données qui ont enregistré non pas l’intérieur d’un processus mais l’OS dans son ensemble sur une seule chronologie.

Les outils pour capturer et lire cela sont Windows Performance Recorder (WPR) et Windows Performance Analyzer (WPA). WPR enregistre l’activité à l’échelle de l’OS sur une base ETW (Event Tracing for Windows), et WPA analyse cet enregistrement en graphiques et tableaux. Qui a utilisé le CPU sur quelle pile, pour qui un thread attendait, quel processus a émis des E/S disque vers quel fichier — des faits un ou deux crans sous le Gestionnaire des tâches restent tous, avec des horodatages.

Destiné au personnel informatique des PME et aux développeurs d’applications Windows, cet article organise la pratique de la capture avec WPR et la façon de lire WPA — en particulier la différence entre investiguer « quand le CPU est élevé » et « quand le CPU est bas et que c’est encore lent » — en s’appuyant sur les sources primaires à août 2026.

1. La conclusion, d’abord

• Le premier choix pour une investigation « tout le PC est lent » est WPR/WPA, qui capture et lit une trace ETW à l’échelle de l’OS. Les problèmes que les outils au niveau du processus (Gestionnaire des tâches, Procmon, PerfView) ne peuvent pas épingler se suivent si vous regardez tous les processus et le noyau sur une seule chronologie.¹²
• L’outil de capture wpr.exe est livré avec Windows 8.1 et versions ultérieures. Vous pouvez l’utiliser sans installation supplémentaire. L’édition graphique (WPRUI) et l’outil d’analyse WPA sont inclus dans le Windows ADK.¹²
• La procédure de base tient en trois lignes. En tant qu’administrateur, wpr -start GeneralProfile -filemode → reproduire le problème → wpr -stop C:\temp\trace.etl. Retenez juste cela et vous pouvez commencer à capturer.³
• La base de terrain est une scission « 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ù vous ne pouvez pas installer de logiciel. C’est la même idée que la capture de paquets « capturer avec un outil standard, lire dans Wireshark ».¹
• La lecture de WPA commence par classer « CPU, attente, ou E/S ». Si le CPU brûle, CPU Usage (Sampled) ; si le CPU est inactif et que c’est encore lent, l’analyse d’attente dans CPU Usage (Precise) ; si le disque est suspecté, Disk Usage — le chemin se scinde au départ.⁴⁵
• CPU Usage (Sampled) montre « quelle fonction a utilisé le CPU » à partir d’un échantillonnage d’environ toutes les 1 milliseconde. Vous pouvez suivre la décomposition des « 50 % » du Gestionnaire des tâches de processus → thread → pile → fonction.⁶
• CPU Usage (Precise) est un enregistrement complet des commutations de contexte, et vous dit « pour qui un thread attendait ». Suivre Waits (temps d’attente), ReadyingProcess (qui l’a réveillé) et ReadyThreadStack (la pile du réveilleur) est la technique que cet article veut le plus transmettre.⁴⁷
• Lire une pile exige une configuration des symboles. WPA se réfère au serveur de symboles public de Microsoft par défaut. Pour voir les noms de fonctions de votre propre application, ajoutez le chemin de vos propres PDB.⁸
• Un fichier ETL contient des informations internes du système telles que les noms de processus et les chemins de fichiers. Gardez la capture au minimum nécessaire, et décidez comment elle sera traitée si elle quitte l’entreprise avant de capturer.

2. Où se situent les outils — WPR capture, WPA lit

Windows Performance Toolkit (WPT) est le jeu d’outils d’investigation des performances inclus dans le Windows ADK (Windows Assessment and Deployment Kit) ; le centre est la paire WPR et WPA.² Les rôles sont clairement scindés.

• WPR (Windows Performance Recorder) = capture. Il regroupe des groupes de fournisseurs ETW en une unité appelée « profil », démarre et arrête l’enregistrement, et produit un fichier ETL. L’édition en ligne de commande, wpr.exe, est livrée 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. Une installation ADK est requise.²

Autrement dit, il n’y a rien que vous ayez besoin de placer dans l’environnement client. Capturer avec le wpr.exe standard de l’OS, ramener le fichier ETL, et le lire dans WPA sur votre propre PC — la même scission que celle de la capture de paquets « capturer avec pktmon, lire dans Wireshark » tient.

flowchart TB
    accTitle: La scission de la capture avec WPR et de la lecture avec WPA
    accDescr: Dans l'environnement client, enregistrez avec le wpr.exe standard de l'OS et produisez un fichier ETL ; ramenez-le et analysez-le dans WPA installé via l'ADK sur votre propre PC
    subgraph customer["PC client（sans installation supplémentaire）"]
        wpr["wpr start → reproduire → stop"] --> etl["Fichier ETL"]
    end
    subgraph office["Votre PC（WPA via l'ADK）"]
        wpa["Analyser graphiques et tableaux"]
    end
    etl -->|"Rapporter"| wpa

Figure 1 : Dans l’environnement client, enregistrez avec le wpr.exe standard de l’OS et produisez un fichier ETL ; ramenez-le et analysez-le dans WPA installé via l’ADK sur votre propre PC.

Comment cela diffère des outils similaires vaut aussi d’être organisé d’abord.

Si Procmon est un journal d’opérations de « ce qu’il a fait » et PerfView « ce qui s’est passé à l’intérieur de .NET », WPA est un outil qui audite « où le temps a disparu » à travers tous les processus. Les mécaniques d’ETW elles-mêmes, et comment instrumenter votre propre application avec ETW, sont couvertes dans « Introduction au journal des événements Windows et à ETW ». Si votre propre application émet des événements ETW, les points de contrôle de votre application sont enregistrés dans la même trace et les aligner devient beaucoup plus facile. WPR, toutefois, n’enregistre que les événements des fournisseurs activés par le profil d’enregistrement que vous avez choisi. GeneralProfile n’inclut pas vos propres fournisseurs, donc si vous voulez les mélanger, préparez un profil d’enregistrement personnalisé (.wprp) qui active vos fournisseurs et combinez-le comme wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, en spécifiant le nom de profil à l’intérieur du fichier .wprp avec !³.

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

La procédure de base dans un terminal administrateur.

:: List of built-in profiles you can use
wpr -profiles

:: 1. Start capture (general-purpose profile, file mode)
wpr -start GeneralProfile -filemode

:: 2. Reproduce the issue (check capture status with wpr -status)

:: 3. Stop and save (you can attach a description of the problem).
::    Create the destination folder in advance (without it, -stop fails to save)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduced the issue where the whole PC becomes slow while starting App X"

:: To abandon without saving
wpr -cancel

Ce que vous passez à -start est un profil, un paquet des fournisseurs ETW dont l’investigation a besoin.³ Retenir seulement ceux que vous utilisez souvent suffit.⁹

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

flowchart TB
    accTitle: Flux de capture WPR et comment choisir un mode
    accDescr: Un problème que vous pouvez reproduire sur place se capture court et de façon fiable en mode fichier ; un problème dont vous ne connaissez pas le moment s'attend dans le tampon circulaire du mode mémoire par défaut. Un problème 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 cela se produit-il ?"}
    q -->|"Sur place"| file["Mode File : capture courte"]
    q -->|"Moment inconnu"| mem["Mode Memory : attendre（3.1）"]
    q -->|"Démarrage ou ouverture de session"| boot["Trace de démarrage（chap. 8）"]
    file --> s1["start → reproduire → stop"]
    mem --> s1

Figure 2 : Un problème que vous pouvez reproduire sur place se capture court et de façon fiable en mode fichier ; un problème dont vous ne connaissez pas le moment s’attend dans le tampon circulaire du mode mémoire par défaut. Un problème 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.

3.1. Mode Memory et mode File — pouvez-vous reproduire, ou attendez-vous

WPR a deux modes de destination d’enregistrement ; le défaut est le mode Memory (un tampon circulaire en mémoire). C’est un tampon circulaire qui écrase à partir des événements les plus anciens, donc il convient pour laisser la capture tourner pendant que vous attendez un problème dont vous ne connaissez pas le moment, et arrêter lorsqu’il se produit. Ajouter -filemode bascule vers le mode File, et tout est enregistré dans un fichier continu. Ceci n’est pas écrasé ; le seul plafond est l’espace disque libre, et le fichier croît sans borne.¹⁰

flowchart TB
    accTitle: Comment le mode Memory et le mode File enregistrent
    accDescr: Le mode Memory enregistre dans un tampon circulaire en mémoire ; les événements plus anciens sont écrasés et seuls les plus récents restent, donc il convient pour attendre. Le mode File conserve tout dans un fichier, mais le seul plafond est l'espace disque libre, donc il convient pour une reproduction courte et fiable
    ev["Événements ETW"] --> ring["Mode Memory : tampon circulaire"]
    ev --> filem["Mode File : faire croître un fichier"]
    ring -.-> use1["Attendre un moment inconnu"]
    filem -.-> use2["Reproduction courte et fiable"]

Figure 3 : Le mode Memory enregistre dans un tampon circulaire en mémoire ; les événements plus anciens sont écrasés et seuls les plus récents restent, donc il convient pour attendre. Le mode File conserve tout dans un fichier, mais le seul plafond est l’espace disque libre, donc il convient pour une reproduction courte et fiable.

Une 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, wpr -stop
• Même quelques minutes de GeneralProfile peuvent produire un ETL de l’ordre de centaines de Mo à des Go. Un fichier trop grand peut devenir inanalysable dans WPA, donc « plus vous capturez longtemps, mieux c’est » est contre-productif¹⁰¹¹

Pour capturer depuis l’interface graphique, démarrez WPRUI, choisissez un profil et un Logging mode, et Start/Save. Le How-to officiel résume la procédure.¹¹ Si vous demandez à un contact sur site client de capturer, les trois commandes ci-dessus peuvent entrer telles quelles dans une procédure.

4. Les bases de la lecture de WPA — Graphiques, la règle d’or des tableaux, et le cadrage du temps

Lorsque vous ouvrez un ETL capturé 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 un graphique que vous voulez voir sur l’onglet Analysis à droite, et un graphique apparaît en haut et un tableau en bas. Les trois premières choses à intégrer sont celles-ci.

1. La règle d’or des tableaux — l’ordre des colonnes décide le groupement. Un tableau WPA a deux barres verticales, or et bleue, et les colonnes à gauche de la barre or hiérarchisent (groupent) les données dans cet ordre, et les colonnes à droite de la barre bleue sont des agrégats.¹³ Arrangez-les Processus → Pile et vous obtenez une agrégation de pile par processus ; Pile → Processus et vous obtenez une agrégation de tous les processus qui utilisent la même pile — faire glisser les colonnes pour les réordonner est elle-même une opération d’analyse. Comprenez ce seul point et chaque tableau WPA se lit de la même façon.

flowchart TB
    accTitle: La règle d'or des tableaux — les deux barres et le rôle des colonnes
    accDescr: Les colonnes à gauche de la barre or hiérarchisent les données dans cet ordre ; les colonnes entre les barres or et bleue sont des colonnes d'affichage ; les colonnes à droite de la barre bleue sont des agrégats. Faire glisser les colonnes pour les réordonner est elle-même une opération d'analyse
    left["À gauche de l'or : groupement"] --> gold["Barre or"]
    gold --> mid["Entre les barres : affichage"]
    mid --> blue["Barre bleue"]
    blue --> right["À droite du bleu : agrégats"]
    left -.-> op["Faire glisser les colonnes pour analyser"]

Figure 4 : Les colonnes à gauche de la barre or hiérarchisent les données dans cet ordre ; les colonnes entre les barres or et bleue sont des colonnes d’affichage ; les colonnes à droite de la barre bleue sont des agrégats. Faire glisser les colonnes pour les réordonner est elle-même une opération d’analyse.

1. Cadrez la plage de temps. Faites glisser sur le graphique pour sélectionner une plage, puis clic droit et « Zoom », et l’agrégation bascule sur cet intervalle seulement. L’investigation de performance consiste toujours, en principe, à ne regarder que « l’intervalle où le problème se produisait » (chapitre 9).
2. Configurez les symboles. Pour lire une pile par nom de fonction, exécutez Trace > Load Symbols depuis le menu.¹⁴ Par défaut il se réfère au serveur de symboles public de Microsoft (msdl.microsoft.com), donc les piles de Windows lui-même peuvent être résolues si vous avez une connexion Internet. Pour voir les noms de fonctions de votre propre application, ajoutez le dossier des PDB de votre application dans Trace > Configure Symbol Paths.⁸ Ce qu’est un PDB, et pourquoi vous devriez toujours le conserver même pour une build Release, est résumé dans « Qu’est-ce qu’un PDB (Program Database) ? ». Pour les images natives NGen de .NET Framework, WPR génère des PDB NGen (.ngenpdb) au moment de la capture et les place dans un dossier à côté de la trace, et WPA s’y réfère automatiquement.⁸ C’est un mécanisme pour les images NGen seulement, et le code JIT .NET ordinaire de votre propre application est hors de portée. Le mappage d’une adresse de code JIT vers un nom de fonction se résout à partir des événements JIT que le 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 le Rundown correspondant) et combinez-le de la même façon que vos propres fournisseurs au chapitre 3, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, afin que les événements CLR soient inclus dans la trace (vous pouvez vérifier quels profils intégrés votre WPR local offre avec wpr -profiles). En plus de cela, conservez les PDB générés par la build pour le mappage vers les lignes source, et ajoutez-les au chemin de symboles ci-dessus.

flowchart TB
    accTitle: Résolution des symboles pour lire une pile par nom de fonction
    accDescr: Exécuter Trace Load Symbols résout Windows lui-même depuis le serveur de symboles public de Microsoft, et votre propre application depuis les PDB de build ajoutés au chemin de symboles. Les images NGen utilisent les PDB NGen que WPR génère ; le code JIT .NET se résout à partir des événements JIT du CLR dans la trace plus les PDB de build
    load["Trace > Load Symbols"] --> ms["Windows : symboles publics"]
    load --> own["Votre application : PDB de build"]
    ms -.-> ngen["NGen : WPR .ngenpdb"]
    own -.-> jit["JIT : événements CLR + PDB"]

Figure 5 : Exécuter Trace Load Symbols résout Windows lui-même depuis le serveur de symboles public de Microsoft, et votre propre application depuis les PDB de build ajoutés au chemin de symboles. Les images NGen utilisent les PDB NGen que WPR génère ; le code JIT .NET se résout à partir des événements JIT du CLR dans la trace plus les PDB de build.

Une fois préparé, vous entrez par la branche suivante. Dans cet intervalle, le CPU était-il élevé, ou bas ? S’il est élevé, chapitre 5 (Sampled) ; s’il est bas et encore lent, chapitre 6 (Precise).

flowchart TB
    accTitle: Branchement pour choisir un graphique WPA à partir du symptôme
    accDescr: Zoomez sur l'intervalle du problème ; si le CPU est élevé allez à CPU Usage Sampled ; s'il est bas et encore lent, vérifiez un pin monocœur / monothread puis l'analyse d'attente dans CPU Usage Precise ; si le disque est suspecté, Disk Usage et File IO
    zoom["Zoomer sur l'intervalle du problème"] --> cpu{"CPU dans cet intervalle ?"}
    cpu -->|"Élevé"| sampled["Chap. 5 : Sampled"]
    cpu -->|"Bas, encore lent"| core{"Pin 1 cœur / 1 thread ?"}
    core -->|"Oui"| sampled
    core -->|"Non"| precise["Chap. 6 : Precise"]
    cpu -->|"Disque suspecté"| disk["Chap. 7 : Disque / E/S fichiers"]

Figure 6 : Zoomez sur l’intervalle du problème ; si le CPU est élevé allez à CPU Usage Sampled ; s’il est bas et encore lent, vérifiez un pin monocœur / monothread puis l’analyse d’attente dans CPU Usage Precise ; si le disque est suspecté, Disk Usage et File IO.

5. Lorsque le CPU est élevé — « Qui brûle quelle fonction » avec CPU Usage (Sampled)

Si le CPU est saturé, ce que vous regardez est CPU Usage (Sampled). Ce sont des données d’échantillonnage qui ont enregistré, environ toutes les 1 milliseconde sur chaque CPU, « quelle pile de quel processus tourne maintenant », et le ratio des comptes d’échantillons est la décomposition du temps CPU telle quelle.⁶

flowchart TB
    accTitle: Comment fonctionne CPU Usage Sampled
    accDescr: Environ toutes les 1 milliseconde, la pile en cours d'exécution sur chaque CPU est enregistrée, et le ratio d'échantillons agrégé est la décomposition du temps CPU. Lisez de processus à thread, pile et fonction. Une activité courte qui se termine entre les échantillons n'apparaît pas
    tick["Interruption environ toutes les 1 ms"] --> snap["Enregistrer la pile en cours"]
    snap --> agg["Ratio d'échantillons = décomposition CPU"]
    agg --> drill["Processus → Thread → Pile"]
    snap -.-> miss["L'activité entre les échantillons est manquée"]

Figure 7 : Environ toutes les 1 milliseconde, la pile en cours d’exécution sur chaque CPU est enregistrée, et le ratio d’échantillons agrégé est la décomposition du temps CPU. Lisez de processus à thread, pile et fonction. Une activité courte qui se termine entre les échantillons n’apparaît pas.

1. Depuis Computation du Graph Explorer, placez CPU Usage (Sampled) sur l’onglet Analysis et choisissez le préréglage Utilization by Process, Stack.⁵
2. Regardez les processus par ordre décroissant de Weight (ou Count). L’identité de ce qui était « 50 % » dans le Gestionnaire des tâches devient claire d’abord au niveau du processus.
3. Développez la colonne Stack du processus coupable. Les piles sont agrégées en arbre, et suivre le chemin où le nombre ne baisse pas beaucoup à une branche vous amène à la fonction qui brûle le CPU. Si les symboles sont résolus, c’est une ligne droite jusqu’à quelle fonction dans votre propre code.
4. Si développer l’arbre est fastidieux, basculez l’affichage du graphique vers Flame. Il est dessiné avec largeur = part du temps CPU, donc quel chemin d’appel domine est évident d’un coup d’œil. CPU Usage (Sampled) a aussi un préréglage Flame by Process, Stack.¹³

Il y a une mise en garde. Parce que c’est de l’échantillonnage, une activité courte qui se termine entre les échantillons n’apparaît pas.⁶ Retenez-le comme un outil pour voir « où le CPU a été utilisé en agrégat », pas un outil pour mesurer la durée exacte par invocation.

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

C’est le cœur de l’article. Avant de passer à l’analyse d’attente, toutefois, il y a une chose à confirmer. « L’utilisation globale du CPU est basse » ne signifie pas « le CPU n’est pas le goulot d’étranglement ». Sur un PC 16 cœurs, un travail sériel épinglé à un cœur (un seul thread UI qui tourne à fond) ne ressemble qu’à environ 6 % au global. Vérifiez d’abord dans le Sampled du chapitre 5 (ou Utilization by CPU de CPU Usage (Precise)) qu’il n’y a pas de pin sur un cœur ou un thread spécifique, et s’il n’y en a pas, venez à ce chapitre — le travail n’est pas incapable de tourner, il attend. Ce qui vous dit ce qu’il attend, c’est CPU Usage (Precise).

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 atterrit sur un CPU — cet aller-retour reste une ligne à la fois, et vous pouvez lire les colonnes suivantes.⁷⁴

flowchart TB
    accTitle: Un aller-retour d'attente et comment les colonnes correspondent
    accDescr: Un thread entre en attente sur la pile qui reste dans NewThreadStack, et attend le temps Waits. Lorsque quelqu'un le réveille, cette partie reste dans ReadyingProcess et ReadyThreadStack ; il attend le temps Ready pour la contention CPU puis tourne à nouveau
    run1["En cours d'exécution"] -->|"Entrer en attente"| waitst["Attente（Waits us）"]
    waitst -->|"Quelqu'un le réveille"| ready["Ready（contention CPU）"]
    ready -->|"Atterrit sur un CPU"| run2["En cours d'exécution à nouveau"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

Figure 8 : Un thread entre en attente sur la pile qui reste dans NewThreadStack, et attend le temps Waits. Lorsque quelqu’un le réveille, cette partie reste dans ReadyingProcess et ReadyThreadStack ; il attend le temps Ready pour la contention CPU puis tourne à nouveau.

Le motif de lecture est le suivant.⁴

1. Appliquez le préréglage Utilization by Process, Thread et ajoutez NewThreadStack et ReadyThreadStack aux colonnes.
2. Identifiez d’abord le thread qui exécutait l’opération retardée (le thread UI, le thread qui traitait la requête en question). Ne regarder que par ordre décroissant de Waits totaux est confus, parce que les threads qui « attendent intentionnellement tout le temps », tels qu’une pompe à messages ou une minuterie, occupent le haut. Une fois que vous avez trouvé le thread cible, si son CPU Usage (ms) est grand c’est un problème CPU du chapitre 5 ; si Waits dominent c’est un problème d’attente.
3. Développez NewThreadStack et voyez ce qu’il faisait lorsqu’il s’est arrêté. WaitForSingleObject ou EnterCriticalSection est une attente de verrou ; à l’intérieur d’une E/S synchrone telle que ReadFile c’est une attente d’E/S ; à l’intérieur d’une réception socket c’est l’attente de la réponse du pair.
4. Ensuite voyez qui a libéré l’attente. Développez ReadyThreadStack et vérifiez ReadyingProcess / ReadyingThreadId. S’il a été réveillé depuis KiTimerExpiration du noyau c’était une minuterie (= il a dormi jusqu’à un délai d’expiration) ; s’il a été réveillé depuis le traitement d’achèvement d’E/S, cela confirme que c’était une attente d’E/S.⁴
5. Si la partie qui l’a réveillé est un autre thread ou un autre processus, investiguez ce thread avec la même procédure. « A attendait que B libère un verrou, B attendait la réponse RPC de C, C attendait une E/S disque » — ce que vous avez lorsque vous avez suivi cette chaîne jusqu’à la racine est le chemin critique du délai.⁷

flowchart TB
    accTitle: La chaîne de chemin critique que vous suivez dans l'analyse d'attente
    accDescr: Voyez dans le NewThreadStack du thread A retardé ce qu'il faisait lorsqu'il s'est arrêté, identifiez le réveilleur B depuis ReadyThreadStack et ReadyingProcess, et investiguez B avec la même procédure jusqu'à l'E/S disque racine
    a["Thread A（travail retardé）"] -->|"Attente de verrou"| b["Thread B（détient le verrou）"]
    b -->|"Attente RPC"| c["Processus C"]
    c -->|"Attente d'E/S sync"| d["E/S disque（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"| a

Figure 9 : Voyez dans le NewThreadStack du thread A retardé ce qu’il faisait lorsqu’il s’est arrêté, identifiez le réveilleur B depuis ReadyThreadStack et ReadyingProcess, et investiguez B avec la même procédure jusqu’à l’E/S disque racine.

Dans un cas tel que « nous l’avons multithreadé et ça n’est pas devenu plus rapide », cette procédure montre chaque worker aligné sur un seul verrou tel quel. Éviter la contention de verrous par conception est couvert dans « Bonnes pratiques de multithreading en pratique — édition .NET », et le mécanisme Windows qui tourne sur une notification d’achèvement au lieu d’attendre dans une E/S synchrone est couvert dans « Les ports d’achèvement d’E/S (IOCP) et le pool de threads .NET ». Épingler « pour qui il attendait » dans WPA et le corriger avec ces arguments de conception est un flux continu.

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

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

Disk Usage est un enregistrement des E/S disque, et deux colonnes comptent. Disk Service Time est le temps que le périphérique disque a réellement passé à traiter cette E/S ; IO Time est le temps depuis l’entrée de l’E/S dans la file d’attente de l’OS jusqu’à son achèvement. IO Time est toujours au moins Service Time du montant de la mise en file, donc si IO Time est beaucoup plus long que Service Time, cette E/S « attendait dans la file ».⁶ Cela seul, toutefois, ne décide pas si le coupable qui a fait la file est un autre processus, ou seulement les E/S lourdes de ce processus lui-même alignées sur un périphérique lent. Ne tirez pas la conclusion ici ; réglez-la avec Service Time (la réponse propre du périphérique) et la décomposition suivante par processus, chemin et pile.

Ensuite, 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 ordre décroissant d’IO Time ou de Size.¹⁵ Les réponses qui remontent souvent sur le terrain sont ces deux-là.

• L’antivirus scannait chaque fichier. Dans la fenêtre où l’application était lente à démarrer, le processus antivirus est vu émettre un grand volume de lectures. Nom de processus, chemin et volume sont des preuves telles quelles pour une discussion d’exclusions.
• Un autre processus écrivait massivement. Sauvegarde, l’indexeur, des journaux écrits trop, et analogues. Quand une écriture atteint le disque implique le gestionnaire de cache, donc le fait que « le moment où vous avez écrit » et « le moment où le disque est occupé » peuvent diverger est aussi couvert dans « Le gestionnaire de cache — Quand votre WriteFile atteint-il vraiment le disque ? ».

File I/O est une couche plus haut, un enregistrement des opérations de fichier que l’application a émises (Create/Read/Write et analogues), et des préréglages tels que Duration by Process, Thread, Type peuvent agréger le temps par nom de fichier et par opération.¹⁵ Un cas qui passe du temps dans le système de fichiers ou un pilote de filtre avant d’atteindre le disque n’apparaît pas dans Disk Usage, donc le décalage lui-même — « Disk Usage est calme mais File I/O est lent » — est un indice. Si vous voulez partir des mécaniques des E/S synchrones et asynchrones, voir « E/S synchrones et asynchrones — ce que signifie vraiment OVERLAPPED ».

flowchart TB
    accTitle: Les couches différentes que File IO et Disk Usage voient
    accDescr: L'opération de fichier d'une application voyage à travers le système de fichiers et les pilotes de filtre depuis la file d'E/S de l'OS jusqu'au périphérique disque. File IO enregistre les opérations à la couche supérieure ; Disk Usage enregistre les E/S qui ont atteint le disque ; la différence entre IO Time et Disk Service Time est le temps de file
    app["Application : ReadFile / WriteFile"] --> fio["FS et filtres（File I/O）"]
    fio --> queue["File d'E/S de l'OS"]
    queue --> dev["Périphérique disque（Disk Usage）"]
    fio -.-> n1["Manqué par Disk Usage"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = périphérique"]

Figure 10 : L’opération de fichier d’une application voyage à travers le système de fichiers et les pilotes de filtre depuis la file d’E/S de l’OS jusqu’au périphérique disque. File IO enregistre les opérations à la couche supérieure ; Disk Usage enregistre les E/S qui ont atteint le disque ; la différence entre IO Time et Disk Service Time est le temps de file.

La ligne de pensée « peut-être qu’il manque de mémoire et qu’il swap » peut recevoir un premier isolement dans le Gestionnaire des tâches et le Moniteur de ressources avant d’aller à WPA. Ne le rejetez toutefois pas à partir de la mémoire committed seule — même avec de la marge de commit, une situation où la pression sur la mémoire physique réduit le working set et où les hard faults continuent est possible. Vérifiez aussi la mémoire physique disponible et les « Hard Faults/sec » du Moniteur de ressources. Comment les lire est dans « Que représente réellement la « mémoire utilisée » sous Windows ? ».

8. Démarrage et ouverture de session lents — L’entrée d’une trace de démarrage

Un type « ça met 3 minutes à démarrer » se termine avant que vous puissiez lancer à la main wpr -start. WPR a une trace de démarrage, et vous pouvez arranger que l’OS commence à enregistrer automatiquement au prochain démarrage.³

:: 1. Arrange automatic recording on the next boot
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduce the slow boot)

:: 3. After boot, stop recording and save (the arrangement is also cleared)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Issue where boot takes 3 minutes"

flowchart TB
    accTitle: Flux de la trace de démarrage
    accDescr: Après avoir arrangé l'enregistrement automatique au prochain démarrage avec addboot et redémarré, l'OS commence à enregistrer automatiquement au démarrage. Enregistrer avec stopboot après l'ouverture de session efface aussi l'arrangement. Pour abandonner, effacez-le avec cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["Redémarrer（démarrage lent）"]
    rebootpc --> auto["L'OS enregistre au démarrage"]
    auto --> stop2["Après ouverture de session : -stopboot"]
    add -.-> cancel["Abandonner : -cancelboot"]

Figure 11 : Après avoir arrangé l’enregistrement automatique au prochain démarrage avec addboot et redémarré, l’OS commence à enregistrer automatiquement au démarrage. Enregistrer avec stopboot après l’ouverture de session efface aussi l’arrangement. Pour abandonner, effacez-le avec cancelboot.

La mesure de démarrage et d’arrêt que xbootmgr possédait autrefois peut aussi s’exécuter dans le WPR actuel avec des options telles que -onoffscenario Boot.³ Une trace capturée se lit avec le même jeu d’outils que les chapitres précédents. Regardez quel processus est né quand sur une chronologie dans le graphique Processes, zoomez sur la fenêtre où le démarrage est coincé, et classifiez CPU, attente ou disque — une application de démarrage qui attend quelque chose en série, un démarrage de service coincé sur une E/S spécifique, et analogues deviennent visibles. L’analyse de démarrage est une spécialité profonde à part entière, donc cet article ne va que jusqu’à l’entrée : « un problème que vous ne pouvez pas attraper à la main peut encore être capturé avec WPR ». Commencez par saisir le tableau d’ensemble avec une trace de démarrage GeneralProfile.

9. Un motif de travail — Classer → Zoomer → Pile, répété

Maintenant que les outils sont clairs, voici le motif pour l’investigation dans son ensemble.

1. Épinglez l’heure du phénomène. Pas « c’était lent », mais « 10:23:40–10:24:10 était lent ». Journaux de l’application, journal des événements, une note de la personne qui a opéré — n’importe quoi fera l’affaire. Si votre propre application écrit des points de contrôle dans ETW ou le journal des événements, les événements à l’intérieur de la trace deviennent des piquets de temps tels quels.
2. Zoomez sur cet intervalle seulement. Une agrégation de toute la trace est moyennée, et l’anomalie qui compte est diluée. L’analyse WPA est toujours une comparaison de « l’intervalle qui était anormal » versus « l’intervalle qui était normal ».
3. Classez d’abord « CPU, attente, ou E/S ». Regardez CPU Usage (Sampled) ; s’il brûle, chapitre 5. S’il ne brûle pas, Waits dans CPU Usage (Precise) (chapitre 6). Si Disk Usage IO Time est gonflé, chapitre 7. Prendre cette fourche à trois d’abord vous empêche de vous perdre.
4. Répétez hypothèse → zoom → pile. Si vous pensez « antivirus ? », cadrez sur ce processus et étayez-le avec la pile. Si ça ne tient pas, l’hypothèse suivante. Ne pas tirer de conclusion avant d’avoir suivi jusqu’à la pile et de l’avoir étayée est la discipline de ce type d’investigation.

flowchart TB
    accTitle: La boucle itérative d'une investigation de performance
    accDescr: Épinglez l'heure du phénomène, zoomez sur l'intervalle, classifiez CPU / attente / E/S, formez une hypothèse et cadrez, et étayez-la avec la pile. Si elle tient, la cause est confirmée ; si elle ne tient pas, répétez avec l'hypothèse suivante
    time["Épingler l'heure"] --> zoomstep["Zoomer sur cet intervalle"]
    zoomstep --> triage["Classifier CPU / attente / E/S"]
    triage --> hypo["Hypothèse et cadrage"]
    hypo --> stack["Étayer avec la pile"]
    stack -->|"Ça tient"| fix["Cause confirmée"]
    stack -->|"Ça ne tient pas"| hypo

Figure 12 : Épinglez l’heure du phénomène, zoomez sur l’intervalle, classifiez CPU / attente / E/S, formez une hypothèse et cadrez, et étayez-la avec la pile. Si elle tient, la cause est confirmée ; si elle ne tient pas, répétez avec l’hypothèse suivante.

Enfin, le traitement du fichier de capture. Un fichier ETL reflète largement l’intérieur du système : les noms de chaque processus, les chemins des fichiers qui ont été ouverts, les modules qui ont été chargés, et (selon le profil) les noms de clés de registre. Une capture GeneralProfile standard n’inclut pas les corps de données tels que les contenus de communication, mais si vous avez activé un fournisseur personnalisé, la charge utile de cet événement (chaînes que l’application a enregistrées, et analogues) entre telle quelle. Après avoir confirmé ce que les fournisseurs que vous avez activés émettent, traitez-le comme un fichier suffisamment confidentiel pour quitter l’entreprise. Comme pour la capture de paquets, intégrez la capture au minimum nécessaire, l’accord avec la partie à qui vous le remettez, et une durée de conservation et une suppression dans la procédure.

flowchart TB
    accTitle: Ce qu'un fichier ETL reflète, et comment le traiter
    accDescr: Un ETL reflète chaque nom de processus, les chemins des fichiers qui ont été ouverts, les modules, et selon le profil les noms de clés de registre ; activer un fournisseur personnalisé inclut aussi sa charge utile. Traitez-le comme confidentiel : capture au minimum nécessaire, accord avec l'autre partie, et une durée de conservation et une suppression
    etl["Fichier ETL"] --> a1["Noms, chemins, modules"]
    a1 --> a2["Clés de registre（certaines）"]
    a2 --> a3["Charge utile personnalisée"]
    a3 -.-> rule["Traiter comme confidentiel"]

Figure 13 : Un ETL reflète chaque nom de processus, les chemins des fichiers qui ont été ouverts, les modules, et selon le profil les noms de clés de registre ; activer un fournisseur personnalisé inclut aussi sa charge utile. Traitez-le comme confidentiel : capture au minimum nécessaire, accord avec l’autre partie, et une durée de conservation et une suppression.

10. Résumé

• Un « tout le PC est lent » que le Gestionnaire des tâches ne peut pas expliquer s’investigue avec une trace ETW à l’échelle de l’OS — capturer avec WPR, lire avec WPA. wpr.exe est livré avec Windows 8.1 et versions ultérieures, donc une scission de capturer dans l’environnement client, ramener l’ETL, et le lire dans WPA sur votre propre machine tient.
• La capture est les trois étapes wpr -start GeneralProfile -filemode → reproduire → wpr -stop trace.etl. Si vous pouvez reproduire, mode File dans quelques minutes ; si vous attendez, mode Memory (tampon circulaire). Plus long n’est pas mieux.
• WPA peut se démarrer une fois que vous avez intégré trois points : la règle d’or des tableaux (à gauche de la barre or = groupement), le zoom de la plage de temps, et la configuration des symboles (votre propre application a besoin de PDB).
• Si le CPU est élevé, suivez processus → pile → fonction dans CPU Usage (Sampled). Si le CPU est bas et que c’est encore lent, suivez la chaîne NewThreadStack (ce qu’il faisait lorsqu’il s’est arrêté) → Waits (combien de temps il a attendu) → ReadyingProcess et ReadyThreadStack (qui l’a réveillé) jusqu’à la racine dans CPU Usage (Precise).
• Pour le disque, voyez « le temps passé dans la file » à partir de la différence entre Disk Usage IO Time et Service Time, et identifiez la cause (si le périphérique lui-même est lent, ou qui a fait la file) à partir de Service Time et de la décomposition par processus, chemin et pile. Un démarrage lent peut se capturer avec wpr -boottrace.
• Le motif de travail est (1) épingler l’heure (2) zoomer sur l’intervalle (3) classer CPU, attente ou E/S (4) répéter hypothèse → zoom → pile. Traitez un ETL comme confidentiel parce qu’il contient des informations internes.

L’écran de WPA intimide, et tout le monde se perd dans la première heure. Une fois les deux colonnes vertébrales — « à gauche de la barre or est le groupement » et « Sampled est où ça a brûlé, Precise est pour qui ça a attendu » — sont en place, toutefois, le reste est la même opération répétée. La prochaine fois qu’une consultation arrive que « le CPU a de la marge et c’est encore lent », fermez le Gestionnaire des tâches et capturez une trace.

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 l’investigation des problèmes de performance à l’échelle du système tels que « tout le PC est devenu lent et je ne sais pas pourquoi », « le CPU a de la marge et l’application est encore lente », et « seul un environnement spécifique est extrêmement lent à démarrer ». Nous prenons en charge comme un engagement continu la conception de capture avec WPR/WPA (dans quel environnement, quel profil, combien capturer), l’analyse de trace, et la correction résultante côté application et côté paramètres.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Nous contacter

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 ? Puis-je les utiliser dans un environnement client où je ne peux pas installer de logiciel ?

L'outil de capture wpr.exe (édition en ligne de commande) est livré avec Windows 8.1 et versions ultérieures, donc vous pouvez l'utiliser 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 nécessitent 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ù vous ne pouvez pas ajouter de logiciel.

Pourquoi est-ce lent alors que le Gestionnaire des tâches montre du CPU de reste ? Que puis-je voir dans 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 ». La contention de verrous, l'attente de la fin d'une E/S synchrone, et l'attente de la réponse d'un autre processus sont typiques. Le Gestionnaire des tâches ne montre que le résultat, l'utilisation ; CPU Usage (Precise) de WPA montre, à partir d'un enregistrement par commutation de contexte, où le thread a commencé à attendre (NewThreadStack), combien de temps il a attendu (Waits), et qui l'a réveillé (ReadyingProcess, ReadyThreadStack). En suivant la partie qui l'a fait attendre, vous pouvez identifier « le coupable de la lenteur » jusqu'à la fonction.

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

Si vous pouvez reproduire le problème, 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, donc il convient pour attendre un problème dont vous ne connaissez pas le moment. Le mode File, 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, le mode File pour une reproduction courte et fiable.

Comment choisir entre PerfView et 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 l'investigation spécifique aux applications managées telles que le GC, l'allocation et le JIT. WPA convient pour lire le CPU, le disque, les E/S fichiers, l'alimentation et analogues à l'échelle de l'OS à travers des graphiques et des tableaux, et 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é ». Une règle empirique : PerfView pour la lenteur de votre propre application .NET seule, WPR/WPA pour la lenteur de tout le système.

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 enregistrer un grand volume d'événements avec des piles consomme tout de même 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 informations 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.