Przejdź do głównej zawartości

MMCSS, DWM i profil Games w Windows 11 25H2

Na tej stronie

MMCSS daje time-sensitive multimedia tasks priorytetowy dostęp do CPU, nie zamieniając ich w absolutny realtime. Profile Window Manager i Games wpływają na klasyfikację tylko tych wątków, które są zarejestrowane pod odpowiednią nazwą zadania. Usunięcie standardowych wartości nie przywraca profilu: włącza niższe fallback-значения z kodu.

Sprawdzano, jak MMCSS odczytuje profile Window Manager i Games, jakie wartości działają przy braku wpisów i co zmienia zmiana priorytetów oraz lazy mode.

Windows 11 25H2 build 26200.9168, mmcss.sys i boot-time obserwacja. Konkretny workload, sterownik GPU i fizyczne opóźnienie nie były mierzone.

Analiza mmcss.sys, obserwacja odczytu profili w bootlogu oraz weryfikacja normalizacji i fallback-значений.

Ścieżka główna:

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

Profil DWM:

...\Tasks\Window Manager

Profil gier:

...\Tasks\Games

Value Type Window Manager w 25H2 Games w 25H2 Potwierdzona rola
Scheduling Category REG_SZ Medium Medium Kategoria scheduler policy
Priority REG_DWORD 5 2 Priorytet zadania w zakresie 1..8
Priority When Yielded REG_DWORD brak, fallback 16 brak, fallback 16 Pułap po ustąpieniu CPU

Wartości głównego SystemProfile:

Value Type Stan w 25H2 Potwierdzona rola
LazyModeTimeout REG_DWORD brak, fallback 1000000 Timer lazy mode w jednostkach 100 ns
NoLazyMode REG_DWORD brak, fallback 0 Wyłączenie idle detector

mmcss.sys odczytuje Scheduling Category, Priority i Priority When Yielded przy inicjalizacji profili. Udokumentowane aktywne pasma kategorii: Low — 8..15, Medium — 16..22, High — 23..26. Dla High wartość Priority w aktywnym paśmie jest zawsze traktowana jako 2, dlatego wpis 6 lub 8 nie podnosi High-профиля tak, jak podpowiada liczba.

W czystym stanie badanej kompilacji profil Games miał Medium/2, a Window Manager — Medium/5. Priority When Yielded był nieobecny u obu, dlatego stosowano fallback 16. Kombinacje High/6/13 i High/8/13 są zmienionymi konfiguracjami, a nie Windows defaults. Wartość 13 wzmacnia democję po ustąpieniu CPU względem fallback 16.

Przydatność: profil opisuje scheduler policy dla sklasyfikowanych wątków. Samo podniesienie kategorii nie dowodzi poprawy końcowego workload; może zwiększyć konkurencję o CPU.

LazyModeTimeout jest mierzony w jednostkach 100 ns. Fallback 1000000 wynosi 100 ms; 10000 wynosi 1 ms. Zero jest zastępowane fallback, górnego clamp w sprawdzonym reader nie ma. NoLazyMode jest wartością logiczną: 0 pozostawia idle detector włączony, każda niezerowa wartość go wyłącza. Przy aktywnym NoLazyMode ścieżka LazyModeTimeout jest praktycznie nieosiągalna, dlatego tych ustawień nie można oceniać niezależnie.

Przydatność: zmniejszenie timeout przyspiesza okres lazy scheduler, a nie podnosi priorytet aktywnych wątków. NoLazyMode=1 usuwa idle-demotion path, ale nie anuluje Priority When Yielded i utrzymuje MMCSS w pełnym cyklu, zwiększając aktywność w tle.

mmcss.sys odczytuje root i task profiles przy starcie usługi/sterownika. W bootlogu obserwowano odwołania do NoLazyMode i profili; dla brakujących wartości rejestrowano NAME NOT FOUND, po czym stosowano kodowy default. To normalny sposób działania konfiguracji Registry.

  • Wartości Medium/5 dla Window Manager i Medium/2 dla Games w czystej konfiguracji 25H2.
  • Fallback Low/1 przy braku Scheduling Category i Priority, a także 16 dla Priority When Yielded.
  • Granice kategorii i interpretacja Priority dla High.
  • Jednostki i fallback LazyModeTimeout, logiczne zachowanie NoLazyMode.
  • Wpływ profili na FPS, frametime i fizyczne opóźnienie.
  • Korzyść ze zmiany priorytetów dla konkretnych gier i aplikacji.

Dla zwykłego systemu zachowaj standardowe Medium/5 i Medium/2. Dla dokładnego przywrócenia nie można usuwać Scheduling Category i Priority: fallback przy braku wynosi Low/1, czyli profil stanie się słabszy od standardowego. Przywrócenie wykonuje się jawnym zapisem standardowej pary i usunięciem opcjonalnego Priority When Yielded.

Wynik dotyczy Windows 11 25H2 build 26200.9168; konkretny workload, GPU driver i fizyczne opóźnienie w tym artykule nie były mierzone.

Jak powtórzyć dynamiczną część obserwacji — zobacz Jak sprawdzić samodzielnie.

Badanie i użyte narzędzia należą do dewelopera BoosterX, dlatego deweloper ma bezpośredni interes w wynikach. Metodyka i granice stosowalności opisano powyżej, a wnioski można zweryfikować na podstawie otwartych danych i wymienionych publicznych źródeł.

Publiczne źródła sprawdzono: 2026-09-02.

  • 2026-09-20: dodano disclaimer o konflikcie interesów i link do samodzielnej weryfikacji dynamicznych obserwacji w metodyce.
  • 2026-09-02: pierwsza publikacja; potwierdzono odczyt profili, defaults i fallback-значения, dodano granice praktycznego efektu.