WPR/WPA in der Praxis — Einstieg in die systemweite Leistungsuntersuchung bei „der ganze PC ist langsam“

„Der ganze PC ist langsam geworden, nachdem wir eine App installiert haben. Im Task-Manager haben CPU und Speicher aber beide Reserve.“ „Nur ein Rechner braucht 3 Minuten zum Start.“ Was solche Beratungen schwierig macht, ist, dass Sie nicht einmal wissen, welchen Prozess Sie ansehen sollen.

Auch wenn App A die langsame ist, kann die Ursache ein Antivirus-Scan sein, starkes Schreiben eines anderen Dienstes oder eine Sperrkette über mehrere Prozesse. Was Sie brauchen, ist die Aktivität des gesamten Betriebssystems auf einer einzigen Zeitachse aufzuzeichnen und zu verfolgen, wo die Zeit geblieben ist.

Die Werkzeuge dafür sind Windows Performance Recorder (WPR) und Windows Performance Analyzer (WPA). WPR erfasst die Aufzeichnung mit ETW (Event Tracing for Windows), und WPA liest diese Aufzeichnung in Grafiken und Tabellen. Entlang der Zeitachse prüfen Sie, welche Prozesse und Stacks CPU genutzt haben, worauf jeder Thread gewartet hat und welcher Prozess Datenträger-E/A an welche Datei ausgegeben hat.

Die Frage, die dieser Artikel beantwortet, ist: „Wie zeichnet man systemweite Langsamkeit auf, und welchen der Bereiche CPU, Wartezeit und E/A untersucht man?“ Er richtet sich an IT-Verantwortliche in kleinen und mittleren Unternehmen und an Entwickler von Windows-Apps und führt, gestützt auf Primärquellen Stand August 2026, von der Praxis der Erfassung bis zur Analyse. Lesen Sie ihn mit dem Unterschied zwischen „die CPU ist hoch“ und „die CPU ist niedrig, und es ist trotzdem langsam“ als Leitachse.

Wie sich das von Process Monitor, das Datei- und Registrierungszugriffe untersucht, und von PerfView, das CPU und GC einer .NET-App verfolgt, unterscheidet, ordnet Kapitel 2.

1. Zuerst die Schlussfolgerung

Der Grundablauf ist „mit WPR erfassen → in WPA auf das Problemintervall eingrenzen → CPU, Warten oder E/A trennen“. Auch ein Problem, das ein einzelner Prozess nicht erklärt, lässt sich untersuchen, indem man jeden Prozess und den Kernel auf derselben Zeitachse verfolgt.¹²

Erfassungsort und Leseort trennen

Das Erfassungswerkzeug wpr.exe ist ab Windows 8.1 im Betriebssystem enthalten, eine zusätzliche Installation ist nicht nötig. Die GUI-Ausgabe WPRUI und das Analysewerkzeug WPA gehören zum Windows ADK. Weil Sie die Arbeit so aufteilen können — „in der Kundenumgebung nur mit wpr.exe erfassen; gelesen wird in WPA auf dem eigenen Rechner“ —, können Sie selbst auf einem Server erfassen, auf dem keine Software hinzugefügt werden darf.¹²

Für ein Ereignis, das Sie reproduzieren können, sind die drei Grundschritte mit Administratorrechten wpr -start GeneralProfile -filemode → das Ereignis reproduzieren → wpr -stop C:\temp\trace.etl.³ Legen Sie den Zielordner an, holen Sie die Freigabe für die Erfassung ein und entscheiden Sie, wie die ETL behandelt wird, bevor Sie ausführen. Das Warten auf ein Ereignis und Probleme während des Starts erfordern andere Erfassungsverfahren; siehe Kapitel 3 und Kapitel 8.

Die erste Grafik, die Sie in WPA öffnen

Grenzen Sie zuerst auf das Intervall des Ereignisses ein und wählen Sie dann die Untersuchungsrichtung aus der folgenden Tabelle.⁴⁵

Sampled zeigt die Aufschlüsselung der CPU-Zeit aus Stichproben etwa jede Millisekunde.⁶ Precise verfolgt Wartezeiten aus einer vollständigen Aufzeichnung der Kontextwechsel. Die Partei, die eine Wartezeit aufgehoben hat, anhand von Waits → ReadyingProcess → ReadyThreadStack zu verfolgen, ist die Technik, die dieser Artikel am meisten vermitteln will.⁴⁷

Lesereihenfolge nach Ziel

Wenn Sie für die Erfassung zuständig sind, beginnen Sie mit Kapitel 2 und Kapitel 3; wenn Sie eine bereits erfasste ETL lesen, mit Kapitel 4. Stacks nach Funktionsnamen zu lesen erfordert eine Symbolkonfiguration; für die eigene App fügen Sie den Pfad zu den PDB hinzu.⁸ Untersuchen Sie JIT-Code von .NET, sind CLR-Ereignisse zum Zeitpunkt der Erfassung ebenfalls nötig; prüfen Sie deshalb die Hinweise zu .NET in Kapitel 4 vor der Erfassung.

Den Ablauf der Untersuchung insgesamt und den Umgang mit ETL fasst Kapitel 9 zusammen. Eine ETL enthält interne Informationen wie Prozessnamen und Dateipfade; halten Sie die Erfassung deshalb auf das nötige Minimum und legen Sie die Bedingungen für die Weitergabe außerhalb des Unternehmens im Voraus fest.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (16 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Wo die Werkzeuge sitzen — WPR erfasst, WPA liest

Windows Performance Toolkit (WPT) ist der Satz von Werkzeugen zur Leistungsuntersuchung im Windows ADK (Windows Assessment and Deployment Kit); den Kern bildet das Paar WPR und WPA.² Die Rollen sind klar getrennt.

WPR erfasst, WPA analysiert

• WPR (Windows Performance Recorder) = Erfassung. Es bündelt ETW-Anbieter in Einheiten namens „Profile“, startet und stoppt die Aufzeichnung und erzeugt eine ETL-Datei. Die Kommandozeilenausgabe wpr.exe ist ab Windows 8.1 im Betriebssystem enthalten, ohne zusätzliche Installation. Die GUI-Ausgabe (WPRUI.exe) gehört zum ADK.¹
• WPA (Windows Performance Analyzer) = Analyse. Es öffnet eine ETL-Datei und analysiert sie in Grafiken und Tabellen. Die Installation des ADK ist erforderlich.²

Mit anderen Worten: Wenn Sie nur von der Kommandozeile erfassen, müssen Sie in der Kundenumgebung keine zusätzliche Software installieren. Mit dem betriebssystemeigenen wpr.exe erfassen, die ETL-Datei mitnehmen und sie in WPA auf dem eigenen PC lesen — dieselbe Aufteilung wie „mit pktmon erfassen, in Wireshark lesen“ bei der Paketmitschnitt.

flowchart LR
    accTitle: Die Aufteilung von Erfassen mit WPR und Lesen mit WPA
    accDescr: In der Kundenumgebung mit dem betriebssystemeigenen wpr.exe aufzeichnen und eine ETL-Datei erzeugen, mitnehmen und in WPA analysieren, das über das ADK auf dem eigenen PC installiert ist
    subgraph customer["Kundenumgebung (keine zusätzliche Installation)"]
        wpr["wpr -start → das Ereignis reproduzieren → wpr -stop"] --> etl["ETL-Datei"]
    end
    subgraph office["Eigener PC (WPA über das ADK installiert)"]
        wpa["Analyse in Grafiken und Tabellen in WPA"]
    end
    etl -->|"Mitnehmen"| wpa

Die Wahl zwischen Procmon, PerfView und WPR/WPA

Ordnen wir zuerst auch ein, wie sich das von ähnlichen Werkzeugen unterscheidet.

Ist Procmon das Operationsprotokoll von „was es getan hat“ und PerfView „was innerhalb von .NET geschehen ist“, dann ist WPA das Werkzeug, das über alle Prozesse hinweg bilanziert, „wo die Zeit geblieben ist“.

Wenn Sie die Ereignisse der eigenen App mit aufzeichnen wollen

Wie ETW selbst funktioniert und wie Sie die eigene App mit ETW instrumentieren, behandelt „Einführung in Windows-Ereignisprotokoll und ETW“. Gibt Ihre App ETW-Ereignisse aus, werden ihre Marken in derselben Ablaufverfolgung aufgezeichnet, und der Abgleich wird deutlich leichter.

Beachten Sie jedoch: WPR zeichnet nur die Ereignisse der Anbieter auf, die das gewählte Aufzeichnungsprofil aktiviert. GeneralProfile enthält Ihren eigenen Anbieter nicht. Um sie gemeinsam aufzuzeichnen, bereiten Sie ein eigenes Aufzeichnungsprofil (.wprp) vor, das Ihren Anbieter aktiviert, und kombinieren Sie es wie in wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, wobei der Profilname in der .wprp-Datei nach ! steht³.

3. Erfassung in der Praxis (WPR) — start, reproduzieren, stop

Was Sie vor der Ausführung festlegen

In einer Produktionsumgebung nehmen Sie nicht an, dass selbst eine kurze Erfassung bedingungslos sicher ist. ETW ist leichtgewichtig, aber das Aufzeichnen eines großen Volumens von Ereignissen mit Stacks verbraucht eine gewisse Menge CPU und Speicher. Wählen Sie einen Zeitpunkt mit geringem Geschäftseinfluss und führen Sie denselben Freigabeprozess wie bei jeder gewöhnlichen Änderung.

Lässt sich das Ereignis reproduzieren, starten Sie knapp davor, stoppen Sie knapp danach und bleiben Sie bei wenigen Minuten. Legen Sie den Zielordner an und entscheiden Sie im Voraus, wer die ETL erhält, wie lange sie aufbewahrt und wie sie gelöscht wird. Hinweise zum Inhalt stehen in Kapitel 9.

Das Folgende ist ein Beispiel, ein vor Ort reproduzierbares Ereignis im File-Modus zu erfassen. Für ein Ereignis mit unbekanntem Zeitpunkt gehen Sie zum Memory-Modus in Abschnitt 3.1; für Probleme während Start oder Anmeldung zu Kapitel 8.

Eine normale Erfassung ist „start → reproduzieren → stop“

Führen Sie dies in einer Eingabeaufforderung aus, die als Administrator geöffnet wurde. -profiles listet die verfügbaren Profile vorab, -status prüft den Zustand während der Erfassung. Das -cancel am Ende dient nur dazu, unterwegs abzubrechen und zu verwerfen; es gehört nicht zum normalen Speichern.

:: Liste der integrierten Profile, die Sie nutzen können
wpr -profiles

:: 1. Erfassung starten (Allzweckprofil, Dateimodus)
wpr -start GeneralProfile -filemode

:: 2. Das Ereignis reproduzieren (Zustand der Erfassung mit wpr -status prüfen)

:: 3. Stoppen und speichern (Sie können eine Beschreibung des Problems anhängen).
::    Den Zielordner vorher anlegen (ohne ihn schlägt -stop beim Speichern fehl)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduziert: der ganze PC wird langsam, während App X startet"

:: Zum Abbrechen unterwegs ohne Speichern verwerfen
wpr -cancel

Was aufgezeichnet wird, wählen Sie mit einem Profil

Was Sie an -start übergeben, ist ein Profil, ein Bündel der ETW-Anbieter, die die Untersuchung braucht.³ Die häufig genutzten zu kennen reicht.⁹

Sie können mehrere Profile gleichzeitig angeben, indem Sie -start wiederholen (zum Beispiel wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: Ablauf der WPR-Erfassung und Wahl des Modus
    accDescr: Ein lokal reproduzierbares Ereignis erfasst man kurz und zuverlässig im Dateimodus; ein Ereignis mit unbekanntem Zeitpunkt wartet man im Standard-Ringpuffer des Speichermodus ab. Ein Ereignis während Start oder Anmeldung nutzt eine Boot-Ablaufverfolgung. In jedem Fall ist die Folge Start, reproduzieren, stoppen dieselbe
    q{"Wann tritt das Ereignis auf?"}
    q -->|"Lokal reproduzierbar"| file["Kurz und zuverlässig mit -filemode erfassen"]
    q -->|"Zeitpunkt unbekannt"| mem["Im Memory-Modus (Standard, Ringpuffer) warten (Abschnitt 3.1)"]
    q -->|"Während Start oder Anmeldung"| boot["Boot-Ablaufverfolgung (Kapitel 8)"]
    file --> s1["wpr -start → das Ereignis reproduzieren oder abwarten → wpr -stop"]
    mem --> s1

3.1. Memory-Modus und File-Modus — können Sie reproduzieren, oder warten Sie?

WPR hat zwei Zielmodi für die Aufzeichnung; der Standard ist der Memory-Modus (zirkulärer Puffer im Speicher).

Den Memory-Modus nutzen Sie, um auf das Eintreten eines Ereignisses zu warten. Weil es ein Ringpuffer ist, der die ältesten Ereignisse zuerst überschreibt, eignet er sich die Erfassung laufen zu lassen, während Sie auf ein Ereignis mit unbekanntem Zeitpunkt warten, und zu stoppen, sobald es eintritt.

Den File-Modus nutzen Sie für Ereignisse, die Sie in kurzer Zeit zuverlässig reproduzieren können. -filemode schaltet auf den File-Modus, und alles wird in einer durchgehenden Datei aufgezeichnet. Nichts geht durch Überschreiben verloren, aber im Gegenzug ist die einzige Obergrenze der freie Datenträgerplatz, und die Datei wächst ohne Grenze.¹⁰

flowchart LR
    accTitle: Wie Memory-Modus und File-Modus aufzeichnen
    accDescr: Der Memory-Modus schreibt in einen zirkulären Puffer im Speicher, in dem die ältesten Ereignisse überschrieben werden und nur die jüngsten bleiben, und eignet sich daher zum Warten. Der File-Modus behält alles in einer Datei, aber die einzige Obergrenze ist der freie Datenträgerplatz, daher eignet er sich für eine kurze, zuverlässige Reproduktion
    ev["Strom der ETW-Ereignisse"] --> ring["Memory-Modus: zirkulärer Puffer (älteste zuerst überschrieben → nur die jüngsten bleiben)"]
    ev --> filem["File-Modus: alles bleibt in einer Datei (Obergrenze ist freier Datenträgerplatz)"]
    ring -.-> use1["Eignet sich zum Warten auf ein Ereignis mit unbekanntem Zeitpunkt"]
    filem -.-> use2["Eignet sich für ein Ereignis, das Sie in kurzer Zeit zuverlässig reproduzieren können"]

Die Faustregel für die Wahl ist wie folgt.

• Vor Ort reproduzierbar → File-Modus. Knapp vor der Reproduktion starten, knapp danach stoppen und die Erfassung bei wenigen Minuten halten
• Zeitpunkt unbekannt → Im Memory-Modus (dem Standard) warten. Sobald es eintritt, wpr -stop ausführen
• Schon wenige Minuten GeneralProfile können eine ETL im Bereich von Hunderten MB bis GB erzeugen. Eine zu große Datei kann in WPA nicht mehr analysierbar sein, deshalb ist „je länger die Erfassung, desto besser“ kontraproduktiv¹⁰¹¹

Erfassen über die GUI

Zum Erfassen über die GUI starten Sie WPRUI, wählen Profil und Logging mode und klicken auf Start und anschließend auf Save. Die Einzelheiten des Verfahrens stehen in den offiziellen How-to-Themen.¹¹ Wenn Sie eine Ansprechperson beim Kunden um die Erfassung bitten, können Sie auch eine Verfahrensanweisung schreiben, die die Schritte Start, reproduzieren und stoppen in den Mittelpunkt stellt und Voraussetzungen sowie den Abbruch getrennt aufführt.

4. Die Grundlagen des Lesens von WPA — Grafiken, die goldene Regel der Tabellen und das Eingrenzen des Zeitbereichs

Öffnen Sie die erfasste ETL in WPA, listet der Graph Explorer links Miniaturansichten der Grafiken in Kategorien wie System Activity, Computation, Storage und Memory.¹² Ziehen Sie die gewünschte Grafik auf die Registerkarte Analysis rechts, und oben erscheint die Grafik, darunter eine Tabelle.

Die drei Dinge, die Sie beherrschen, sind Spaltenreihenfolge, Eingrenzen des Zeitbereichs und Symbolkonfiguration. Statt die Bedienung für jede Grafik neu zu lernen, beginnen Sie mit dieser gemeinsamen Leseweise.

4.1. Die Spaltenreihenfolge entscheidet, wie aggregiert wird

Eine WPA-Tabelle hat zwei senkrechte Leisten, eine goldene und eine blaue: die Spalten links der goldenen Leiste hierarchisieren (gruppieren) die Daten in dieser Reihenfolge, und die Spalten rechts der blauen Leiste sind aggregierte Werte.¹³

Die Reihenfolge „Process → Stack“ ergibt eine Stack-Aggregation pro Prozess; „Stack → Process“ eine Aggregation über jeden Prozess, der denselben Stack nutzt. Spalten per Ziehen umzuordnen ist selbst der Analyseschritt. Verstehen Sie diesen einen Punkt, liest sich jede WPA-Tabelle auf dieselbe Weise.

flowchart LR
    accTitle: Die goldene Regel der Tabellen — die zwei Leisten und die Rollen der Spalten
    accDescr: Die Reihenfolge der Spalten links der goldenen Leiste hierarchisiert die Daten, die Spalten zwischen goldener und blauer Leiste sind Anzeigespalten, und die Spalten rechts der blauen Leiste sind aggregierte Werte. Spalten per Ziehen umzuordnen ist selbst der Analyseschritt
    left["Links der goldenen Leiste: Gruppierungsspalten (Reihenfolge = Hierarchie)"] --> gold["Goldene Leiste"]
    gold --> mid["Zwischen den Leisten: Anzeigespalten"]
    mid --> blue["Blaue Leiste"]
    blue --> right["Rechts der blauen Leiste: aggregierte Werte (Sum, % und so weiter)"]
    left -.-> op["Eine Spalte ziehen = ein Analyseschritt (Process → Stack ergibt eine Stack-Aggregation pro Prozess)"]

4.2. Auf das Intervall eingrenzen, in dem das Ereignis auftrat

Ziehen Sie auf der Grafik, um einen Bereich auszuwählen, und wählen Sie im Kontextmenü „Zoom“; die Aggregation wechselt auf nur dieses Intervall. Der Grundsatz der Leistungsuntersuchung ist, immer nur „das Intervall, in dem das Ereignis auftrat“ anzusehen (Kapitel 9).

4.3. Symbole laden und Stacks nach Funktionsnamen ansehen

Um Stacks nach Funktionsnamen zu lesen, führen Sie im Menü Trace > Load Symbols aus.¹⁴ Standardmäßig wird Microsofts öffentlicher Symbolserver (msdl.microsoft.com) verwendet; Stacks in Windows selbst lassen sich deshalb auflösen, solange eine Internetverbindung besteht.

Um auch Funktionsnamen in der eigenen App zu sehen, fügen Sie unter Trace > Configure Symbol Paths den Ordner mit den PDB der App hinzu.⁸ Was eine PDB ist und warum Sie sie auch für Release-Builds immer aufbewahren sollten, fasst „Was ist eine PDB (Program Database)?“ zusammen.

Bei .NET NGen-Abbilder und JIT-Code getrennt behandeln

Für native NGen-Abbilder von .NET Framework erzeugt WPR bei der Erfassung NGen-PDB (.ngenpdb), legt sie in einem Ordner neben der Ablaufverfolgung ab, und WPA greift automatisch darauf zu.⁸ Dieser Mechanismus gilt nur für NGen-Abbilder; eigener Code in einer gewöhnlichen .NET-App, die unter dem JIT läuft, ist nicht abgedeckt.

Die Zuordnung von Adressen in JIT-Code zu Funktionsnamen wird aus den JIT-Ereignissen aufgelöst, die die CLR ausgibt. Wenn Sie eine .NET-App untersuchen, bereiten Sie deshalb ein Aufzeichnungsprofil (.wprp) vor, das die CLR-Anbieter aktiviert (Microsoft-Windows-DotNETRuntime und das zugehörige Rundown), und kombinieren Sie es in der Form wpr -start GeneralProfile -start MyDotNet.wprp!ProfileName, analog zum eigenen Anbieter in Kapitel 2, sodass die CLR-Ereignisse in der Ablaufverfolgung enthalten sind (welche integrierten Profile Ihr lokales WPR anbietet, prüfen Sie mit wpr -profiles).

Bewahren Sie darüber hinaus die vom Build erzeugten PDB für die Zuordnung zu Quellzeilen auf und fügen Sie sie dem oben beschriebenen Symbolpfad hinzu.

flowchart TB
    accTitle: Symbolauflösung, um Stacks nach Funktionsnamen zu lesen
    accDescr: Führen Sie Trace Load Symbols aus, löst Windows selbst über Microsofts öffentlichen Symbolserver auf und die eigene App über die Build-PDB, die dem Symbolpfad hinzugefügt wurden. NGen-Abbilder lösen über die von WPR erzeugten NGen-PDB auf, JIT-.NET-Code über die CLR-JIT-Ereignisse in der Ablaufverfolgung plus die Build-PDB
    load["Trace > Load Symbols"] --> ms["Windows selbst: öffentlicher Symbolserver (msdl)"]
    load --> own["Eigene App: Build-PDB, hinzugefügt unter Configure Symbol Paths"]
    load --> ngen["NGen-Abbilder von .NET Framework: von WPR erzeugte .ngenpdb"]
    load --> jit["JIT-.NET-Code: CLR-JIT-Ereignisse in der Ablaufverfolgung + Build-PDB"]

4.4. Entscheiden, ob CPU, Warten oder E/A untersucht wird

Sind Sie vorbereitet, sehen Sie nach, ob die CPU im Intervall des Ereignisses hoch oder niedrig war. War sie hoch, gehen Sie zu Sampled in Kapitel 5. War sie niedrig, prüfen Sie zuerst, ob ein bestimmter Kern oder Thread fest hängt; wenn nicht, verfolgen Sie die Wartezeiten mit Precise in Kapitel 6. Wird der Datenträger verdächtigt, gehen Sie zu Kapitel 7.

flowchart TB
    accTitle: Eine WPA-Grafik anhand des Symptoms wählen
    accDescr: Zoomen Sie auf das Intervall des Ereignisses; ist die CPU hoch, zu CPU Usage Sampled; ist sie niedrig und es ist trotzdem langsam, einen fest hängenden Kern prüfen und dann Warteanalyse in CPU Usage Precise; wird der Datenträger verdächtigt, zu Disk Usage und File IO
    zoom["Auf das Intervall des Ereignisses zoomen"] --> cpu{"CPU in diesem Intervall?"}
    cpu -->|"Hoch"| sampled["Kapitel 5: CPU Usage (Sampled) für «wer verbraucht in welcher Funktion CPU-Zeit»"]
    cpu -->|"Niedrig, aber langsam"| core{"Ein Kern oder ein Thread fest hängend?"}
    core -->|"Ja"| sampled
    core -->|"Nein"| precise["Kapitel 6: CPU Usage (Precise) für «worauf gewartet wurde»"]
    cpu -->|"Datenträger verdächtigt"| disk["Kapitel 7: Disk Usage / File I/O, um den Schuldigen zu identifizieren"]

5. Wenn die CPU hoch ist — „wer verbraucht in welcher Funktion CPU-Zeit“ mit CPU Usage (Sampled)

Was dieses Kapitel sucht, ist der Aufrufpfad, der einen großen Anteil der CPU-Zeit verbraucht.

Hängt die CPU fest, sehen Sie CPU Usage (Sampled) an. Das sind Stichprobendaten, die etwa jede Millisekunde auf jeder CPU aufzeichnen, „welcher Stack welchen Prozesses gerade läuft“, und das Verhältnis der Stichprobenzahlen ist unmittelbar die Aufschlüsselung der CPU-Zeit.⁶

flowchart LR
    accTitle: Wie CPU Usage Sampled funktioniert
    accDescr: Etwa jede Millisekunde wird der auf jeder CPU laufende Stack aufgezeichnet, und das Verhältnis der aggregierten Stichproben ist die Aufschlüsselung der CPU-Zeit. Lesen Sie von Prozess zu Thread, Stack und Funktion hinab. Kurze Aktivität, die zwischen Stichproben endet, wird nicht erfasst
    tick["Unterbrechung etwa alle 1 ms"] --> snap["Den «gerade laufenden Stack» auf jeder CPU aufzeichnen"]
    snap --> agg["Die Stichproben aggregieren (Verhältnis = Aufschlüsselung der CPU-Zeit)"]
    agg --> drill["Hinabsteigen Process → Thread → Stack → Funktion"]
    snap -.-> miss["Kurze Aktivität, die zwischen Stichproben endet, wird nicht erfasst"]

Von Prozess zu Stack zu Funktion hinabsteigen

1. Legen Sie aus Computation im Graph Explorer CPU Usage (Sampled) auf die Registerkarte Analysis und wählen Sie die Vorgabe Utilization by Process, Stack.⁵
2. Sehen Sie die Prozesse in absteigender Reihenfolge von Weight (oder Count) an. Was im Task-Manager „50 %“ war, wird zuerst auf Prozessebene identifiziert.
3. Klappen Sie die Spalte Stack des schuldigen Prozesses auf. Stacks sind als Baum aggregiert, und entlang des Pfads hinabzusteigen, an dem die Zahlen an jeder Verzweigung nicht stark fallen, führt Sie zu der Funktion, die CPU-Zeit verbraucht. Sind die Symbole aufgelöst, ist es ein gerader Weg zur konkreten Funktion im eigenen Code.
4. Ist das Aufklappen des Baums mühsam, schalten Sie die Grafikanzeige auf Flame (Flammendiagramm). Die Breite wird als Anteil der CPU-Zeit gezeichnet, sodass auf einen Blick klar ist, welcher Aufrufpfad dominiert. CPU Usage (Sampled) bringt auch eine Vorgabe Flame by Process, Stack mit.¹³

Sampled kann die genaue Dauer eines einzelnen Durchlaufs nicht messen

Weil es Stichproben sind, wird kurze Aktivität, die zwischen Stichproben endet, nicht erfasst.⁶ Merken Sie sich, dass es ein Werkzeug ist, um zu sehen, „wo CPU-Zeit in der Summe verbraucht wurde“, kein Werkzeug, um die genaue Ausführungszeit jedes einzelnen Durchlaufs zu messen.

6. Wenn die CPU niedrig ist und es trotzdem langsam ist — CPU Usage (Precise) und Warteanalyse

6.1. Vor der Warteanalyse einen einzelnen fest hängenden Kern prüfen

„Die CPU-Auslastung insgesamt ist niedrig“ bedeutet nicht „die CPU ist nicht der Engpass“. Auf einem 16-Kern-PC erscheint serielle Arbeit, die an einem Kern fest hängt (ein einzelner UI-Thread, der mit voller Kraft läuft), insgesamt nur als etwa 6 %.

Prüfen Sie zuerst mit Sampled aus Kapitel 5 oder mit Utilization by CPU in CPU Usage (Precise), ob ein bestimmter Kern oder Thread fest hängt. Hängt auch nichts fest, gehen Sie davon aus, dass die Arbeit die CPU nicht nicht nutzen kann, sondern auf etwas wartet, und fahren Sie mit der Warteanalyse fort. Ab hier ist das Werkzeug CPU Usage (Precise).

6.2. „Zeit im Warten“ von „Warten auf eine CPU nach dem Aufwecken“ trennen

Wo Sampled Stichproben sind, ist Precise eine vollständige Aufzeichnung der Kontextwechsel (Threadwechsel). Ein Thread tritt in eine Wartezeit ein, wird von jemandem aufgeweckt (Ready) und kommt auf eine CPU — jede solche Hin- und Rückfahrt bleibt als eine Zeile, und Sie können die folgenden Spalten lesen.⁷⁴

flowchart LR
    accTitle: Eine Hin- und Rückfahrt des Wartens und die zugehörigen Spalten
    accDescr: Ein Thread tritt auf dem in NewThreadStack festgehaltenen Stack in eine Wartezeit ein und wartet die Waits-Zeit. Weckt ihn jemand auf, bleibt diese Partei in ReadyingProcess und ReadyThreadStack, und der Thread wartet die Ready-Zeit auf die Konkurrenz um die CPU, bevor er wieder läuft
    run1["Laufend"] -->|"Tritt in eine Wartezeit ein (in NewThreadStack festgehalten)"| waitst["Warten (Waits (us))"]
    waitst -->|"Jemand weckt ihn auf (ReadyingProcess / ReadyThreadStack)"| ready["Ready (Warten auf die Konkurrenz um die CPU)"]
    ready -->|"Kommt auf eine CPU"| run2["Wieder laufend"]

6.3. Vom verzögerten Thread nacheinander jeden Aufwecker verfolgen

Die Lesereihenfolge ist wie folgt.⁴

1. Grafik und Spalten vorbereiten

Wenden Sie die Vorgabe Utilization by Process, Thread an und fügen Sie NewThreadStack und ReadyThreadStack zu den Spalten hinzu.

2. Den Thread der verzögerten Operation auswählen

Identifizieren Sie zuerst den Thread, der die verzögerte Operation ausgeführt hat, etwa den UI-Thread oder den Thread, der die betreffende Anforderung bearbeitet. Sehen Sie nur in absteigender Reihenfolge der gesamten Waits, stehen gesunde Threads, die absichtlich warten, etwa eine Nachrichtenpumpe oder ein Timer, oben.

Ist die CPU Usage (ms) des Zielthreads groß, ist es ein CPU-Problem aus Kapitel 5; dominieren die Waits, ein Warteproblem.

3. In NewThreadStack sehen, „was es tat, als es anhielt“

Klappen Sie NewThreadStack auf. WaitForSingleObject oder EnterCriticalSection bedeutet Warten auf eine Sperre; innerhalb synchroner E/A wie ReadFile Warten auf E/A; innerhalb eines Socket-Empfangs Warten auf die Antwort der Gegenstelle.

4. In ReadyThreadStack sehen, „wer die Wartezeit aufgehoben hat“

Klappen Sie ReadyThreadStack auf und prüfen Sie ReadyingProcess / ReadyingThreadId. Wurde er aus dem KiTimerExpiration des Kernels aufgeweckt, war es ein Timer (er schlief bis zum Timeout); wurde er aus der E/A-Abschlussverarbeitung aufgeweckt, bestätigt das ein E/A-Warten.⁴

5. Dieselbe Untersuchung am Aufwecker wiederholen

Ist der Aufwecker ein anderer Thread oder ein anderer Prozess, untersuchen Sie als Nächstes diesen Thread mit demselben Verfahren.

Zum Beispiel eine Kette wie A wartete darauf, dass B eine Sperre freigibt, B wartete auf eine RPC-Antwort von C, und C wartete auf Datenträger-E/A. Diese Kette bis zur Wurzel zu verfolgen ergibt den kritischen Pfad der Verzögerung.⁷

flowchart LR
    accTitle: Die Kette des kritischen Pfads, die die Warteanalyse verfolgt
    accDescr: Sehen Sie in NewThreadStack des verzögerten Threads A, was er tat, als er anhielt, identifizieren Sie den Aufwecker B aus ReadyThreadStack und ReadyingProcess, untersuchen Sie B mit demselben Verfahren und verfolgen Sie bis zur Datenträger-E/A an der Wurzel
    a["Thread A (die verzögerte Operation)"] -->|"NewThreadStack: in einem Sperrwarten angehalten"| b["Thread B (hält die Sperre)"]
    b -->|"NewThreadStack: Warten auf eine RPC-Antwort"| c["Prozess C"]
    c -->|"NewThreadStack: Warten auf synchrone E/A"| d["Datenträger-E/A (die Wurzel)"]
    d -.->|"Abschluss weckt C"| c
    c -.->|"Die Antwort weckt B"| b
    b -.->|"Freigabe der Sperre weckt A (erscheint in ReadyThreadStack)"| a

Die Ursache des Wartens in eine Entwurfsprüfung überführen

In einem Vorhaben, in dem „wir es multithreaded gemacht haben, aber es nicht schneller wurde“, zeigt dieses Verfahren zum Beispiel alle Worker hinter einer einzigen Sperre aufgereiht, genau so, wie es ist. Sperrkonkurrenz durch Entwurf zu vermeiden, behandelt „Praktische Best Practices für Multithreading: .NET-Edition“, und den Windows-Mechanismus, der auf Abschlussbenachrichtigungen läuft statt in synchroner E/A zu warten, „I/O-Completion-Ports (IOCP) und der .NET-Thread-Pool“. In WPA festzunageln, „auf wen gewartet wurde“, und es dann mit diesen Entwurfsgrundsätzen zu beheben, ist ein durchgehender Ablauf.

7. Datenträger und Datei-E/A — „jemand scannt den Datenträger“ identifizieren

Der klassische Schuldige hinter „der ganze PC ist langsam“ ist nicht die CPU, sondern der Datenträger. Untersuchen Sie mit Disk Usage und File I/O in der Kategorie Storage.¹⁵

7.1. In Disk Usage „Verarbeitung des Geräts“ von „Warten in der Warteschlange“ trennen

Disk Usage ist die Aufzeichnung der Datenträger-E/A. Beginnen Sie damit, die folgenden zwei Spalten zu unterscheiden.⁶

IO Time ist immer mindestens so groß wie Service Time; die Differenz ist die Zeit in der Warteschlange. Ist IO Time deutlich länger als Service Time, hat diese E/A in der Warteschlange gewartet.⁶

Schließen Sie die Ursache jedoch nicht allein aus der Zeitdifferenz. Ob ein anderer Prozess die Warteschlange aufgebaut hat oder die eigene starke E/A des Prozesses sich auf einem langsamen Gerät gereiht hat, ist noch nicht entschieden. Sehen Sie die Antwort des Geräts selbst in Service Time an und klären Sie es dann mit der Aufschlüsselung nach Prozess, Pfad und Stack.

7.2. Welcher Prozess hat E/A an welche Datei ausgegeben

Mit der Vorgabe Utilization by Process, Path Name, Stack sehen Sie deshalb an, welcher Prozess von welchem Stack E/A an welche Datei ausgegeben hat, in absteigender Reihenfolge von IO Time oder Size.¹⁵ Die zwei Antworten, die im Feld am häufigsten kommen, sind diese.

• Antivirensoftware hat jede Datei gescannt. Es erscheint als der Antivirusprozess, der im Intervall, in dem die App langsam startete, ein großes Volumen von Lesevorgängen ausgibt. Prozessname, Pfad und Menge sind Belege, die sich in einem Gespräch über Ausschlusseinstellungen direkt verwenden lassen.
• Ein anderer Prozess hat stark geschrieben. Sicherung, ein Indexer, übermäßiges Protokollieren und Ähnliches. Wann ein Schreibvorgang den Datenträger erreicht, hängt mit dem Cache-Manager zusammen; dass „der Moment des Schreibens“ und „der Moment, in dem der Datenträger beschäftigt ist“ auseinanderlaufen können, erklärt auch „Cache-Manager — Wann erreicht Ihr WriteFile tatsächlich die Festplatte?“.

7.3. Langsamkeit vor dem Datenträger mit File I/O sehen

File I/O liegt eine Schicht höher: die Aufzeichnung der Dateioperationen, die die App ausgegeben hat (Create, Read, Write und so weiter), und Vorgaben wie Duration by Process, Thread, Type aggregieren die Zeit je Dateiname und je Operation.¹⁵

Ein Fall, in dem Zeit im Dateisystem oder in einem Filtertreiber verbraucht wird, bevor der Datenträger erreicht wird, erscheint in Disk Usage nicht; die Abweichung selbst, „Disk Usage ist ruhig, File I/O aber langsam“, ist ein Hinweis. Wenn Sie bei der Funktionsweise von synchroner und asynchroner E/A beginnen wollen, siehe „Synchrones und asynchrones I/O — Was OVERLAPPED wirklich bedeutet“.

flowchart TB
    accTitle: Die unterschiedlichen Schichten, die File IO und Disk Usage sehen
    accDescr: Eine Dateioperation der App geht durch Dateisystem und Filtertreiber und erreicht das Datenträgergerät aus der E/A-Warteschlange des Betriebssystems. File IO zeichnet die Operationen der oberen Schicht auf, Disk Usage die E/A, die den Datenträger erreicht hat, und die Differenz zwischen IO Time und Disk Service Time zeigt die Zeit in der Warteschlange
    app["App: ReadFile / WriteFile"] --> fio["Dateisystem und Filtertreiber (die Schicht, die File I/O sieht)"]
    fio --> queue["E/A-Warteschlange des Betriebssystems"]
    queue --> dev["Datenträgergerät (die Schicht, die Disk Usage sieht)"]
    fio -.-> n1["Hier verbrauchte Zeit erscheint in Disk Usage nicht"]
    queue -.-> n2["IO Time − Disk Service Time = Zeit in der Warteschlange"]
    dev -.-> n3["Disk Service Time = Verarbeitungszeit des Geräts"]

7.4. Wenn Sie Speichermangel verdächtigen, prüfen Sie auch den physischen Speicher

Die Überlegung „vielleicht ist zu wenig Speicher da und es wird ausgelagert“ lässt sich vor dem Gang zu WPA im Task-Manager und im Ressourcenmonitor einer ersten Eingrenzung unterziehen.

Schließen Sie Speichermangel nicht allein anhand des committeten Speichers aus. Auch bei Reserve im Commit kann Druck auf den physischen Speicher Working Sets kürzen und Hard Faults in Gang halten. Prüfen Sie auch den verfügbaren physischen Speicher und „Hartfehler/s“ im Ressourcenmonitor. Zur Leseweise siehe den Artikel Was bedeutet Windows’ „Speicherauslastung“ eigentlich?.

8. Langsamer Start und langsame Anmeldung — der Einstieg in die Boot-Ablaufverfolgung

Beim Typ „der Start dauert 3 Minuten“ ist das Problem vorbei, bevor Sie wpr -start von Hand ausführen können. WPR hat eine Boot-Ablaufverfolgung, die Sie so einrichten, dass das Betriebssystem beim nächsten Start automatisch mit der Aufzeichnung beginnt.³

Die Aufzeichnung für den nächsten Start einrichten, nach dem Neustart speichern

Wie in Kapitel 3 legen Sie Freigabe der Erfassung und Umgang mit der ETL fest und arbeiten dann in einer als Administrator geöffneten Eingabeaufforderung.

:: 1. Automatische Aufzeichnung beim nächsten Start einrichten
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Neu starten (den langsamen Start reproduzieren)

:: 3. Nach dem Start die Aufzeichnung stoppen und speichern (hebt auch die Einrichtung auf)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Start dauert 3 Minuten"

flowchart LR
    accTitle: Ablauf der Boot-Ablaufverfolgung
    accDescr: Richten Sie mit addboot die automatische Aufzeichnung beim nächsten Start ein und starten Sie neu; das Betriebssystem beginnt beim Start automatisch zu zeichnen. Speichern mit stopboot nach der Anmeldung hebt auch die Einrichtung auf. Zum Aufgeben mit cancelboot aufheben
    add["Mit wpr -boottrace -addboot einrichten"] --> rebootpc["Neu starten (den langsamen Start reproduzieren)"]
    rebootpc --> auto["Das Betriebssystem beginnt beim Start automatisch zu zeichnen"]
    auto --> stop2["Nach der Anmeldung mit -stopboot speichern (hebt auch die Einrichtung auf)"]
    add -.-> cancel["Zum Aufgeben -cancelboot"]

Nach der Erfassung dieselbe Trennung „CPU, Warten oder E/A“

Die Messung von Start und Herunterfahren, die früher xbootmgr übernahm, lässt sich im heutigen WPR auch mit Optionen wie -onoffscenario Boot ausführen.³

Die erfasste Ablaufverfolgung liest man mit demselben Werkzeugsatz wie in den vorherigen Kapiteln. Sehen Sie in der Grafik Processes in zeitlicher Reihenfolge, welcher Prozess wann entstanden ist; zoomen Sie auf das Intervall, in dem der Start hängt; und ordnen Sie es als CPU, Warten oder Datenträger ein. Muster wie Start-Apps, die der Reihe nach auf etwas warten, oder ein Dienststart, der an einer bestimmten E/A steht, werden sichtbar.

Die Boot-Analyse ist ein eigenes tiefes Fachgebiet; dieser Artikel geht nur bis zum Einstieg: „ein Ereignis, das Sie von Hand nicht erwischen, lässt sich mit WPR trotzdem erfassen.“ Beginnen Sie damit, sich mit einer Boot-Ablaufverfolgung von GeneralProfile ein Gesamtbild zu verschaffen.

9. Das Arbeitsmuster — klassifizieren, zoomen, Stack, wiederholen

Da die Werkzeuge klar sind, hier das Muster für die Untersuchung insgesamt. Die Reihenfolge die Zeit festnageln und das Intervall eingrenzen, klassifizieren, dann den Stack verfolgen gilt für jedes Symptom.

Von der Festlegung der Zeit bis zur Prüfung der Hypothese

1. Nageln Sie die Zeit des Phänomens fest. Nicht „es war langsam“, sondern „es war langsam von 10:23:40 bis 10:24:10“. App-Protokolle, das Ereignisprotokoll, eine Notiz der Person, die bedient hat — alles ist recht. Schreibt die eigene App Marken in ETW oder das Ereignisprotokoll, dienen die Ereignisse in der Ablaufverfolgung unmittelbar als Zeitpflöcke.
2. Zoomen Sie nur auf dieses Intervall. Eine Aggregation über die gesamte Ablaufverfolgung wird zu Mittelwerten geglättet, und die Anomalie, auf die es ankommt, verdünnt sich. Die Analyse in WPA ist immer ein Vergleich von „dem Intervall, das abweichend war“ gegen „das Intervall, das normal war“.
3. Klassifizieren Sie zuerst „CPU, Warten oder E/A“. Sehen Sie CPU Usage (Sampled) an; brennt es, gehen Sie zu Kapitel 5. Brennt es nicht, zu Waits in CPU Usage (Precise) (Kapitel 6). Ist IO Time in Disk Usage aufgebläht, zu Kapitel 7. Diese Dreiwege-Gabelung zuerst zu durchlaufen, verhindert, dass Sie sich verirren.
4. Wiederholen Sie Hypothese → Zoom → Stack. Denken Sie „Antivirus?“, grenzen Sie auf diesen Prozess ein und bestätigen Sie es am Stack. Hält es nicht, zur nächsten Hypothese. Keine Schlussfolgerung zu ziehen, bevor Sie zum Stack hinabgestiegen sind und es bestätigt haben, ist die Disziplin dieser Art von Untersuchung.

flowchart LR
    accTitle: Die iterative Schleife einer Leistungsuntersuchung
    accDescr: Nageln Sie die Zeit des Phänomens fest, zoomen Sie auf das Intervall, klassifizieren Sie CPU, Warten oder E/A, bilden Sie eine Hypothese und grenzen Sie ein, und bestätigen Sie am Stack. Hält sie, ist die Ursache bestätigt; hält sie nicht, mit der nächsten Hypothese wiederholen
    time["Die Zeit des Phänomens festnageln"] --> zoomstep["Auf dieses Intervall zoomen"]
    zoomstep --> triage["CPU, Warten oder E/A klassifizieren"]
    triage --> hypo["Eine Hypothese bilden und eingrenzen"]
    hypo --> stack["Am Stack bestätigen"]
    stack -->|"Bestätigt"| fix["Ursache identifiziert → beheben"]
    stack -->|"Hielt nicht"| hypo

Legen Sie den Umgang mit der ETL vor der Erfassung fest

Eine ETL-Datei hält einen weiten Blick ins Innere des Systems fest: die Namen jedes Prozesses, die Pfade geöffneter Dateien, die geladenen Module und (je nach Profil) Namen von Registrierungsschlüsseln.

Eine Standarderfassung mit GeneralProfile enthält keine Datenkörper wie Kommunikationsinhalte, aber wenn Sie einen eigenen Anbieter aktiviert haben, geht die Nutzlast seiner Ereignisse (etwa von der App aufgezeichnete Zeichenfolgen) unverändert hinein.

Prüfen Sie, was die aktivierten Anbieter ausgeben, und behandeln Sie die Datei dann als vertraulich genug, um Sorgfalt zu verlangen, bevor sie das Unternehmen verlässt. Wie beim Paketmitschnitt bauen Sie minimale Erfassung, Einvernehmen mit dem Empfänger sowie Aufbewahrungsfrist und Löschung in das Verfahren ein.

flowchart LR
    accTitle: Was eine ETL-Datei festhält und wie sie zu behandeln ist
    accDescr: Eine ETL hält jeden Prozessnamen, die Pfade geöffneter Dateien, Module und je nach Profil Namen von Registrierungsschlüsseln fest; das Aktivieren eines eigenen Anbieters fügt auch dessen Nutzlast hinzu. Behandeln Sie sie als vertraulich und bauen Sie minimale Erfassung, Einvernehmen mit dem Empfänger sowie Aufbewahrungsfrist und Löschung in das Verfahren ein
    etl["ETL-Datei"] --> a1["Jeder Prozessname, Dateipfade, Module"]
    etl --> a2["(Je nach Profil) Namen von Registrierungsschlüsseln"]
    etl --> a3["Nutzlast eigener Anbieter (von der App aufgezeichnete Zeichenfolgen)"]
    a1 -.-> rule["Als vertraulich behandeln: minimale Erfassung, Einvernehmen mit dem Empfänger, Aufbewahrungsfrist und Löschung"]
    a2 -.-> rule
    a3 -.-> rule

10. Zusammenfassung

Eine Untersuchung mit WPR/WPA lässt sich in die folgenden drei Stufen gliedern.

1. Erfassen Sie das Intervall, das Sie brauchen. Erfassen Sie mit wpr.exe, das ab Windows 8.1 im Betriebssystem enthalten ist, und lesen Sie die ETL in WPA auf dem eigenen Rechner. Die Grundlage ist wpr -start GeneralProfile -filemode → reproduzieren → wpr -stop trace.etl. Lässt es sich reproduzieren, File-Modus innerhalb weniger Minuten; wenn Sie darauf warten, Memory-Modus. Für Langsamkeit während des Starts wpr -boottrace. Länger ist nicht besser, und die internen Informationen in der ETL werden als vertraulich behandelt.
2. Grenzen Sie den Zeitbereich ein und wählen Sie die Untersuchungsrichtung. In WPA ist links der goldenen Leiste die Gruppierung und rechts der blauen Leiste sind aggregierte Werte. Beherrschen Sie Spaltenreihenfolge, Zoomen auf das Intervall und Symbolkonfiguration und trennen Sie dann CPU, Warten oder E/A. Stellen Sie PDB für die eigene App bereit, und prüfen Sie bei JIT-Code von .NET auch die CLR-Ereignisse zum Zeitpunkt der Erfassung.
3. Verfolgen Sie bis zum Stack und prüfen Sie die Hypothese. Ist die CPU hoch, steigen Sie in Sampled von Prozess zu Funktion hinab. Auch wenn die CPU insgesamt niedrig ist, prüfen Sie zuerst, ob ein einzelner Kern oder Thread fest hängt, und wenn nicht, verfolgen Sie die Wartezeiten in Precise. Beim Datenträger entscheiden Sie die Ursache nicht allein aus der Zeitdifferenz; sehen Sie die Antwort des Geräts und die Aufschlüsselung, wer die E/A ausgegeben hat.

Was Sie in der Warteanalyse verfolgen, ist NewThreadStack (was es tat, als es anhielt) → Waits (wie lange es wartete) → ReadyingProcess und ReadyThreadStack (wer es aufweckte). Untersuchen Sie den Aufwecker auf dieselbe Weise, und Sie können die Kette der Verzögerungen bis zur Wurzel verfolgen.

WPA kann Sie anfangs mit der Informationsmenge auf dem Bildschirm überfordern. Halten Sie trotzdem fest: „die Spaltenreihenfolge ist die Art der Aggregation“ und „Sampled ist, wo CPU verbraucht wurde, Precise ist, auf wen gewartet wurde“. Der Rest ist die Wiederholung von Zeit festnageln, zoomen, klassifizieren und den Stack prüfen. Wenn das nächste Mal eine Beratung kommt, „die CPU hat Reserve, und es ist trotzdem langsam“, erfassen Sie eine Ablaufverfolgung in dieser Reihenfolge und lesen Sie sie durch.

Verwandte Artikel

• Mit PerfView und dotnet-trace die Ursache von „langsam“ finden — Praxis-Einstieg in die .NET-Performanceanalyse
• Process Monitor (ProcMon) Praxisleitfaden — „Konfiguration wird nicht gelesen“ und ACCESS DENIED in 10 Minuten identifizieren
• Einführung in Windows-Ereignisprotokoll und ETW ── Protokolle von Geschäftsanwendungen in die Standardmechanismen des Betriebssystems einordnen
• Was bedeutet Windows’ „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen
• Windows-Prozessorzeitplanung – Hintergrunddienste und P-/E-Kerne
• Was ist eine PDB (Program Database)? — Debugging-Informationen, Symbole und Source Link verstehen

Verwandte Beratungsleistungen

Die KomuraSoft LLC untersucht systemweite Leistungsprobleme wie „der ganze PC ist langsam geworden, und wir finden die Ursache nicht“, „die CPU hat Reserve, und die App ist langsam“ und „nur eine bestimmte Umgebung startet extrem langsam“. Wir übernehmen alles als einen durchgehenden Auftrag, vom Entwurf der Erfassung mit WPR/WPA (welche Umgebung, welches Profil und wie viel erfasst wird) über die Analyse der Ablaufverfolgung bis zur Behebung der Ursache auf App- oder Einstellungsseite.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wo bekomme ich WPR und WPA? Kann ich sie in einer Kundenumgebung nutzen, in der nichts installiert werden darf?

Das Erfassungswerkzeug wpr.exe (die Kommandozeilenausgabe) ist ab Windows 8.1 im Betriebssystem enthalten und ohne zusätzliche Installation nutzbar. Die GUI-Ausgabe WPRUI und das Analysewerkzeug WPA (Windows Performance Analyzer) gehören zum Windows ADK (Windows Assessment and Deployment Kit) und erfordern eine separate Installation. In der Praxis reicht die Aufteilung „in der Kundenumgebung nur mit dem betriebssystemeigenen wpr.exe eine ETL-Datei erfassen, mitnehmen und auf dem eigenen Rechner in WPA analysieren“, um auch an einem Standort, an dem keine Software hinzugefügt werden darf, die Leistung des gesamten Systems zu untersuchen.

Warum ist es langsam, obwohl der Task-Manager CPU-Reserve zeigt? Was zeigt WPA?

Wenn die CPU-Auslastung niedrig ist und es trotzdem langsam ist, kann die Arbeit die CPU nicht nicht nutzen; sie steht still, weil sie „auf etwas wartet“. Typisch sind Konkurrenz um eine Sperre, das Warten auf den Abschluss synchroner E/A und das Warten auf die Antwort eines anderen Prozesses. Der Task-Manager zeigt nur das Ergebnis, die Auslastung. CPU Usage (Precise) in WPA zeigt aus der Aufzeichnung jedes Kontextwechsels, wo ein Thread zu warten begann (NewThreadStack), wie lange er wartete (Waits) und wer ihn aufweckte (ReadyingProcess und ReadyThreadStack). Folgt man nacheinander der Partei, die ihn warten ließ, lässt sich der „Schuldige der Langsamkeit“ auf Funktionsebene identifizieren.

Wie lange soll ich eine Ablaufverfolgung erfassen? Wird die Datei nicht riesig?

Lässt sich das Ereignis reproduzieren, ist die Grundregel: knapp vor der Reproduktion starten, knapp danach stoppen und bei wenigen Minuten bleiben. Der Standard von WPR ist der Memory-Modus, der in einen zirkulären Puffer im Speicher schreibt; ältere Ereignisse werden zuerst überschrieben, er eignet sich also zum Warten auf ein Ereignis mit unbekanntem Zeitpunkt. Der File-Modus, eingeschaltet mit -filemode, behält alles in einer durchgehenden Datei, aber die einzige Obergrenze ist der freie Datenträgerplatz, und eine zu große Datei kann in WPA nicht mehr analysierbar sein. Memory-Modus für langes Warten, File-Modus für eine kurze, zuverlässige Reproduktion.

Wann nutze ich PerfView, wann WPA?

Beide Werkzeuge verarbeiten ETW-Traces, aber ihre Stärken unterscheiden sich. PerfView versteht die .NET-Laufzeit tief und ist stark bei Untersuchungen, die verwaltete Apps betreffen, etwa GC, Allokationen und JIT. WPA eignet sich, CPU, Datenträger, Datei-E/A, Energie und mehr des gesamten Betriebssystems über Grafiken und Tabellen zu lesen, und ist die erste Wahl, wenn „nicht eine bestimmte App, sondern der ganze PC langsam ist“, „mehrere Prozesse beteiligt sind“ oder „etwas außerhalb der App (Antivirus, ein Treiber, ein anderer Prozess) verdächtigt wird“. Als Faustregel: Langsamkeit der eigenen .NET-App allein, PerfView; Langsamkeit des gesamten Systems, WPR/WPA.

Ist es in Ordnung, WPR in der Produktionsumgebung eines Kunden auszuführen?

Eine kurze Erfassung ist in der Praxis üblich, aber nicht bedingungslos sicher. ETW ist leichtgewichtig, zeichnet aber ein großes Volumen von Ereignissen mit Stacks auf und verbraucht deshalb eine gewisse Menge CPU und Speicher. Überlegungen wie Start knapp vor dem Reproduktionsschritt und Stopp knapp danach, Halten der Erfassung bei wenigen Minuten und Ausführung zu einem Zeitpunkt mit geringem Geschäftseinfluss gehören in denselben Freigabeprozess wie jede gewöhnliche Änderung. Außerdem enthält eine ETL-Datei interne Systeminformationen wie Prozessnamen, Dateipfade und Angaben zu ausführbaren Dateien; wie sie behandelt wird, wenn sie das Unternehmen verlässt (Minimierung, Aufbewahrungsfrist, Löschung), sollte man deshalb im Voraus festlegen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.