DPC og Kernel Executive-workers i Windows 11 25H2
På denne side
Kort svar
Sektion kaldt “Kort svar”Gruppen af DpcQueueDepth, worker limits og watchdog-parametre opfattes ofte som et sæt universelle latency tweaks. I virkeligheden er det interne grænser og beskyttelsesmekanismer i kernen. Deres effekt viser sig kun ved en konkret DPC-kø, antal processorer, drivertype eller worker-fejl.
Hvad der blev undersøgt
Sektion kaldt “Hvad der blev undersøgt”Der blev undersøgt, hvilke grænser for DPC, worker threads og watchdog kernen læser, hvordan værdierne normaliseres, og hvor disse mekanismer faktisk anvendes.
Undersøgelsens omfang
Sektion kaldt “Undersøgelsens omfang”Windows 11 25H2 build 26200.9168, grenene Session Manager\Kernel og Session Manager\Executive. Hardwareafhængige funktioner og konkrete drivere indgik ikke i målingerne.
Metode
Sektion kaldt “Metode”Statisk analyse af ntoskrnl.exe: søgning efter readers og forbrugere, kontrol af intervaller og normalisering af værdier; verifikation mod Microsofts offentlige dokumentation.
Kanonisk sti og værdier
Sektion kaldt “Kanonisk sti og værdier”Sti for DPC og watchdog:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel
| Value | Type | Default/normalization | Hvad den styrer |
|---|---|---|---|
DpcQueueDepth |
REG_DWORD |
4 |
dybden af DPC queue |
MinimumDpcRate |
REG_DWORD |
3 |
minimal DPC-behandlingsfrekvens |
IdealDpcRate |
REG_DWORD |
20 |
målrettet DPC rate |
AdjustDpcThreshold |
REG_DWORD |
20 |
tærskel for tilpasning af DPC policy |
ThreadDpcEnable |
REG_DWORD |
1 |
thread-DPC processing |
DpcWatchdogPeriod |
REG_DWORD |
120000 |
DPC watchdog-periode |
DpcCumulativeSoftTimeout |
REG_DWORD |
120000 i den undersøgte build |
akkumuleret soft budget |
PassiveWatchdogTimeout |
REG_DWORD |
300 sekunder |
passive-level watchdog ved KD |
ForceIdleGracePeriod |
REG_DWORD |
5 sekunder |
force-idle grace period |
PerfIsoEnabled |
REG_DWORD |
0 |
performance isolation |
CacheIsoBitmap |
REG_DWORD |
0 |
Intel CAT L3-maske |
SchedulerAssistThreadFlagOverride |
REG_DWORD |
0 |
scheduler assist override |
VpThreadSystemWorkPriority |
REG_DWORD |
30, interval 1..31 |
arbejdsprioritet for virtuel processor |
AlwaysTrackIoBoosting |
REG_DWORD |
0 |
diagnostisk I/O boost-sporing |
Sti for Kernel Executive workers:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Executive
| Value | Type | Default/normalization | Hvad den styrer |
|---|---|---|---|
AdditionalCriticalWorkerThreads |
REG_DWORD |
0, clamp 0..100 |
ekstra kritiske workers |
AdditionalDelayedWorkerThreads |
REG_DWORD |
0, clamp 0..100 |
forsinkede workers |
MaximumKernelWorkerThreads |
REG_DWORD |
4096, 32..16384 |
øvre grænse for kernel workers |
ForceEnableMutantAutoboost |
REG_DWORD |
0 |
mutant autoboost |
WorkerThreadTimeoutInSeconds |
REG_DWORD |
600, 60..3600 |
worker timeout |
Session Manager\Kernel og Session Manager\Executive er forskellige konfigurationsgrene. For hver værdi er den sti vigtig, som kernens reader åbner i den pågældende build.
DPC queue og rates
Sektion kaldt “DPC queue og rates”Kernen bruger DpcQueueDepth, MinimumDpcRate, IdealDpcRate og AdjustDpcThreshold til at kontrollere køen og tilpasse DPC processing. De undersøgte defaults 4/3/20/20 svarer allerede til standardtilstanden i Windows 11 25H2; at skrive disse tal igen ændrer intet.
Anvendelighed: disse parametre kan være nyttige ved analyse af et konkret DPC-backlog, men uden en ETW/WPR-trace diagnosticerer en ændring i blinde ikke årsagen. En stor kø kan udskyde behandlingen og øge latency-halen.
Thread DPC og worker limits
Sektion kaldt “Thread DPC og worker limits”ThreadDpcEnable=1 aktiverer threaded-DPC-infrastruktur, 0 sender arbejdet tilbage til den normale DIRQL-path og kan forlænge interrupt-off-vinduer. MaximumKernelWorkerThreads begrænser den samlede pulje af kernel workers. AdditionalCriticalWorkerThreads og AdditionalDelayedWorkerThreads lægges til grundpuljerne: på klient-Windows er det henholdsvis 5 kritiske og 7 forsinkede workers før override anvendes.
Flere tråde betyder ikke mindre latency: ekstra workers forbruger stack, scheduler-tid og cache-ressourcer, og køen kan være begrænset af en anden komponent. AdditionalDelayedWorkerThreads=32 tilføjer ganske vist forsinkede workers, men der er ingen målt universel gevinst.
Watchdog og timeout
Sektion kaldt “Watchdog og timeout”DpcCumulativeSoftTimeout begrænser den akkumulerede DPC-tid. DpcWatchdogPeriod=0 er tilladt og slår denne watchdog fra; enhver ikke-nul værdi under 2000 bliver 2000 ms. PassiveWatchdogTimeout bruges kun med aktiveret kernel debugger, så på et almindeligt system er denne timer ikke aktiv, selv ved standardværdien 300 sekunder. WorkerThreadTimeoutInSeconds begrænser et hængende worker operation.
DpcCumulativeSoftTimeout har en nedre grænse på 2000 ms og kan ikke overstige DpcWatchdogPeriod. For at opnå værdien 240000 skal watchdog period også være 240000. WorkerThreadTimeoutInSeconds normaliseres til intervallet 60..3600 sekunder; at skrive 0 slår ikke timeout fra, men fører til minimumsværdien.
At slå den beskyttende timeout fra fjerner diagnostikken, men løser ikke årsagen til blokeringen. For et production-system er watchdog en del af mekanismen til at opdage defekte drivere.
Kernel Executive policy
Sektion kaldt “Kernel Executive policy”ForceEnableMutantAutoboost ligger i grenen Executive, mens ForceIdleGracePeriod, PerfIsoEnabled, CacheIsoBitmap, SchedulerAssistThreadFlagOverride, VpThreadSystemWorkPriority og AlwaysTrackIoBoosting læses fra grenen Kernel. Denne forskel er kritisk: en post med samme navn i den tilstødende undernøgle anvendes ikke.
CacheIsoBitmap bruges kun ved understøttelse af Intel Resource Director/CAT; uden CAT skaber værdien ingen isolering. SchedulerAssistThreadFlagOverride=0 og 1 efterlader automatisk aktivering, 2 slår grenen tvungent fra. VpThreadSystemWorkPriority tillader 1..31, ellers nulstilles til 1; default 30, og 31 er blot den øvre grænse. AlwaysTrackIoBoosting=1 aktiverer diagnostisk allocation og stack-capture på boost paths og holder ikke I/O-prioriteten forhøjet.
Anvendelighed: uden en bekræftet consumer-effekt er effekten normalt fraværende eller for lille til en praktisk beslutning. Sådanne værdier er nyttige som genstand for en separat kernel-diagnostik, ikke som et generelt optimeringssæt.
Resultater
Sektion kaldt “Resultater”De undersøgte defaults 4/3/20/20 svarer til standardtilstanden i Windows 11 25H2. Ekstra workers er som standard nul, den øvre grænse for kernel workers er 4096 med interval 32..16384. Watchdog-parametre normaliseres: en værdi under 2000 ms bliver 2000, og DpcCumulativeSoftTimeout overstiger ikke watchdog-perioden. Grenene Kernel og Executive kan ikke erstatte hinanden.
Hvad der er bekræftet
Sektion kaldt “Hvad der er bekræftet”- Readers og forbrugere af parametrene i
ntoskrnl.exei den undersøgte build. - Standardværdier og normaliseringsgrænser, herunder afhængigheder mellem watchdog-parametre.
- Adskillelsen af grenene
KernelogExecutive: en post med samme navn i den tilstødende undernøgle anvendes ikke.
Hvad der ikke er bekræftet
Sektion kaldt “Hvad der ikke er bekræftet”- Indvirkningen af at ændre parametrene på FPS, latency eller responsivitet.
- Nytten af at ændre grænser uden et bekræftet problem med DPC-køen eller worker.
Praktisk konklusion
Sektion kaldt “Praktisk konklusion”Ændr ikke disse parametre i blinde: uden en ETW/WPR-trace kan årsagen til backlog ikke fastslås. For et system i drift bør watchdog holdes aktiveret, og parametrene bør bruges til diagnostik, ikke som et optimeringssæt.
Gendannelse af tilstand
Sektion kaldt “Gendannelse af tilstand”Gendan standardværdierne, eller slet de valgfrie poster. Kernel-parametre anvendes ved næste opstart af Windows.
Kilder og begrænsninger
Sektion kaldt “Kilder og begrænsninger”Readers og consumers er verificeret i ntoskrnl.exe Windows 11 25H2 build 26200.9168. Offsets eller pseudokode offentliggøres ikke. Endelige brugerrelaterede målinger indgik ikke i denne serie.
- DPCs and threads, Microsoft Learn, verificeret 2026-09-01.
- Bug checks 0x133 DPC_WATCHDOG_VIOLATION, Microsoft Learn, verificeret 2026-09-01.
Se Sådan verificerer du selv for at gentage den dynamiske del af observationerne.
Undersøgelsen og de anvendte værktøjer tilhører udvikleren af BoosterX, så udvikleren har en direkte interesse i resultaterne. Metode og anvendelsesgrænser er beskrevet ovenfor, og konklusionerne kan verificeres via åbne data og de anførte offentlige kilder.
Offentlige kilder verificeret: 2026-09-02.
Ændringshistorik
Sektion kaldt “Ændringshistorik”- 2026-09-20: afsnittet «Resultater» flyttet til den obligatoriske placering før «Gendannelse af tilstand»; tilføjet disclaimer om interessekonflikt og link til selvstændig verifikation af dynamiske observationer i metoden.
- 2026-09-02: første publikation; readers, defaults og clamps bekræftet, grænser for praktisk nytte tilføjet.
