Přeskočit na obsah

MMCSS, DWM a profil Games v Windows 11 25H2

Na této stránce

MMCSS dává time-sensitive multimedia tasks přednostní přístup k CPU, aniž by je měnil na absolutní realtime. Profily Window Manager a Games ovlivňují klasifikaci pouze těch vláken, která jsou zaregistrována pod odpovídajícím názvem úlohy. Odstranění standardních hodnot profil neobnoví: aktivuje nižší fallback hodnoty z kódu.

Testovalo se, jak MMCSS čte profily Window Manager a Games, které hodnoty platí při absenci záznamů a co mění změna priorit a lazy mode.

Windows 11 25H2 build 26200.9168, mmcss.sys a boot-time sledování. Konkrétní workload, ovladač GPU a fyzická latence se neměřily.

Rozbor mmcss.sys, sledování čtení profilů v bootlogu a ověření normalizace a fallback hodnot.

Kořenová cesta:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile

Profil DWM:

...\Tasks\Window Manager

Profil her:

...\Tasks\Games

Value Type Window Manager v 25H2 Games v 25H2 Potvrzená role
Scheduling Category REG_SZ Medium Medium Kategorie scheduler policy
Priority REG_DWORD 5 2 Priorita úlohy v rozsahu 1..8
Priority When Yielded REG_DWORD chybí, fallback 16 chybí, fallback 16 Strop po ustoupení CPU

Hodnoty kořenového SystemProfile:

Value Type Stav v 25H2 Potvrzená role
LazyModeTimeout REG_DWORD chybí, fallback 1000000 Časovač lazy mode ve 100-ns jednotkách
NoLazyMode REG_DWORD chybí, fallback 0 Vypnutí idle detector

mmcss.sys čte Scheduling Category, Priority a Priority When Yielded při inicializaci profilů. Dokumentované aktivní pásma kategorií: Low — 8..15, Medium — 16..22, High — 23..26. Pro High se hodnota Priority v aktivním pásmu vždy interpretuje jako 2, proto záznam 6 nebo 8 nezvedá High-profil tak, jak napovídá číslo.

V čistém stavu zkoumaného buildu měl profil Games hodnotu Medium/2, a Window Manager — Medium/5. Priority When Yielded chyběl u obou, proto se použil fallback 16. Kombinace High/6/13 a High/8/13 jsou změněné konfigurace, nikoli Windows defaults. Hodnota 13 zesiluje democi po ustoupení CPU vůči fallback 16.

Užitečnost: profil popisuje scheduler policy pro klasifikovaná vlákna. Samotné zvýšení kategorie nedokazuje zlepšení konečného workloadu; může zvýšit konkurenci o CPU.

LazyModeTimeout a NoLazyMode

Sekce “LazyModeTimeout a NoLazyMode”

LazyModeTimeout se měří ve 100-ns jednotkách. Fallback 1000000 je 100 ms; 10000 je 1 ms. Nula se nahrazuje fallbackem, horní clamp v ověřeném readeru není. NoLazyMode je booleovský: 0 ponechává idle detector zapnutý, jakákoli nenulová hodnota jej vypíná. Při aktivním NoLazyMode je cesta LazyModeTimeout prakticky nedosažitelná, proto tyto nastavení nelze hodnotit nezávisle.

Užitečnost: zkrácení timeoutu zrychluje periodu lazy scheduleru, nikoli zvyšuje prioritu aktivních vláken. NoLazyMode=1 odstraňuje idle-demotion path, ale neruší Priority When Yielded a udržuje MMCSS v plném cyklu, čímž zvyšuje aktivitu na pozadí.

mmcss.sys čte root a task profiles při startu služby/ovladače. V bootlogu byly pozorovány přístupy k NoLazyMode a profilům; pro chybějící hodnoty se zaznamenával NAME NOT FOUND, načež se použil kódový default. To je normální způsob fungování Registry-konfigurace.

  • Hodnoty Medium/5 pro Window Manager a Medium/2 pro Games v čisté konfiguraci 25H2.
  • Fallback Low/1 při absenci Scheduling Category a Priority, a také 16 pro Priority When Yielded.
  • Hranice kategorií a interpretace Priority pro High.
  • Jednotky a fallback LazyModeTimeout, booleovské chování NoLazyMode.
  • Vliv profilů na FPS, frametime a fyzickou latenci.
  • Přínos změny priorit pro konkrétní hry a aplikace.

Pro běžný systém zachovejte standardní Medium/5 a Medium/2. Pro přesný návrat nelze odstranit Scheduling Category a Priority: fallback při absenci je roven Low/1, tedy profil bude slabší než standardní. Návrat se provádí explicitním zápisem standardní dvojice a odstraněním volitelného Priority When Yielded.

Výsledek se vztahuje k Windows 11 25H2 build 26200.9168; konkrétní workload, GPU driver a fyzická latence se v tomto článku neměřily.

Jak zopakovat dynamickou část pozorování — viz Jak ověřit samostatně.

Výzkum a použité nástroje patří vývojáři BoosterX, proto má vývojář přímý zájem na výsledcích. Metodika a hranice použitelnosti jsou popsány výše a závěry lze ověřit podle otevřených dat a uvedených veřejných zdrojů.

Veřejné zdroje ověřeny: 2026-09-02.

  • 2026-09-20: přidán disclaimer o konfliktu zájmů a odkaz na samostatné ověření dynamických pozorování v metodice.
  • 2026-09-02: první publikace; potvrzeno čtení profilů, defaults a fallback hodnoty, přidány hranice praktického efektu.