Перейти до вмісту

MMCSS, DWM і профіль Games у Windows 11 25H2

На цій сторінці

MMCSS надає time-sensitive multimedia tasks пріоритетний доступ до CPU, не перетворюючи їх на абсолютний realtime. Профілі Window Manager і Games впливають на класифікацію лише тих потоків, які зареєстровані під відповідним іменем задачі. Видалення штатних значень не відновлює профіль: воно вмикає нижчі fallback-значення з коду.

Перевіряли, як MMCSS читає профілі Window Manager і Games, які значення діють за відсутності записів і що змінює зміна пріоритетів та lazy mode.

Windows 11 25H2 build 26200.9168, mmcss.sys і boot-time спостереження. Конкретний workload, драйвер GPU і фізична затримка не вимірювалися.

Розбір mmcss.sys, спостереження читання профілів у bootlog і перевірка нормалізації та fallback-значень.

Кореневий шлях:

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

Профіль DWM:

...\Tasks\Window Manager

Профіль ігор:

...\Tasks\Games

Value Type Window Manager в 25H2 Games в 25H2 Підтверджена роль
Scheduling Category REG_SZ Medium Medium Категорія scheduler policy
Priority REG_DWORD 5 2 Пріоритет задачі в діапазоні 1..8
Priority When Yielded REG_DWORD відсутнє, fallback 16 відсутнє, fallback 16 Стеля після поступки CPU

Значення кореневого SystemProfile:

Value Type Стан у 25H2 Підтверджена роль
LazyModeTimeout REG_DWORD відсутнє, fallback 1000000 Таймер lazy mode у 100-нс одиницях
NoLazyMode REG_DWORD відсутнє, fallback 0 Вимкнення idle detector

mmcss.sys читає Scheduling Category, Priority і Priority When Yielded під час ініціалізації профілів. Документовані активні смуги категорій: Low — 8..15, Medium — 16..22, High — 23..26. Для High значення Priority в активній смузі завжди трактується як 2, тому запис 6 або 8 не піднімає High-профіль так, як підказує число.

У чистому стані дослідженої збірки профіль Games мав Medium/2, а Window Manager — Medium/5. Priority When Yielded був відсутній в обох, тому застосовувався fallback 16. Комбінації High/6/13 і High/8/13 є зміненими конфігураціями, а не Windows defaults. Значення 13 підсилює демоцію після поступки CPU відносно fallback 16.

Корисність: профіль описує scheduler policy для класифікованих потоків. Саме підвищення категорії не доводить покращення кінцевого workload; воно може збільшити конкуренцію за CPU.

LazyModeTimeout вимірюється в 100-нс одиницях. Fallback 1000000 дорівнює 100 ms; 10000 дорівнює 1 ms. Нуль замінюється fallback, верхнього clamp у перевіреному reader немає. NoLazyMode є булевим: 0 залишає idle detector увімкненим, будь-яке ненульове значення вимикає його. При активному NoLazyMode шлях LazyModeTimeout практично недосяжний, тому ці налаштування не можна оцінювати незалежно.

Корисність: зменшення timeout прискорює період lazy scheduler, а не підвищує пріоритет активних потоків. NoLazyMode=1 прибирає idle-demotion path, але не скасовує Priority When Yielded і утримує MMCSS у повному циклі, збільшуючи фонову активність.

mmcss.sys читає root і task profiles під час старту служби/драйвера. У bootlog спостерігалися звернення до NoLazyMode і профілів; для відсутніх значень фіксувався NAME NOT FOUND, після чого застосовувався кодовий default. Це нормальний спосіб роботи Registry-конфігурації.

  • Значення Medium/5 для Window Manager і Medium/2 для Games у чистій конфігурації 25H2.
  • Fallback Low/1 за відсутності Scheduling Category і Priority, а також 16 для Priority When Yielded.
  • Межі категорій і трактування Priority для High.
  • Одиниці та fallback LazyModeTimeout, булева поведінка NoLazyMode.
  • Вплив профілів на FPS, frametime і фізичну затримку.
  • Користь зміни пріоритетів для конкретних ігор і застосунків.

Для звичайної системи зберігайте штатні Medium/5 і Medium/2. Для точного повернення не можна видаляти Scheduling Category і Priority: fallback за відсутності дорівнює Low/1, тобто профіль стане слабшим за штатний. Повернення виконується явним записом штатної пари і видаленням необов’язкового Priority When Yielded.

Результат стосується Windows 11 25H2 build 26200.9168; конкретний workload, GPU driver і фізична затримка в цій статті не вимірювалися.

Як повторити динамічну частину спостережень — див. Як перевірити самостійно.

Дослідження та використані інструменти належать розробнику BoosterX, тому в розробника є прямий інтерес до результатів. Методика та межі застосовності описані вище, а висновки можна перевірити за відкритими даними та переліченими публічними джерелами.

Публічні джерела перевірені: 2026-09-02.

  • 2026-09-20: додано дисклеймер про конфлікт інтересів і посилання на самостійну перевірку динамічних спостережень у методиці.
  • 2026-09-02: перша публікація; підтверджено читання профілів, defaults і fallback-значення, додано межі практичного ефекту.