Diese Anleitung richtet sich an erfahrene Windows-Anwender, Systembauer, Gamer und Audio-Professionals. Ziel ist nicht der niedrigste synthetische Spitzenwert, sondern ein stabiler realer Workload ohne Dropouts oder Frametime-Störungen.
Wichtige Daten sichern, Wiederherstellungspunkt erstellen und aktuelle Treiberpakete bereithalten. Keine Windows-Systemdateien löschen. BIOS-, Registry-, Boot- und Interrupt-Einstellungen nur ändern, wenn ein messbarer Zusammenhang besteht und ein dokumentierter Rückweg vorhanden ist.
1. Testmatrix statt Bauchgefühl
Definiere zuerst einen Ablauf, der das Problem zuverlässig auslöst. Ein guter Test dauert nur so lange wie nötig und verändert zwischen zwei Durchläufen genau eine Variable.
Dasselbe Game-Save, Benchmark-Segment oder DAW-Projekt verwenden.
Beispielsweise zehn Minuten plus ein klar markierter Fehlerzeitpunkt.
ASIO-Puffer und 44,1/48/96 kHz im Protokoll festhalten.
FPS-Limit, V-Sync/VRR, Auflösung und Preset nicht verändern.
Notiere Windows-Build, BIOS-Version, Chipsatz-, GPU-, Netzwerk- und Audio-Treiberversion. Für jeden Lauf reichen: Änderung, Messdauer, Symptomzeitpunkt, höchster ISR/DPC, auffälliges Modul und Ergebnis.
2. LatencyMon tiefer auswerten
Führe LatencyMon als Administrator aus und reproduziere die reale Last. Werte nicht nur die grüne oder rote Zusammenfassung aus:
- Main: höchster gemessener Interrupt-to-Process-Wert sowie längste ISR- und DPC-Ausführung.
- Drivers: nach Highest execution und zusätzlich nach Total execution sortieren. Eine seltene lange Spitze und dauerhaft hohe Gesamtzeit sind unterschiedliche Muster.
- Processes: Hard Pagefaults und betroffene Prozesse prüfen. Sampler und grosse Projekte können durch nicht residente Speicherseiten stören.
- CPUs: kontrollieren, ob die Aktivität auf einzelnen logischen Prozessoren konzentriert ist.
Ein Kernelmodul ist zunächst ein Anhaltspunkt. Sammelmodule wie Wdf01000.sys, ndis.sys oder dxgkrnl.sys benötigen eine Geräte- oder Stack-Korrelation.
3. Windows Performance Toolkit installieren
Installiere aus dem aktuellen Windows ADK nur das Windows Performance Toolkit. Es enthält Windows Performance Recorder (WPR) und Windows Performance Analyzer (WPA). WPR zeichnet ETW-Ereignisse auf, WPA stellt sie zeitlich und nach Modulen/Funktionen dar.
Ein Performance-Trace kann Prozessnamen, Pfade, Hardware- und Aktivitätsinformationen enthalten. Nicht ungeprüft öffentlich hochladen. Aufnahmen kurz halten; -filemode kann bei langen Läufen grosse Dateien erzeugen.
4. Reproduzierbaren WPR-Trace aufnehmen
Öffne Terminal oder Eingabeaufforderung als Administrator. Prüfe zuerst, ob das integrierte Profil vorhanden ist:
wpr -profilesIst GeneralProfile aufgeführt, starte die Aufnahme direkt vor dem reproduzierbaren Test:
wpr -start GeneralProfile -filemodeReproduziere den Dropout oder Ruckler möglichst innerhalb von 30 bis 120 Sekunden und merke dir den Zeitpunkt. Stoppe dann die Aufnahme:
wpr -stop "%USERPROFILE%\Desktop\DPC-Latency.etl" "Audio dropout oder Gaming stutter" -compressFalls die Aufnahme abgebrochen werden soll, ohne eine Datei zu speichern:
wpr -cancel5. ETL-Datei in WPA analysieren
Öffne DPC-Latency.etl in WPA und zoome zuerst auf das enge Zeitfenster um den hör- oder sichtbaren Fehler. Füge danach aus Computation die DPC/ISR-Ansicht hinzu.
- DPC/ISR Duration by Module, Function
Nach inklusiver Dauer sortieren. Module und Funktionen mit hoher Einzeldauer sowie hoher Gesamtdauer notieren.
- DPC/ISR Duration by CPU
Prüfen, ob die Spitzen auf dem Prozessor auftreten, auf dem gleichzeitig der Audio- oder Game-Thread beeinträchtigt wird.
- Timeline korrelieren
DPC/ISR-Spitzen mit Audio-Glitches, Dropped Frames oder dem notierten Problemzeitpunkt vergleichen. Aktivität ausserhalb des Fehlerfensters ist kein ausreichender Beweis.
- Stack und Funktion prüfen
Bei geladenen Symbolen Modul, Funktion und Stack untersuchen. Das oberste Windows-Sammelmodul kann auf einen darunterliegenden Hersteller-Treiber oder Gerätepfad führen.
6. Vom Modul zur Hardwareklasse
| ndis.sys / tcpip.sys | Netzwerk | WLAN aus, Ethernet an; dann umgekehrt. VPN-, Filter- und Adaptertreiber getrennt prüfen. Interrupt Moderation nur als dokumentierten A/B-Test ändern. |
| nvlddmkm / amdkmdag / dxgkrnl | Grafik | Treiberstand, Overlays, Capture, HAGS und Multi-Monitor-Setup einzeln vergleichen; Shader-Aufbau ausschliessen. |
| USBXHCI / Wdf01000 | USB & Framework | Gerätebaum nach Controller betrachten, Hubs entfernen, Audio-Interface an anderen Controllerpfad anschliessen und Geräte einzeln abziehen. |
| ACPI.sys | Firmware & Power | Aktuelles BIOS und Chipsatzpaket prüfen. Energieprofil vergleichen; C-States oder ASPM höchstens temporär und einzeln zur Diagnose ändern. |
| storport / stornvme | Storage | NVMe-Firmware, Storage-Treiber, SMART-Zustand, hohe I/O-Last, Indexierung und Sampler-Streaming prüfen. |
| Audio-/Thunderbolt-Treiber | Pro Audio | Hersteller-ASIO, Firmware, Kabel, Port, Sample-Rate und Puffer testen. Interface nicht über einen ungeeigneten Hub betreiben. |
7. Energie- und Power-Requests dokumentieren
Die folgenden Befehle reparieren keine DPC-Latenz, liefern aber einen nachvollziehbaren Ausgangszustand:
powercfg /getactivescheme
powercfg /requests
powercfg /energy /duration 60 /output "%USERPROFILE%\Desktop\BHAZARD-energy-report.html"powercfg /energy sollte laut Microsoft auf einem möglichst inaktiven System laufen. Der Bericht ist deshalb eine Ergänzung zur DPC-Lastmessung, nicht derselbe Test. Für Desktop-Audio oder Gaming kann ein Leistungsmodus als Vergleich sinnvoll sein; auf Mobilgeräten steigen Verbrauch, Temperatur und Lüfterlast.
8. Audio-Workstation: fortgeschrittene Tests
- Buffer-Sweep: 512 → 256 → 128 → 64 Samples bei identischem Projekt. Den kleinsten stabilen Wert dokumentieren.
- Plugin-Isolation: Look-ahead, Oversampling, Linear Phase, Convolution und externe DSP-Routen gruppenweise deaktivieren.
- USB-Topologie: Audio-Interface und schnelle Storage-Geräte auf getrennte Host-Controller legen, sofern die Hardware mehrere Controller besitzt.
- Sampler: RAM-Auslastung und Hard Pagefaults prüfen; Preload und Disk-Streaming passend zur SSD einstellen.
- Recording versus Mixing: Beim Recording kleine Puffer und leichte Signalkette, beim Mixing grössere Puffer und höhere Plugin-Reserve verwenden.
9. Gaming: fortgeschrittene Tests
- Frametime statt Durchschnitts-FPS: 1%-Low-Werte und Frametime-Graph mit dem WPR-Zeitfenster vergleichen.
- Renderlimit: Ein konstantes FPS-Limit kann CPU- und Treiber-Spitzen reduzieren und macht Vergleiche reproduzierbarer.
- Capture und Overlays: Discord, GeForce/AMD-Overlay, Xbox Game Bar, RGB- und Monitoring-Software einzeln testen.
- Netzwerk: Lokalen Offline-Test gegen Online-Match vergleichen. Ping und Paketverlust separat von DPC-Latenz messen.
- Stabilität: XMP/EXPO, Undervolting und GPU-OC testweise auf Standard. Instabilität kann wie ein Treiberproblem wirken.
10. Fix professionell bestätigen
Ein Fix gilt erst als bestätigt, wenn mindestens drei identische Durchläufe ohne das ursprüngliche Symptom abgeschlossen sind und die problematische DPC/ISR-Aktivität im relevanten Zeitfenster deutlich zurückgeht. Danach die Änderung dokumentieren und alle nicht hilfreichen Teständerungen zurücknehmen.
Nur die eine Änderung, die reproduzierbar geholfen hat.
Alle BIOS-, Geräte- und Softwaretests ohne messbaren Nutzen.
ETL, LatencyMon-Screenshots, Treiberversionen und Testmatrix an Hersteller oder Support.
Kein pauschales Abschalten von HPET, Dynamic Tick, CPU-Kernen, C-States, Sicherheitsfunktionen oder der Auslagerungsdatei. Keine ungeprüften MSI-Mode-Tools und keine fremden Registry-Pakete. Diese Eingriffe verschieben häufig nur Messwerte, erschweren Updates oder erzeugen Stabilitäts- und Sicherheitsprobleme.