Scheduler, Timer und Foreground Boost Windows 11 25H2

Kurze Antwort

Diese Werte steuern den Scheduler, die Timer-Auflösung, die Verteilung der Takt-Interrupts und das DPC-Budget. Anhand des Namens allein lässt sich der gesamte Effekt nicht bestimmen: Windows verwendet Bitmasken und normalisiert die Eingabewerte. Verschiedene Einträge können denselben Betriebsmodus festlegen.

Was geprüft wurde

Geprüft wurde, welche Scheduler- und Timer-Parameter der Kernel liest, wie die Werte normalisiert werden und welche Felder von Win32PrioritySeparation wofür zuständig sind.

Untersuchungsbereich

Windows 11 25H2 build 26200.9168, Scheduler- und Timer-Pfade des Kernels. Konkrete Spiele und Anwendungen waren nicht Teil der Messungen.

Methodik

Master-Tabelle der Kernel-Parameter, Beobachtung der Runtime-Zugriffe auf die Registry und Prüfung der Bitfelder und der Normalisierung der Werte.

Kanonische Parameter

Registry path	Value	Type	Default	Reader/timing
HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl	Win32PrioritySeparation	REG_DWORD	0x02	ntoskrnl.exe, dann session initialization
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel	GlobalTimerResolutionRequests	REG_DWORD	0	kernel phase-0
derselbe Pfad	MaxDynamicTickDuration	REG_DWORD	0xFFFFFFFF	dynamic tick duration limit
derselbe Pfad	EnablePerCpuClockTickScheduling	REG_DWORD	0	phase-1 clock init
derselbe Pfad	DisableLowQosTimerResolution	REG_DWORD	1	timer policy init
derselbe Pfad	DpcCumulativeSoftTimeout	REG_DWORD	120000	DPC budget init
derselbe Pfad	ForceForegroundBoostDecay	REG_DWORD	0	scheduler init
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\I/O System	PassiveIntRealTimeWorkerPriority	REG_DWORD	16	I/O worker init

Win32PrioritySeparation

Der Wert besteht aus Bitfeldern. Der Kernel bestimmt separat die Verstärkung der aktiven Anwendung (foreground boost), Typ und Dauer des Quantums. Im untersuchten Build ist der Anfangswert der Client-Version von Windows gleich 0x02. Auf den Eingabewert wird die Maske 0x3F angewendet, daher können verschiedene Einträge einen Scheduler-Modus festlegen.

Die bitweise Analyse der Bitfelder, ein Rechner für äquivalente Werte sowie historische Messungen von Latenz und FPS sind in eine separate Untersuchung «Win32PrioritySeparation: Latenz und FPS bei voller CPU-Auslastung» ausgelagert. Die Anwenderseite des Themas — Auswahl, Effekt und Rückgabe — behandelt die Seite der BoosterX-Einstellung.

Der Parameter ändert die Planungsregeln. Zur Bewertung des Nutzens in einer konkreten Aufgabe muss der Test mit CPU-Last wiederholt und die Latenz gemessen werden; eine universelle Beschleunigung garantiert die Einstellung nicht.

Timer policy

GlobalTimerResolutionRequests und benachbarte Timer-Parameter werden aus Session Manager\Kernel gelesen. Sie beeinflussen den Geltungsbereich der Anfragen zur Timer-Auflösung, lokal oder systemweit, sowie die Verteilung der Takt-Interrupts zwischen den CPUs. Auf unterstützten Plattformen kann die getrennte Takt-Planung pro CPU auch ohne erzwungene Einstellung funktionieren.

MaxDynamicTickDuration begrenzt die Schlafdauer im Leerlauf ohne periodische Takte. Die Maßeinheit beträgt 100 Nanosekunden: 7500 bedeutet 0.75 ms, nicht 7.5 ms. Die Obergrenze wird zusätzlich durch die aktuelle Timer-Auflösung begrenzt. 0xFFFFFFFF hebt die zusätzliche Grenze auf.

DisableLowQosTimerResolution ändert die Begrenzung für Anfragen zur Timer-Auflösung mit niedriger Priorität. Eine dauerhaft hohe Auflösung wird dadurch allein nicht festgelegt.

Die Timer-Regeln sollten nur für Last geändert werden, die solche Anfragen tatsächlich ausführt. Eine dauerhaft hohe Auflösung erhöht die Zahl der Timer-Interrupts und den Energieverbrauch.

DPC budget und boost decay

DpcCumulativeSoftTimeout legt das Budget der gesamten Ausführungszeit von DPC fest. Seine Normalisierungsgrenzen, der Zusammenhang mit DpcWatchdogPeriod sowie benachbarte DPC-Parameter und Worker-Limits sind in der Untersuchung «DPC und Kernel Executive workers in Windows 11 25H2» analysiert; hier werden sie nicht wiedergegeben. ForceForegroundBoostDecay ändert die Regeln für das Abklingen der Verstärkung der aktiven Anwendung, und PassiveIntRealTimeWorkerPriority legt die Priorität des speziellen E/A-Arbeits-Threads fest. Für PassiveIntRealTimeWorkerPriority akzeptiert der Code 17..21; fehlt der Eintrag, wird 16 verwendet. Der Wert 18 ist zulässig und erhöht die Priorität.

Beim Vergleich sind die Maßeinheiten und Bereichsgrenzen zu berücksichtigen. Der Kernel normalisiert nicht unterstützte Werte, daher kann die eingetragene Zahl von der tatsächlich angewendeten abweichen.

Diese Parameter betreffen die Systemplanung und die Treiberdiagnose. Ohne eine DPC/ISR-Trace gibt es keine verlässliche Grundlage für ihre manuelle Änderung.

Ergebnisse

• Das Lesen aller Parameter der Tabelle wurde in ntoskrnl.exe des Builds 26200.9168 bestätigt: Win32PrioritySeparation wird bei der Initialisierung des Schedulers und der session initialization gelesen, die Timer-Parameter in den Phasen der Kernel-Initialisierung.
• Die Anfangswerte und die Normalisierung wurden bestätigt: die Maske 0x3F für Win32PrioritySeparation, der Bereich 17..21 mit Rückfallwert 16 für PassiveIntRealTimeWorkerPriority, die Einheit 100 ns bei MaxDynamicTickDuration.
• Die Beobachtungen selbst sind qualitativ: Werte für Latenz, FPS oder Hintergrundlast wurden in dieser Untersuchung nicht gemessen.

Was bestätigt ist

• Reader und Normalisierung der Parameter in ntoskrnl.exe des untersuchten Builds.
• Der Anfangswert 0x02 für Win32PrioritySeparation und die Maske 0x3F.
• Die Bedeutung der Felder boost und Quanten, die Einheiten von MaxDynamicTickDuration.
• Die Normalisierung von PassiveIntRealTimeWorkerPriority auf den Bereich 17..21 mit Rückfallwert 16.

Was nicht bestätigt ist

• Der Einfluss der Änderung auf FPS, Latenz oder Reaktionsfähigkeit.
• Der Nutzen der Änderung ohne Last, die Timer und DPC tatsächlich verwendet.

Praktische Schlussfolgerung

Belassen Sie die Standardwerte. Ändern Sie die Parameter nur für Last, die die entsprechenden Anfragen tatsächlich ausführt, und vergleichen Sie die Ergebnisse in identischen Durchläufen.

Wiederherstellung des Zustands

Stellen Sie die Standardwerte wieder her oder löschen Sie die optionalen Einträge. Kernel-Parameter werden beim nächsten Start von Windows angewendet.

Einschränkungen

Lesvorgänge in der Phase 0 des Starts können außerhalb des Aufzeichnungsintervalls von Procmon liegen. Die Untersuchung bestätigt den Lesecode und die Normalisierung am Build 26200.9168. Die Zahl der unabhängigen Beobachtungsdurchläufe (Starts und Traces) ist in den Daten des Artikels nicht festgehalten, daher wurde die Wiederholbarkeit der Beobachtungen der Reader selbst nicht quantitativ bewertet. Ein universeller Einfluss auf Leistung oder Latenz ist nicht festgestellt.

Die Untersuchung und die verwendeten Werkzeuge gehören dem Entwickler von BoosterX, daher hat der Entwickler ein direktes Interesse an den Ergebnissen. Die Methodik und die Grenzen der Anwendbarkeit sind oben beschrieben, und die Schlussfolgerungen lassen sich anhand offener Daten und der aufgeführten öffentlichen Quellen überprüfen.

Quellen

• Win32PrioritySeparation, Microsoft Learn, geprüft am 2026-09-01.
• Timer resolution, Microsoft Learn, geprüft am 2026-09-01.

Öffentliche Quellen geprüft: 2026-09-02.

Änderungsverlauf

• 2026-09-20: Disclaimer zum Interessenkonflikt hinzugefügt; reviewed/modified-Daten abgestimmt.
• 2026-09-19: Abschnitt «Ergebnisse», Querverweise auf die Untersuchungen Win32PrioritySeparation und der DPC/Worker-Parameter sowie die Seite der BoosterX-Einstellung hinzugefügt; das Fehlen der Zahl der Beobachtungsdurchläufe festgehalten.
• 2026-09-02: erste Veröffentlichung; Reader, Normalisierung und Bitfelder bestätigt, Grenzen des praktischen Nutzens hinzugefügt.