DPC et workers Kernel Executive dans Windows 11 25H2

Réponse courte

Le groupe DpcQueueDepth, des limites de workers et des paramètres de watchdog est souvent perçu comme un ensemble de latency tweaks universels. En réalité, ce sont des limites internes et des mécanismes de protection du noyau. Leur effet ne se manifeste que pour une file DPC précise, un nombre de processeurs, un type de pilote ou une erreur de worker donnés.

Ce qui a été vérifié

Nous avons vérifié quelles limites DPC, quels worker threads et quels watchdog le noyau lit, comment les valeurs sont normalisées et où ces mécanismes s’appliquent réellement.

Périmètre de l’étude

Windows 11 25H2 build 26200.9168, branches Session Manager\Kernel et Session Manager\Executive. Les fonctions dépendantes du matériel et les pilotes spécifiques n’ont pas été inclus dans les mesures.

Méthodologie

Analyse statique de ntoskrnl.exe : recherche des readers et des consommateurs, vérification des plages et de la normalisation des valeurs ; recoupement avec la documentation publique de Microsoft.

Chemin canonique et valeurs

Chemin DPC et watchdog :

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

Value	Type	Default/normalization	Что управляет
DpcQueueDepth	REG_DWORD	4	profondeur de la file DPC
MinimumDpcRate	REG_DWORD	3	fréquence minimale de traitement DPC
IdealDpcRate	REG_DWORD	20	DPC rate cible
AdjustDpcThreshold	REG_DWORD	20	seuil d’adaptation de la DPC policy
ThreadDpcEnable	REG_DWORD	1	thread-DPC processing
DpcWatchdogPeriod	REG_DWORD	120000	période du DPC watchdog
DpcCumulativeSoftTimeout	REG_DWORD	120000 dans la build étudiée	budget soft accumulé
PassiveWatchdogTimeout	REG_DWORD	300 secondes	watchdog de niveau passif sous KD
ForceIdleGracePeriod	REG_DWORD	5 secondes	délai de grâce force-idle
PerfIsoEnabled	REG_DWORD	0	performance isolation
CacheIsoBitmap	REG_DWORD	0	masque Intel CAT L3
SchedulerAssistThreadFlagOverride	REG_DWORD	0	override de l’assist du scheduler
VpThreadSystemWorkPriority	REG_DWORD	30, plage 1..31	priorité de travail du processeur virtuel
AlwaysTrackIoBoosting	REG_DWORD	0	suivi diagnostique du boost I/O

Chemin Kernel Executive workers :

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

Value	Type	Default/normalization	Что управляет
AdditionalCriticalWorkerThreads	REG_DWORD	0, clamp 0..100	critical workers supplémentaires
AdditionalDelayedWorkerThreads	REG_DWORD	0, clamp 0..100	delayed workers
MaximumKernelWorkerThreads	REG_DWORD	4096, 32..16384	limite supérieure des kernel workers
ForceEnableMutantAutoboost	REG_DWORD	0	mutant autoboost
WorkerThreadTimeoutInSeconds	REG_DWORD	600, 60..3600	timeout des workers

Session Manager\Kernel et Session Manager\Executive sont des branches de configuration différentes. Pour chaque valeur, le chemin que le reader du noyau ouvre dans cette build est important.

File DPC et rates

Le noyau utilise DpcQueueDepth, MinimumDpcRate, IdealDpcRate et AdjustDpcThreshold pour contrôler la file et adapter le DPC processing. Les defaults vérifiés 4/3/20/20 coïncident déjà avec l’état standard de Windows 11 25H2 ; réécrire ces nombres ne change rien.

Utilité : ces paramètres peuvent être utiles pour analyser un DPC backlog précis, mais sans trace ETW/WPR, une modification à l’aveugle ne diagnostique pas la cause. Une file importante peut différer le traitement et augmenter la queue de latence.

Thread DPC et limites de workers

ThreadDpcEnable=1 active l’infrastructure threaded-DPC, 0 renvoie le travail vers le chemin DIRQL normal et peut allonger les fenêtres interrupt-off. MaximumKernelWorkerThreads limite le pool global de kernel workers. AdditionalCriticalWorkerThreads et AdditionalDelayedWorkerThreads s’ajoutent aux pools de base : sur un Windows client, cela correspond respectivement à 5 critical et 7 delayed workers avant application de l’override.

Plus de threads ne signifie pas moins de latence : des workers supplémentaires consomment de la stack, du temps scheduler et des ressources de cache, et la file peut être limitée par un autre composant. AdditionalDelayedWorkerThreads=32 ajoute effectivement des delayed workers, mais il n’existe aucun gain universel mesuré.

Watchdog et timeout

DpcCumulativeSoftTimeout limite le temps DPC accumulé. DpcWatchdogPeriod=0 est admissible et désactive ce watchdog ; toute valeur non nulle inférieure à 2000 devient 2000 ms. PassiveWatchdogTimeout n’est utilisé que lorsque le kernel debugger est activé, donc sur un système ordinaire ce timer n’est pas actif même avec les 300 secondes standard. WorkerThreadTimeoutInSeconds limite le blocage d’une worker operation.

DpcCumulativeSoftTimeout a une borne inférieure de 2000 ms et ne peut pas dépasser DpcWatchdogPeriod. Pour obtenir la valeur 240000, la période du watchdog doit également être 240000. WorkerThreadTimeoutInSeconds est normalisé dans la plage 60..3600 secondes ; écrire 0 ne désactive pas le timeout, mais conduit à la valeur minimale.

Désactiver le timeout de protection supprime le diagnostic, mais ne corrige pas la cause du blocage. Pour un système de production, le watchdog fait partie du mécanisme de détection des pilotes défectueux.

Kernel Executive policy

ForceEnableMutantAutoboost se trouve dans la branche Executive, tandis que ForceIdleGracePeriod, PerfIsoEnabled, CacheIsoBitmap, SchedulerAssistThreadFlagOverride, VpThreadSystemWorkPriority et AlwaysTrackIoBoosting sont lus depuis la branche Kernel. Cette distinction est critique : une entrée de même nom dans la clé voisine ne s’applique pas.

CacheIsoBitmap n’est utilisé qu’avec le support Intel Resource Director/CAT ; sans CAT, la valeur ne crée pas d’isolation. SchedulerAssistThreadFlagOverride=0 et 1 laissent l’activation automatique, 2 désactive de force la branche. VpThreadSystemWorkPriority admet 1..31, sinon la valeur est réinitialisée à 1 ; le default est 30, et 31 n’est qu’une borne supérieure. AlwaysTrackIoBoosting=1 active des allocation et stack-capture diagnostiques sur les boost paths, et ne maintient pas la priorité I/O élevée.

Utilité : sans effet consumer confirmé, l’effet est généralement absent ou trop faible pour une décision pratique. Ces valeurs sont utiles comme objet d’un diagnostic kernel distinct, et non comme ensemble d’optimisation général.

Résultats

Les defaults vérifiés 4/3/20/20 coïncident avec l’état standard de Windows 11 25H2. Les workers supplémentaires sont égaux à zéro par défaut, la limite supérieure des kernel workers est 4096 avec une plage 32..16384. Les paramètres de watchdog sont normalisés : une valeur inférieure à 2000 ms devient 2000, et DpcCumulativeSoftTimeout ne dépasse pas la période du watchdog. Les branches Kernel et Executive ne sont pas interchangeables.

Ce qui est confirmé

• Les readers et les consommateurs des paramètres dans ntoskrnl.exe de la build étudiée.
• Les valeurs par défaut et les bornes de normalisation, y compris les dépendances entre paramètres de watchdog.
• La séparation des branches Kernel et Executive : une entrée de même nom dans la clé voisine ne s’applique pas.

Ce qui n’est pas confirmé

• L’influence de la modification des paramètres sur les FPS, la latence ou la réactivité.
• L’utilité de modifier les limites sans problème confirmé de file DPC ou de worker.

Conclusion pratique

Ne modifiez pas ces paramètres à l’aveugle : sans trace ETW/WPR, la cause du backlog ne peut pas être établie. Pour un système de travail, gardez le watchdog activé et utilisez les paramètres pour le diagnostic, et non comme ensemble d’optimisation.

Restauration de l’état

Rétablissez les valeurs standard ou supprimez les entrées facultatives. Les paramètres du noyau s’appliquent au prochain démarrage de Windows.

Sources et limites

Les readers et consumers ont été vérifiés dans ntoskrnl.exe Windows 11 25H2 build 26200.9168. Les offsets et le pseudocode ne sont pas publiés. Les métriques finales utilisateur n’ont pas été incluses dans cette série.

• DPCs and threads, Microsoft Learn, vérifié le 2026-09-01.
• Bug checks 0x133 DPC_WATCHDOG_VIOLATION, Microsoft Learn, vérifié le 2026-09-01.

Pour savoir comment reproduire la partie dynamique des observations — voir Comment vérifier soi-même.

L’étude et les outils utilisés appartiennent au développeur de BoosterX, le développeur a donc un intérêt direct aux résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus, et les conclusions peuvent être vérifiées à partir des données ouvertes et des sources publiques listées.

Sources publiques vérifiées : 2026-09-02.

Historique des modifications

• 2026-09-20: la section « Résultats » a été déplacée à sa place obligatoire avant « Restauration de l’état » ; ajout d’un avertissement sur le conflit d’intérêts et d’un lien vers la vérification autonome des observations dynamiques dans la méthodologie.
• 2026-09-02: première publication ; readers, defaults et clamps confirmés, ajout des limites d’utilité pratique.