DPC e Kernel Executive workers in Windows 11 25H2

Risposta breve

Il gruppo di DpcQueueDepth, worker limits e parametri watchdog è spesso percepito come un insieme di latency tweaks universali. In realtà si tratta di limiti interni e meccanismi di protezione del kernel. Il loro effetto si manifesta solo con una specifica coda DPC, un determinato numero di processori, un tipo di driver o un errore del worker.

Cosa è stato verificato

È stato verificato quali limiti DPC, worker threads e watchdog legge il kernel, come vengono normalizzati i valori e dove questi meccanismi vengono effettivamente applicati.

Ambito della ricerca

Windows 11 25H2 build 26200.9168, rami Session Manager\Kernel e Session Manager\Executive. Le funzioni dipendenti dall’hardware e i driver specifici non sono stati inclusi nelle misurazioni.

Metodologia

Analisi statica di ntoskrnl.exe: ricerca di readers e consumatori, verifica degli intervalli e della normalizzazione dei valori; confronto con la documentazione pubblica di Microsoft.

Percorso canonico e valori

Percorso DPC e watchdog:

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

Value	Type	Default/normalization	Cosa controlla
DpcQueueDepth	REG_DWORD	4	profondità della coda DPC
MinimumDpcRate	REG_DWORD	3	frequenza minima di elaborazione DPC
IdealDpcRate	REG_DWORD	20	DPC rate target
AdjustDpcThreshold	REG_DWORD	20	soglia di adattamento della DPC policy
ThreadDpcEnable	REG_DWORD	1	elaborazione thread-DPC
DpcWatchdogPeriod	REG_DWORD	120000	periodo del DPC watchdog
DpcCumulativeSoftTimeout	REG_DWORD	120000 nella build esaminata	soft budget accumulato
PassiveWatchdogTimeout	REG_DWORD	300 secondi	watchdog a livello passivo con KD
ForceIdleGracePeriod	REG_DWORD	5 secondi	periodo di grazia force-idle
PerfIsoEnabled	REG_DWORD	0	isolamento delle prestazioni
CacheIsoBitmap	REG_DWORD	0	maschera Intel CAT L3
SchedulerAssistThreadFlagOverride	REG_DWORD	0	override dell’assist dello scheduler
VpThreadSystemWorkPriority	REG_DWORD	30, intervallo 1..31	priorità di lavoro del processore virtuale
AlwaysTrackIoBoosting	REG_DWORD	0	tracciamento diagnostico del boost I/O

Percorso Kernel Executive workers:

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

Value	Type	Default/normalization	Cosa controlla
AdditionalCriticalWorkerThreads	REG_DWORD	0, clamp 0..100	worker critici aggiuntivi
AdditionalDelayedWorkerThreads	REG_DWORD	0, clamp 0..100	worker ritardati
MaximumKernelWorkerThreads	REG_DWORD	4096, 32..16384	limite superiore dei kernel workers
ForceEnableMutantAutoboost	REG_DWORD	0	autoboost del mutant
WorkerThreadTimeoutInSeconds	REG_DWORD	600, 60..3600	timeout del worker

Session Manager\Kernel e Session Manager\Executive sono rami di configurazione diversi. Per ogni valore è importante il percorso che il reader del kernel apre in questa build.

Coda DPC e rates

Il kernel utilizza DpcQueueDepth, MinimumDpcRate, IdealDpcRate e AdjustDpcThreshold per controllare la coda e l’adattamento dell’elaborazione DPC. I default verificati 4/3/20/20 coincidono già con lo stato standard di Windows 11 25H2; riscrivere questi numeri non cambia nulla.

Utilità: questi parametri possono essere utili nell’analisi di uno specifico DPC backlog, ma senza una traccia ETW/WPR la modifica alla cieca non diagnostica la causa. Una coda più grande può ritardare l’elaborazione e aumentare la coda della latenza.

Thread DPC e worker limits

ThreadDpcEnable=1 abilita l’infrastruttura threaded-DPC, 0 riporta il lavoro al normale DIRQL path e può allungare le finestre di interrupt-off. MaximumKernelWorkerThreads limita il pool complessivo dei kernel workers. AdditionalCriticalWorkerThreads e AdditionalDelayedWorkerThreads vengono aggiunti ai pool di base: su Windows client si tratta rispettivamente di 5 worker critici e 7 ritardati prima dell’applicazione dell’override.

Più thread non significa meno latenza: i worker aggiuntivi consumano stack, tempo dello scheduler e risorse di cache, mentre la coda può essere limitata da un altro componente. AdditionalDelayedWorkerThreads=32 aggiunge effettivamente worker ritardati, ma non c’è un guadagno universale misurato.

Watchdog e timeout

DpcCumulativeSoftTimeout limita il tempo DPC accumulato. DpcWatchdogPeriod=0 è ammesso e disattiva questo watchdog; qualsiasi valore diverso da zero inferiore a 2000 diventa 2000 ms. PassiveWatchdogTimeout viene utilizzato solo con il kernel debugger abilitato, quindi su un sistema normale questo timer non è attivo nemmeno con i 300 secondi standard. WorkerThreadTimeoutInSeconds limita il blocco di un’operazione del worker.

DpcCumulativeSoftTimeout ha un limite inferiore di 2000 ms e non può superare DpcWatchdogPeriod. Per ottenere il valore 240000, anche il periodo del watchdog deve essere 240000. WorkerThreadTimeoutInSeconds viene normalizzato nell’intervallo 60..3600 secondi; scrivere 0 non disattiva il timeout, ma porta al valore minimo.

Disattivare il timeout di protezione elimina la diagnostica, ma non corregge la causa del blocco. Per un sistema di produzione il watchdog è parte del meccanismo di rilevamento dei driver difettosi.

Kernel Executive policy

ForceEnableMutantAutoboost si trova nel ramo Executive, mentre ForceIdleGracePeriod, PerfIsoEnabled, CacheIsoBitmap, SchedulerAssistThreadFlagOverride, VpThreadSystemWorkPriority e AlwaysTrackIoBoosting vengono letti dal ramo Kernel. Questa differenza è critica: la voce con lo stesso nome nella sottochiave adiacente non viene applicata.

CacheIsoBitmap viene utilizzato solo con il supporto Intel Resource Director/CAT; senza CAT il valore non crea isolamento. SchedulerAssistThreadFlagOverride=0 e 1 lasciano l’attivazione automatica, 2 disattiva forzatamente il ramo. VpThreadSystemWorkPriority ammette 1..31, altrimenti viene reimpostato a 1; il default è 30, mentre 31 è solo il limite superiore. AlwaysTrackIoBoosting=1 abilita l’allocazione diagnostica e la stack-capture sui boost paths, e non mantiene elevata la priorità I/O.

Utilità: senza un consumer confermato l’effetto di solito è assente o troppo piccolo per una decisione pratica. Tali valori sono utili come oggetto di una diagnostica kernel separata, non come insieme generale di ottimizzazione.

Risultati

I default verificati 4/3/20/20 coincidono con lo stato standard di Windows 11 25H2. I worker aggiuntivi per impostazione predefinita sono pari a zero, il limite superiore dei kernel workers è 4096 con intervallo 32..16384. I parametri watchdog vengono normalizzati: un valore inferiore a 2000 ms diventa 2000, mentre DpcCumulativeSoftTimeout non supera il periodo del watchdog. I rami Kernel e Executive non sono intercambiabili.

Cosa è confermato

• Readers e consumatori dei parametri in ntoskrnl.exe della build esaminata.
• Valori predefiniti e limiti di normalizzazione, incluse le dipendenze tra i parametri watchdog.
• Separazione dei rami Kernel e Executive: la voce con lo stesso nome nella sottochiave adiacente non viene applicata.

Cosa non è confermato

• L’influenza della modifica dei parametri su FPS, latenza o reattività.
• L’utilità della modifica dei limiti senza un problema confermato con la coda DPC o il worker.

Conclusione pratica

Non modificate questi parametri alla cieca: senza una traccia ETW/WPR non è possibile stabilire la causa del backlog. Per un sistema in uso mantenete il watchdog abilitato e usate i parametri per la diagnostica, non come insieme di ottimizzazione.

Ripristino dello stato

Ripristinate i valori standard o eliminate le voci non necessarie. I parametri del kernel vengono applicati al successivo avvio di Windows.

Fonti e limitazioni

Readers e consumers sono stati verificati in ntoskrnl.exe Windows 11 25H2 build 26200.9168. Non vengono pubblicati offsets o pseudocodice. Le metriche finali per l’utente non sono state incluse in questa serie.

• DPCs and threads, Microsoft Learn, verificato 2026-09-01.
• Bug checks 0x133 DPC_WATCHDOG_VIOLATION, Microsoft Learn, verificato 2026-09-01.

Come ripetere la parte dinamica delle osservazioni — vedi Come verificare autonomamente.

La ricerca e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, pertanto lo sviluppatore ha un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate tramite i dati aperti e le fonti pubbliche elencate.

Fonti pubbliche verificate: 2026-09-02.

Cronologia delle modifiche

• 2026-09-20: la sezione «Risultati» è stata spostata nella posizione obbligatoria prima di «Ripristino dello stato»; aggiunti il disclaimer sul conflitto di interessi e il link alla verifica autonoma delle osservazioni dinamiche nella metodologia.
• 2026-09-02: prima pubblicazione; confermati readers, defaults e clamps, aggiunti i limiti dell’utilità pratica.