Skip to content

Scheduler, timers and foreground boost in Windows 11 25H2

On this page

Short answer

Section titled “Short answer”

These values control the scheduler, timer resolution, clock interrupt distribution and the DPC budget. The full effect cannot be determined from a name alone: Windows applies bitmasks and normalizes input values. Different entries can set the same operating mode.

What was checked

Section titled “What was checked”

We checked which scheduler and timer parameters the kernel reads, how values are normalized, and which Win32PrioritySeparation fields are responsible for what.

Scope of research

Section titled “Scope of research”

Windows 11 25H2 build 26200.9168, kernel scheduler and timer paths. Specific games and applications were not part of the measurements.

Methodology

Section titled “Methodology”

A master table of kernel parameters, observation of runtime accesses to the Registry, and verification of bit fields and value normalization.

Canonical parameters

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

Win32PrioritySeparation

Section titled “Win32PrioritySeparation”

The value consists of bit fields. The kernel separately determines the foreground boost of the active application, and the type and duration of the quantum. In the build studied, the initial value for client Windows is 0x02. A mask of 0x3F is applied to the input value, so different entries can set the same scheduler mode.

The bit-by-bit breakdown of the bit fields, a calculator of equivalent values, and historical latency and FPS measurements are covered in a separate study «Win32PrioritySeparation: latency and FPS under full CPU load». The user-facing side of the question — selection, effect and rollback — is covered by the BoosterX setting page.

The parameter changes scheduling rules. To assess the benefit for a specific task, the test must be repeated under CPU load and latency measured; the setting does not guarantee universal acceleration.

Timer policy

Section titled “Timer policy”

GlobalTimerResolutionRequests and neighboring timer parameters are read from Session Manager\Kernel. They affect the scope of timer resolution requests, local or system-wide, and the distribution of clock interrupts between CPUs. On supported platforms, per-CPU clock scheduling may work without forced configuration.

MaxDynamicTickDuration limits the sleep duration when idle without periodic ticks. The unit of measurement is 100 nanoseconds: 7500 means 0.75 ms, not 7.5 ms. The upper bound is additionally limited by the current timer resolution. 0xFFFFFFFF removes the additional limit.

DisableLowQosTimerResolution changes the limit for low-priority timer resolution requests. A permanently high resolution is not set by this alone.

Timer rules should only be changed for a workload that actually issues such requests. A permanently high resolution increases the number of timer interrupts and energy consumption.

DPC budget and boost decay

Section titled “DPC budget and boost decay”

DpcCumulativeSoftTimeout sets the budget for the total DPC execution time. Its normalization bounds, its relationship with DpcWatchdogPeriod, and neighboring DPC parameters and worker limits are covered in the study «DPC and Kernel Executive workers in Windows 11 25H2»; they are not restated here. ForceForegroundBoostDecay changes the decay rules for the foreground boost, and PassiveIntRealTimeWorkerPriority sets the priority of the special I/O worker thread. For PassiveIntRealTimeWorkerPriority, the code accepts 17..21; if the entry is absent, 16 is used. The value 18 is valid and raises the priority.

When comparing, take units of measurement and range limits into account. The kernel normalizes unsupported values, so the recorded number may differ from the one actually applied.

These parameters relate to system scheduling and driver diagnostics. Without a DPC/ISR trace there is no reliable basis for changing them manually.

Results

Section titled “Results”
  • Reading of all parameters in the table was confirmed in ntoskrnl.exe of build 26200.9168: Win32PrioritySeparation is read during scheduler initialization and session initialization, timer parameters — at kernel initialization phases.
  • Initial values and normalization were confirmed: the mask 0x3F for Win32PrioritySeparation, the range 17..21 with fallback 16 for PassiveIntRealTimeWorkerPriority, the 100 ns unit for MaxDynamicTickDuration.
  • The observations themselves are qualitative: latency, FPS or background load values were not measured in this study.

What was confirmed

Section titled “What was confirmed”
  • Readers and normalization of the parameters in ntoskrnl.exe of the build studied.
  • The initial value 0x02 for Win32PrioritySeparation and the mask 0x3F.
  • The meaning of the boost and quantum fields, the units of MaxDynamicTickDuration.
  • Normalization of PassiveIntRealTimeWorkerPriority to the range 17..21 with fallback 16.

What was not confirmed

Section titled “What was not confirmed”
  • The effect of the change on FPS, latency or responsiveness.
  • The benefit of the change without a workload that actually uses timers and DPC.

Practical conclusion

Section titled “Practical conclusion”

Leave the default values. Change parameters only for a workload that actually issues the corresponding requests, and compare results across identical runs.

Restoring the state

Section titled “Restoring the state”

Return the default values or delete the optional entries. Kernel parameters are applied on the next Windows boot.

Limitations

Section titled “Limitations”

Reads at boot phase 0 may fall outside the Procmon recording interval. The study confirms the read code and normalization on build 26200.9168. The number of independent observation runs (boots and traces) is not recorded in the article’s data, so the repeatability of the reader observations themselves was not quantitatively assessed. No universal effect on performance or latency has been established.

The study and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and scope of applicability are described above, and the conclusions can be verified against open data and the listed public sources.

Sources

Section titled “Sources”

Public sources reviewed: 2026-09-02.

Change history

Section titled “Change history”
  • 2026-09-20: added a conflict-of-interest disclaimer; aligned reviewed/modified dates.
  • 2026-09-19: added the “Results” section, cross-references to the studies of Win32PrioritySeparation and DPC/worker parameters, and the BoosterX setting page; recorded the absence of an observation run count.
  • 2026-09-02: first publication; confirmed readers, normalization and bit fields, added the limits of practical benefit.