MMCSS, DWM e profilo Games in Windows 11 25H2

Risposta breve

MMCSS concede ai time-sensitive multimedia tasks un accesso prioritario alla CPU, senza trasformarli in realtime assoluto. I profili Window Manager e Games influenzano la classificazione solo di quei thread registrati con il nome di task corrispondente. La rimozione dei valori predefiniti non ripristina il profilo: attiva valori di fallback più bassi dal codice.

Cosa è stato verificato

È stato verificato come MMCSS legge i profili Window Manager e Games, quali valori sono attivi in assenza di voci e cosa cambia modificando le priorità e la lazy mode.

Ambito della ricerca

Windows 11 25H2 build 26200.9168, mmcss.sys e osservazione al boot. Il workload specifico, il driver GPU e la latenza fisica non sono stati misurati.

Metodologia

Analisi di mmcss.sys, osservazione della lettura dei profili nel bootlog e verifica della normalizzazione e dei valori di fallback.

Percorso canonico

Percorso radice:

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

Profilo DWM:

...\Tasks\Window Manager

Profilo giochi:

...\Tasks\Games

Value	Type	Window Manager in 25H2	Games in 25H2	Ruolo confermato
Scheduling Category	REG_SZ	Medium	Medium	Categoria scheduler policy
Priority	REG_DWORD	5	2	Priorità del task nell’intervallo 1..8
Priority When Yielded	REG_DWORD	assente, fallback 16	assente, fallback 16	Tetto dopo la cessione della CPU

Valori del SystemProfile radice:

Value	Type	Stato in 25H2	Ruolo confermato
LazyModeTimeout	REG_DWORD	assente, fallback 1000000	Timer lazy mode in unità da 100 ns
NoLazyMode	REG_DWORD	assente, fallback 0	Disattivazione dell’idle detector

Profilo DWM e Games

mmcss.sys legge Scheduling Category, Priority e Priority When Yielded durante l’inizializzazione dei profili. Bande di categorie attive documentate: Low — 8..15, Medium — 16..22, High — 23..26. Per High il valore Priority nella banda attiva viene sempre interpretato come 2, quindi la voce 6 o 8 non eleva il profilo High come suggerirebbe il numero.

Allo stato pulito della build esaminata il profilo Games aveva Medium/2, mentre Window Manager — Medium/5. Priority When Yielded era assente in entrambi, quindi si applicava il fallback 16. Le combinazioni High/6/13 e High/8/13 sono configurazioni modificate, non Windows defaults. Il valore 13 rafforza la demozione dopo la cessione della CPU rispetto al fallback 16.

Utilità: il profilo descrive la scheduler policy per i thread classificati. L’aumento della categoria di per sé non dimostra un miglioramento del workload finale; può aumentare la competizione per la CPU.

LazyModeTimeout e NoLazyMode

LazyModeTimeout è misurato in unità da 100 ns. Il fallback 1000000 è pari a 100 ms; 10000 è pari a 1 ms. Lo zero viene sostituito dal fallback, nel reader verificato non esiste un clamp superiore. NoLazyMode è booleano: 0 lascia l’idle detector attivo, qualsiasi valore diverso da zero lo disattiva. Con NoLazyMode attivo il percorso LazyModeTimeout è praticamente irraggiungibile, quindi queste impostazioni non possono essere valutate in modo indipendente.

Utilità: ridurre il timeout accelera il periodo del lazy scheduler, non aumenta la priorità dei thread attivi. NoLazyMode=1 elimina l’idle-demotion path, ma non annulla Priority When Yielded e mantiene MMCSS in un ciclo completo, aumentando l’attività in background.

Timing e prove

mmcss.sys legge root e task profiles all’avvio del servizio/driver. Nel bootlog sono stati osservati accessi a NoLazyMode e ai profili; per i valori assenti veniva registrato NAME NOT FOUND, dopodiché si applicava il default del codice. Questo è il normale funzionamento della configurazione del Registry.

Cosa è confermato

• I valori Medium/5 per Window Manager e Medium/2 per Games nella configurazione pulita di 25H2.
• Il fallback Low/1 in assenza di Scheduling Category e Priority, nonché 16 per Priority When Yielded.
• I confini delle categorie e l’interpretazione di Priority per High.
• Le unità e il fallback LazyModeTimeout, il comportamento booleano di NoLazyMode.

Cosa non è confermato

• L’influenza dei profili su FPS, frametime e latenza fisica.
• L’utilità della modifica delle priorità per giochi e applicazioni specifici.

Conclusione pratica

Per un sistema normale conservare i Medium/5 e Medium/2 predefiniti. Per un ripristino preciso non si possono eliminare Scheduling Category e Priority: il fallback in assenza è pari a Low/1, cioè il profilo diventerà più debole di quello predefinito. Il ripristino si esegue scrivendo esplicitamente la coppia predefinita e rimuovendo l’opzionale Priority When Yielded.

Fonti e limitazioni

• Multimedia Class Scheduler Service, Microsoft Learn, verificato il 2026-09-01.
• MMCSS task profiles, descrizione di task categories e SystemProfile.

Il risultato si riferisce a Windows 11 25H2 build 26200.9168; il workload specifico, il GPU driver e la latenza fisica non sono stati misurati in questo articolo.

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

La ricerca e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, quindi 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: aggiunto il disclaimer sul conflitto di interessi e il link alla verifica autonoma delle osservazioni dinamiche nella metodologia.
• 2026-09-02: prima pubblicazione; confermati la lettura dei profili, i defaults e i valori di fallback, aggiunti i limiti dell’effetto pratico.