Come disattivare Cross-Device Resume

Risposta breve

Cross-Device Resume può essere disattivato tramite i criteri MDM di Windows. Nel nostro esperimento, dopo la sua applicazione, un riavvio e l’accesso, CrossDeviceResume.exe non si è avviato per 153 secondi di osservazione. Riabilitando la funzione e riavviando di nuovo, il processo è ricomparso.

È più semplice applicare l’impostazione tramite BoosterX → Ottimizzazione → Tweaks → Cross-Device Resume: selezionare la disattivazione, premere «Applica» e riavviare il PC. Questo studio verificava un meccanismo pubblico di Windows, non l’implementazione di BoosterX: come il programma applichi esattamente l’impostazione non è stato testato in questa serie e non viene affermato nell’articolo. I dettagli sull’applicazione e sul ripristino sono disponibili sulla pagina dell’impostazione.

Cosa è stato verificato

Ci interessava non solo la scomparsa delle notifiche Resume, ma anche la prevenzione dell’avvio standard del suo processo separato all’accesso in Windows. Sono risultati diversi: il programma può avviarsi e terminare subito, continuare a funzionare senza notifiche oppure non ricevere affatto una richiesta di avvio.

Microsoft descrive DisableCrossDeviceResume come criterio utente che disattiva le notifiche di continuazione del lavoro dal telefono, e indica la necessità di un riavvio. Documentato: lo scopo del criterio e il momento dell’applicazione. Osservato nel nostro esperimento: l’assenza dell’avvio del processo separato. Descrizione Microsoft.

Ambito dello studio

Condizione	Ambiente verificato
Sistema	Windows 11 Pro 25H2, build 26200.9445
Componente	CrossDeviceResume 2607.27000.0.0
Banco di prova	Una macchina virtuale VMware
Scenario	Riavvio e accesso interattivo dello stesso utente
Osservazione	Elenco dei processi e audit della loro creazione, eventi 4688
Data dell’esperimento	2026-09-17

Questo è un esperimento funzionale, non un test di FPS o di consumo di memoria. Il modello della CPU fisica, la configurazione delle risorse virtuali e le versioni dei driver non sono inclusi nel campione pubblicato. Non si può trasferire il risultato a PC fisici, ad altre build o ad altri metodi di avvio senza verifica.

Come è stata condotta la verifica

Inizialmente sono stati registrati il processo in esecuzione e lo stato iniziale del criterio. Poi è stato applicato il criterio di divieto tramite il meccanismo locale di gestione di Windows, è stata verificata la riuscita dell’operazione e lo stato è stato riletto. Dopo il riavvio si è atteso l’accesso interattivo e l’avvio della shell, quindi sono stati controllati i processi e il registro della loro creazione.

Per il controllo inverso è stato consentito Resume e si è ripetuto il riavvio con accesso. Separatamente la funzione è stata nuovamente vietata, il processo già in esecuzione è stato terminato esplicitamente e si è osservato un possibile riavvio. La terminazione del processo è stata un’azione autonoma, non può essere attribuita al criterio.

Perché una voce nel registro non prova ancora la disattivazione

La presenza del valore necessario nel registro non conferma che Windows lo abbia accettato come criterio MDM attivo. Perciò la situazione «il valore è scritto, ma CrossDeviceResume si avvia comunque» non contraddice il risultato di questo studio.

Nella documentazione pubblicata di questo criterio non esiste una corrispondenza pronta con un’impostazione ordinaria del Registry. Nella nostra serie non c’è un confronto controllato separato di tutte le varianti di scrittura diretta. La scrittura diretta non è confermata come sostituto dell’applicazione del criterio, ma non ci sono nemmeno basi per affermare che qualsiasi modifica del registro sia sempre inutile. Il risultato operativo è stato ottenuto tramite il meccanismo di gestione dei criteri, con verifica dello stato e dell’avvio effettivo dopo l’accesso.

Il ruolo della DLL di sistema e dell’aggiramento di laboratorio

Nell’esperimento è stata utilizzata la mdmlocalmanagement.dll integrata. Essa fornisce l’interfaccia di gestione locale: RegisterDeviceWithLocalManagement e ApplyLocalManagementSyncML. Le loro dichiarazioni sono disponibili nel header pubblico di Windows SDK. La libreria di sistema accettava la richiesta di applicazione del criterio; non è stato necessario scaricare DLL di terze parti, sostituire file di Windows o applicare patch al codice eseguibile. Intune e la gestione cloud non sono stati utilizzati nell’esperimento.

La normale registrazione locale sulla Windows Pro verificata ha restituito «non supportato». In laboratorio è stato possibile superare questa limitazione attivando temporaneamente Embedded Mode, dopodiché applicare il criterio e ripristinare il parametro originale della modalità. Microsoft descrive Embedded Mode nel contesto di dispositivi specializzati Windows IoT. Tale utilizzo su Pro non è uno scenario di supporto confermato da Microsoft.

Il ripristino della modalità temporanea non ha rimosso la registrazione locale della gestione e il criterio assegnato. Gli effetti collaterali dell’attivazione temporanea della modalità al di fuori dello scenario verificato non sono stati studiati. Qui è descritto il principio dell’esperimento; i comandi, il contenuto della richiesta e la sequenza di riproduzione dell’aggiramento non vengono pubblicati.

Risultati

Verifica	Risultato e limite della conclusione
Applicazione del criterio di divieto	Operazione riuscita, la rilettura ha confermato lo stato
Processo già in esecuzione	Non si è terminato automaticamente
Riavvio e accesso con divieto	Processo assente; nei 153 secondi dopo l’avvio della shell non è stato registrato alcun suo avvio
Autorizzazione, riavvio e accesso	Il processo è comparso, la creazione è confermata dal registro
Nuovo divieto e terminazione separata del processo	Dopo 10 secondi il processo era assente; nei 120 secondi di osservazione non è stato rilevato alcun riavvio
Ripristino completo del banco di prova	Lo stato iniziale è stato ripristinato con un’immagine VM e verificato

Nel campione ci sono una VM e una sequenza di verifiche. Le osservazioni ripetute all’interno dell’intervallo di 120 secondi non sono esperimenti indipendenti. Non esiste una riproduzione indipendente su un secondo computer.

Cosa è confermato

• Nello scenario verificato il criterio ha impedito l’avvio standard del processo separato dopo il riavvio e l’accesso.
• La riabilitazione della funzione ha ripristinato l’avvio sullo stesso banco di prova.
• L’applicazione del criterio di per sé non chiude un processo già in esecuzione.
• Per il risultato ottenuto non sono stati necessari la sostituzione di DLL di sistema o una patch all’EXE.

L’avvio impedito esclude il funzionamento di questo processo nello scenario osservato. È un effetto concreto della disattivazione di una funzione in background non necessaria, anche senza misurazione degli FPS.

Cosa non è confermato

Non sono stati misurati l’aumento degli FPS, la variazione del frametime, il carico complessivo della CPU e il risparmio di RAM. Non sono stati verificati l’avvio manuale dell’EXE, tutti i metodi alternativi di attivazione, la collocazione di Resume all’interno di ShellHost e il funzionamento da un altro account o da SYSTEM. Non c’è stato un test appaiato separato dell’applicazione tramite l’interfaccia pronta di BoosterX in questa serie: la tabella descrive il meccanismo di laboratorio di Windows.

Limitazioni

Alla data della verifica Microsoft contrassegna il criterio come applicabile a Windows Insider Preview. L’osservazione sulla suddetta Windows 11 Pro 25H2 non sostituisce la matrice di supporto ufficiale. La verifica su un’altra VM prevista non ha avuto luogo, quindi non ci sono risultati per essa. L’assenza di eventi per 153 secondi non significa divieto di qualsiasi avvio per sempre: l’effetto confermato riguarda l’avvio standard dopo il riavvio e l’accesso, mentre l’avvio del processo con altri metodi non è stato studiato da questa ricerca.

L’articolo non stabilisce in quale modo BoosterX applichi la sua impostazione. Il legame tra la scheda di BoosterX e il criterio MDM verificato qui non rientrava nel piano dell’esperimento; un giudizio sul fatto che il programma utilizzi questo stesso meccanismo richiede una verifica separata basata sul comportamento effettivo dell’applicazione.

La disattivazione riguarda Resume. Non può essere descritta come disattivazione dell’intera «Connessione al telefono» o dell’intera infrastruttura multi-dispositivo di Windows.

Conclusione pratica

Se non utilizzate la continuazione del lavoro dal telefono, disattivare Resume è giustificato. Sul banco di prova verificato il criterio MDM ha permesso di evitare il suo avvio standard. Per l’utente è più semplice selezionare l’impostazione esistente in BoosterX e riavviare il PC, piuttosto che sperimentare manualmente con l’archivio dei criteri. Verificate il risultato sulla vostra versione di Windows.

Ripristino dello stato

Nell’esperimento l’autorizzazione della funzione e un nuovo riavvio hanno ripristinato l’avvio del processo. Poi la VM è stata ripristinata completamente dall’immagine iniziale: sono stati verificati l’assenza del criterio assegnato durante la verifica, lo stato iniziale della modalità, l’annullamento dell’accesso automatico temporaneo e il ritorno del processo.

In BoosterX l’attivazione nella stessa scheda consente Resume dopo l’applicazione e il riavvio. Non è un analogo completo del ripristino da immagine: la registrazione locale della gestione, creata dall’applicazione di laboratorio del criterio, rimane, come le restrizioni precedentemente applicate da altri strumenti. I dettagli sul ripristino sono indicati sulla pagina dell’impostazione.

Fonti primarie pubbliche

• Microsoft: Connectivity / DisableCrossDeviceResume: scopo del criterio, ambito utente e riavvio; non è una prova dei risultati della nostra VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: dichiarazioni dell’interfaccia di gestione locale; non è una promessa di disponibilità su qualsiasi edizione.
• Microsoft: Embedded Mode: contesto di Windows IoT; non è un’istruzione per un’applicazione supportata su Pro.

La ricerca e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, pertanto 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. Microsoft non è l’autore della ricerca e non ha confermato le sue conclusioni.

Data della verifica e cronologia delle modifiche

2026-09-17: prima versione; verificate le fonti pubbliche, pubblicati i risultati di una VM, i limiti della conclusione e la verifica inversa dell’avvio.

2026-09-19: dopo una verifica indipendente è stata corretta l’impostazione della conclusione: rimossa l’affermazione su un meccanismo specifico di BoosterX. La ricerca verifica il criterio MDM pubblico di Windows e il percorso di laboratorio per la sua applicazione, non l’implementazione dell’impostazione nel programma; i risultati dell’esperimento, i limiti della conclusione e le fonti sono conservati, sono state precisate le avvertenze sui limiti dell’effetto confermato.

2026-09-20: il disclaimer sul conflitto di interessi è stato rafforzato: è stato riconosciuto esplicitamente il diretto interesse dello sviluppatore, a cui appartengono la ricerca e gli strumenti; description abbreviata.