Så här inaktiverar du Cross-Device Resume

Kort svar

Cross-Device Resume kan stängas av via MDM-principen i Windows. I vårt experiment startade CrossDeviceResume.exe inte under 153 sekunders observation efter att den tillämpats, datorn startats om och inloggning skett. När funktionen tilläts igen och datorn startades om på nytt dök processen upp igen.

Det är enklare att tillämpa inställningen via BoosterX → Optimering → Tweaks → Cross-Device Resume: välj avstängning, klicka på “Tillämpa” och starta om datorn. Den här undersökningen testade en offentlig mekanism i Windows, inte BoosterX implementering: hur programmet faktiskt tillämpar inställningen testades inte i den här serien och påstås inte i artikeln. Detaljer om tillämpning och återställning finns på inställningssidan.

Vad som testades

Vi var inte bara intresserade av att Resume-aviseringarna försvann, utan också av att förhindra den ordinarie starten av dess separata process vid inloggning i Windows. Det är olika resultat: programmet kan starta och omedelbart avslutas, fortsätta köra utan aviseringar eller inte få någon startbegäran alls.

Microsoft beskriver DisableCrossDeviceResume som en användarprincip som stänger av aviseringar om att fortsätta arbetet från telefonen, och anger att en omstart krävs. Dokumenterat: principens syfte och när den tillämpas. Observerat i vårt experiment: att den separata processen inte startade. Microsofts beskrivning.

Undersökningens omfattning

Villkor	Testad miljö
System	Windows 11 Pro 25H2, build 26200.9445
Komponent	CrossDeviceResume 2607.27000.0.0
Testbänk	En virtuell VMware-maskin
Scenario	Omstart och interaktiv inloggning av samma användare
Observation	Processlista och granskning av deras skapande, händelse 4688
Experimentdatum	2026-09-17

Detta är ett funktionellt experiment, inte ett test av FPS eller minnesförbrukning. Modell för fysisk CPU, konfiguration av virtuella resurser och drivrutinsversioner ingår inte i det publicerade urvalet. Resultatet kan inte överföras till fysiska datorer, andra builds eller andra startmetoder utan verifiering.

Hur testet genomfördes

Först registrerades den körande processen och principens ursprungliga tillstånd. Därefter tillämpades den förbjudande principen via Windows lokala hanteringsmekanism, operationens framgång verifierades och tillståndet lästes tillbaka. Efter omstarten inväntades interaktiv inloggning och att skalet började köra, och processerna samt deras skapandelogg kontrollerades.

För omvänd kontroll tilläts Resume och omstarten med inloggning upprepades. Separat förbjöds funktionen igen, den redan körande processen avslutades uttryckligen och en eventuell ny start observerades. Avslutningen av processen var en självständig åtgärd och kan inte tillskrivas principen.

Varför en registerpost ännu inte bevisar avstängning

Att det önskade värdet finns i registret bekräftar inte att Windows har accepterat det som en gällande MDM-princip. Därför motsäger situationen “värdet är skrivet, men CrossDeviceResume startar ändå” inte resultatet av den här undersökningen.

I den publicerade dokumentationen för denna princip finns ingen färdig motsvarighet till en vanlig Registry-inställning. I vår serie finns ingen separat kontrollerad jämförelse av alla varianter av direkt skrivning. Direkt skrivning är inte bekräftad som ersättning för att tillämpa principen, men det finns inte heller grund för att påstå att varje registerändring alltid är värdelös. Det fungerande resultatet erhölls via principhanteringsmekanismen, med verifiering av tillståndet och den faktiska starten efter inloggning.

System-DLL:ens roll och laboratoriets kringgående

I experimentet användes den inbyggda mdmlocalmanagement.dll. Den tillhandahåller gränssnittet för lokal hantering: RegisterDeviceWithLocalManagement och ApplyLocalManagementSyncML. Deras deklarationer finns i den offentliga headern i Windows SDK. Systembiblioteket tog emot begäran om att tillämpa principen; det behövdes inte att ladda ner tredjeparts-DLL:er, ersätta Windows-filer eller patcha körbar kod. Intune och molnhantering användes inte i försöket.

Vanlig lokal registrering på den testade Windows Pro returnerade “stöds inte”. I laboratoriet gick det att passera denna begränsning genom att tillfälligt aktivera Embedded Mode, varefter principen kunde tillämpas och lägets ursprungliga parameter återställas. Microsoft beskriver Embedded Mode i kontexten specialiserade enheter Windows IoT. Sådan användning på Pro är inte ett av Microsoft bekräftat supportscenario.

Återställningen av det tillfälliga läget tog inte bort den lokala hanteringsregistreringen och den tilldelade principen. Biverkningar av att tillfälligt aktivera läget utanför det testade scenariot undersöktes inte. Här beskrivs experimentets princip; kommandon, begärans innehåll och reproduktionssekvensen för kringgåendet publiceras inte.

Resultat

Kontroll	Resultat och slutsatsens gräns
Tillämpning av den förbjudande principen	Operationen lyckades, tillbakaläsningen bekräftade tillståndet
Redan körande process	Avslutades inte automatiskt
Omstart och inloggning med förbud	Processen saknades; under 153 sekunder efter skalets start registrerades inga starter av den
Tillåtelse, omstart och inloggning	Processen dök upp, skapandet bekräftades av loggen
Upprepat förbud och separat avslutning av processen	Efter 10 sekunder saknades processen; ingen ny start upptäcktes under 120 sekunders observation
Fullständig återställning av testbänken	Ursprungligt tillstånd återställdes med VM-snapshot och verifierades

I urvalet finns en VM och en sekvens av kontroller. Upprepade observationer inom 120-sekundersintervallet är inte oberoende experiment. Det finns ingen oberoende reproduktion på en andra dator.

Vad som bekräftats

• I det testade scenariot förhindrade principen den ordinarie starten av den separata processen efter omstart och inloggning.
• Att tillåta funktionen igen återställde starten på samma testbänk.
• Att tillämpa principen stänger i sig inte en redan körande process.
• För det erhållna resultatet krävdes ingen ersättning av system-DLL:er eller patchning av EXE.

Den förhindrade starten utesluter att denna process körs i det observerade scenariot. Det är en konkret effekt av att stänga av en onödig bakgrundsfunktion, även utan mätning av FPS.

Vad som inte bekräftats

Ökning av FPS, förändring av frametime, total CPU-belastning och RAM-besparing har inte mätts. Manuell start av EXE, alla alternativa aktiveringssätt, placering av Resume inuti ShellHost och körning från ett annat konto eller SYSTEM har inte testats. Det fanns inget separat parat test av tillämpning via BoosterX färdiga gränssnitt i den här serien: tabellen beskriver laboratoriets Windows-mekanism.

Begränsningar

Vid testdatumet märker Microsoft principen som tillämplig på Windows Insider Preview. Observationen på den angivna Windows 11 Pro 25H2 ersätter inte den officiella supportmatrisen. Testet på en annan planerad VM genomfördes inte, därför finns inga resultat för den. Att inga händelser finns under 153 sekunder betyder inte att alla starter är förbjudna för alltid: den bekräftade effekten gäller den ordinarie starten efter omstart och inloggning, och start av processen på andra sätt har denna undersökning inte studerat.

Artikeln fastställer inte på vilket sätt BoosterX tillämpar sin inställning. Sambandet mellan BoosterX kort och den MDM-princip som testats här ingick inte i experimentplanen; en bedömning av huruvida programmet använder samma mekanism kräver en separat verifiering utifrån applikationens faktiska beteende.

Avstängningen gäller Resume. Den kan inte beskrivas som avstängning av hela “Länkning till telefonen” eller hela Windows infrastruktur för mellan enheter.

Praktisk slutsats

Om du inte använder fortsatt arbete från telefonen är det motiverat att stänga av Resume. På den testade testbänken gjorde MDM-principen att dess ordinarie start kunde undvikas. För användaren är det enklare att välja den befintliga inställningen i BoosterX och starta om datorn än att manuellt experimentera med principarkivet. Verifiera resultatet på din Windows-version.

Återställning av tillståndet

I experimentet återställde tillåtelse av funktionen och en ny omstart starten av processen. Därefter återställdes VM:en helt från den ursprungliga snapshoten: frånvaron av principen som tilldelats under testet, lägets ursprungliga tillstånd, upphävandet av den tillfälliga automatiska inloggningen och processens återkomst verifierades.

I BoosterX tillåter aktivering i samma kort Resume efter tillämpning och omstart. Det är inte en fullständig motsvarighet till återställning av en snapshot: den lokala hanteringsregistreringen som skapades av laboratoriets tillämpning av principen finns kvar, liksom tidigare tillämpade begränsningar från andra verktyg. Detaljer om återställning finns på inställningssidan.

Offentliga primärkällor

• Microsoft: Connectivity / DisableCrossDeviceResume: principens syfte, användaromfattning och omstart; inte bevis för resultaten på vår VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: deklarationer för gränssnittet för lokal hantering; inte ett löfte om tillgänglighet i alla utgåvor.
• Microsoft: Embedded Mode: kontext för Windows IoT; inte en instruktion för supportad användning på Pro.

Undersökningen och de använda verktygen tillhör utvecklaren av BoosterX, därför har utvecklaren ett direkt intresse av resultaten. Metodiken och gränserna för tillämplighet beskrivs ovan, och slutsatserna kan verifieras mot öppna data och de angivna offentliga källorna. Microsoft är inte författare till undersökningen och har inte bekräftat dess slutsatser.

Testdatum och ändringshistorik

2026-09-17: första versionen; offentliga källor verifierades, resultat publicerades för en VM, slutsatsens gränser och den omvända kontrollen av starten.

2026-09-19: efter en oberoende granskning korrigerades slutsatsens ramverk: påståendet om en specifik mekanism i BoosterX togs bort. Undersökningen testar den offentliga MDM-principen i Windows och laboratoriets väg för att tillämpa den, inte implementeringen av inställningen i programmet; experimentets resultat, slutsatsens gränser och källor bevarades, och förbehållen om gränserna för den bekräftade effekten preciserades.

2026-09-20: ansvarsfriskrivningen om intressekonflikt förstärktes: utvecklarens direkta intresse, som äger undersökningen och verktygen, erkänns uttryckligen; description kortades.