DPC і Kernel Executive workers у Windows 11 25H2

Коротка відповідь

Група DpcQueueDepth, worker limits і watchdog-параметрів часто сприймається як набір універсальних latency tweaks. Насправді це внутрішні ліміти та захисні механізми ядра. Їхній ефект проявляється лише за конкретної черги DPC, кількості процесорів, типу драйвера або помилки worker.

Що перевіряли

Перевіряли, які ліміти DPC, worker threads і watchdog читає ядро, як нормалізуються значення і де ці механізми справді застосовуються.

Область дослідження

Windows 11 25H2 build 26200.9168, гілки Session Manager\Kernel і Session Manager\Executive. Апаратно-залежні функції та конкретні драйвери у вимірювання не входили.

Методика

Статичний аналіз ntoskrnl.exe: пошук readers і споживачів, перевірка діапазонів і нормалізації значень; звірка з публічною документацією Microsoft.

Канонічний шлях і значення

Шлях DPC і watchdog:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel

Value	Type	Default/normalization	Що керує
DpcQueueDepth	REG_DWORD	4	глибина DPC queue
MinimumDpcRate	REG_DWORD	3	мінімальна частота DPC обробки
IdealDpcRate	REG_DWORD	20	цільова DPC rate
AdjustDpcThreshold	REG_DWORD	20	поріг адаптації DPC policy
ThreadDpcEnable	REG_DWORD	1	thread-DPC processing
DpcWatchdogPeriod	REG_DWORD	120000	DPC watchdog period
DpcCumulativeSoftTimeout	REG_DWORD	120000 у дослідженій збірці	накопичений soft budget
PassiveWatchdogTimeout	REG_DWORD	300 секунд	passive-level watchdog при KD
ForceIdleGracePeriod	REG_DWORD	5 секунд	force-idle grace period
PerfIsoEnabled	REG_DWORD	0	performance isolation
CacheIsoBitmap	REG_DWORD	0	Intel CAT L3 mask
SchedulerAssistThreadFlagOverride	REG_DWORD	0	scheduler assist override
VpThreadSystemWorkPriority	REG_DWORD	30, діапазон 1..31	virtual processor work priority
AlwaysTrackIoBoosting	REG_DWORD	0	діагностичний I/O boost tracking

Шлях Kernel Executive workers:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Executive

Value	Type	Default/normalization	Що керує
AdditionalCriticalWorkerThreads	REG_DWORD	0, clamp 0..100	додаткові critical workers
AdditionalDelayedWorkerThreads	REG_DWORD	0, clamp 0..100	delayed workers
MaximumKernelWorkerThreads	REG_DWORD	4096, 32..16384	верхня межа kernel workers
ForceEnableMutantAutoboost	REG_DWORD	0	mutant autoboost
WorkerThreadTimeoutInSeconds	REG_DWORD	600, 60..3600	worker timeout

Session Manager\Kernel і Session Manager\Executive є різними гілками конфігурації. Для кожного значення важливий шлях, який відкриває reader ядра в цій збірці.

DPC queue і rates

Ядро використовує DpcQueueDepth, MinimumDpcRate, IdealDpcRate і AdjustDpcThreshold для контролю черги та адаптації DPC processing. Перевірені defaults 4/3/20/20 вже збігаються зі штатним станом Windows 11 25H2; повторний запис цих чисел нічого не змінює.

Корисність: ці параметри можуть бути корисні при розборі конкретного DPC backlog, але без ETW/WPR-траси зміна наосліп не діагностує причину. Велика черга може відкласти обробку та збільшити хвіст затримки.

Thread DPC і worker limits

ThreadDpcEnable=1 вмикає threaded-DPC infrastructure, 0 повертає роботу в звичайний DIRQL path і може подовжити вікна interrupt-off. MaximumKernelWorkerThreads обмежує загальний пул kernel workers. AdditionalCriticalWorkerThreads і AdditionalDelayedWorkerThreads додаються до базових пулів: на клієнтській Windows це відповідно 5 critical і 7 delayed workers до застосування override.

Більше потоків не означає менше latency: додаткові workers споживають stack, scheduler time і cache resources, а черга може бути обмежена іншим компонентом. AdditionalDelayedWorkerThreads=32 справді додає delayed workers, але виміряного універсального виграшу немає.

Watchdog і timeout

DpcCumulativeSoftTimeout обмежує накопичений час DPC. DpcWatchdogPeriod=0 допустимий і вимикає цей watchdog; будь-яке ненульове значення нижче 2000 стає 2000 ms. PassiveWatchdogTimeout використовується лише при увімкненому kernel debugger, тому на звичайній системі цей timer не активний навіть за штатних 300 секунд. WorkerThreadTimeoutInSeconds обмежує зависання worker operation.

DpcCumulativeSoftTimeout має нижню межу 2000 ms і не може перевищувати DpcWatchdogPeriod. Щоб отримати значення 240000, watchdog period також має бути 240000. WorkerThreadTimeoutInSeconds нормалізується в діапазон 60..3600 секунд; запис 0 не вимикає timeout, а призводить до мінімального значення.

Вимкнення захисного timeout прибирає діагностику, але не виправляє причину блокування. Для production-системи watchdog є частиною механізму виявлення несправних драйверів.

Kernel Executive policy

ForceEnableMutantAutoboost знаходиться в гілці Executive, а ForceIdleGracePeriod, PerfIsoEnabled, CacheIsoBitmap, SchedulerAssistThreadFlagOverride, VpThreadSystemWorkPriority і AlwaysTrackIoBoosting читаються з гілки Kernel. Ця відмінність критична: однойменний запис у сусідньому підключі не застосовується.

CacheIsoBitmap використовується лише за підтримки Intel Resource Director/CAT; без CAT значення не створює ізоляції. SchedulerAssistThreadFlagOverride=0 і 1 залишають автоматичне вмикання, 2 примусово вимикає гілку. VpThreadSystemWorkPriority допускає 1..31, інакше скидається до 1; default 30, а 31 є лише верхньою межею. AlwaysTrackIoBoosting=1 вмикає діагностичні allocation і stack-capture на boost paths, а не утримує I/O priority підвищеним.

Корисність: без підтвердженого consumer ефект зазвичай відсутній або занадто малий для практичного рішення. Такі значення корисні як предмет окремої kernel-діагностики, а не як загальний набір оптимізації.

Результати

Перевірені defaults 4/3/20/20 збігаються зі штатним станом Windows 11 25H2. Додаткові workers за замовчуванням дорівнюють нулю, верхня межа kernel workers — 4096 з діапазоном 32..16384. Watchdog-параметри нормалізуються: значення нижче 2000 мс стає 2000, а DpcCumulativeSoftTimeout не перевищує період watchdog. Гілки Kernel і Executive не взаємозамінні.

Що підтверджено

• Readers і споживачі параметрів у ntoskrnl.exe дослідженої збірки.
• Значення за замовчуванням і межі нормалізації, включно із залежностями між watchdog-параметрами.
• Розділення гілок Kernel і Executive: однойменний запис у сусідньому підключі не застосовується.

Що не підтверджено

• Вплив зміни параметрів на FPS, затримку або відзивчивість.
• Користь зміни лімітів без підтвердженої проблеми з чергою DPC або worker.

Практичний висновок

Не змінюйте ці параметри наосліп: без ETW/WPR-траси причину backlog встановити не можна. Для робочої системи зберігайте watchdog увімкненим, а параметри використовуйте для діагностики, а не як набір оптимізації.

Відновлення стану

Поверніть штатні значення або видаліть необов’язкові записи. Параметри ядра застосовуються при наступному завантаженні Windows.

Джерела та обмеження

Readers і consumers перевірені в ntoskrnl.exe Windows 11 25H2 build 26200.9168. Не публікуються offsets або псевдокод. Кінцеві користувацькі метрики в цю серію не входили.

• DPCs and threads, Microsoft Learn, перевірено 2026-09-01.
• Bug checks 0x133 DPC_WATCHDOG_VIOLATION, Microsoft Learn, перевірено 2026-09-01.

Як повторити динамічну частину спостережень — див. Як перевірити самостійно.

Дослідження та використані інструменти належать розробнику BoosterX, тому в розробника є прямий інтерес до результатів. Методика та межі застосовності описані вище, а висновки можна перевірити за відкритими даними та переліченими публічними джерелами.

Публічні джерела перевірені: 2026-09-02.

Історія змін

• 2026-09-20: розділ «Результати» переміщено на обов’язкове місце до «Відновлення стану»; додано дисклеймер про конфлікт інтересів і посилання на самостійну перевірку динамічних спостережень у методиці.
• 2026-09-02: перша публікація; підтверджено readers, defaults і clamps, додано межі практичної користі.