Sådan deaktiveres Cross-Device Resume

Kort svar

Cross-Device Resume kan deaktiveres via MDM-politikken i Windows. I vores eksperiment blev CrossDeviceResume.exe efter anvendelse af den, genstart og login ikke startet i 153 sekunders observation. Da funktionen blev tilladt igen, og der blev genstartet igen, optrådte processen atter.

Det er nemmere at anvende indstillingen via BoosterX → Optimering → Tweaks → Cross-Device Resume: vælg deaktivering, tryk på «Anvend» og genstart pc’en. Denne undersøgelse testede en offentlig Windows-mekanisme, ikke BoosterX’ implementering: hvordan programmet helt præcist anvender indstillingen, blev ikke testet i denne serie og påstås ikke i artiklen. Detaljer om anvendelse og tilbageføring findes på indstillingssiden.

Hvad vi undersøgte

Vi var ikke kun interesserede i, at Resume-notifikationer forsvandt, men også i at forhindre den normale start af dens separate proces ved login i Windows. Det er forskellige resultater: programmet kan starte og straks afslutte, fortsætte med at køre uden notifikationer eller slet ikke modtage en startanmodning.

Microsoft beskriver DisableCrossDeviceResume som en brugerpolitik, der deaktiverer notifikationer om fortsat arbejde fra telefonen, og angiver, at genstart er nødvendig. Dokumenteret: politikens formål og anvendelsestidspunkt. Observeret i vores eksperiment: at den separate proces ikke startede. Microsofts beskrivelse.

Undersøgelsens omfang

Betingelse	Testet miljø
System	Windows 11 Pro 25H2, build 26200.9445
Komponent	CrossDeviceResume 2607.27000.0.0
Testopsætning	Én virtuel VMware-maskine
Scenarie	Genstart og interaktivt login for samme bruger
Observation	Procesliste og revision af deres oprettelse, hændelse 4688
Eksperimentdato	2026-09-17

Dette er et funktionelt eksperiment, ikke en test af FPS eller hukommelsesforbrug. Modellen for den fysiske CPU, konfigurationen af virtuelle ressourcer og driverversioner er ikke inkluderet i den offentliggjorte stikprøve. Resultatet kan ikke overføres til fysiske pc’er, andre builds eller andre startmetoder uden verifikation.

Sådan udførte vi testen

Først registrerede vi den kørende proces og politikens oprindelige tilstand. Derefter anvendte vi den forbydende politik via Windows’ lokale styringsmekanisme, kontrollerede, at operationen lykkedes, og læste tilstanden tilbage. Efter genstart afventede vi interaktivt login og start af shell, kontrollerede processer og loggen over deres oprettelse.

Til den omvendte kontrol tillod vi Resume og gentog genstart med login. Separat forbød vi funktionen igen, afsluttede eksplicit den allerede kørende proces og observerede en mulig genstart. Afslutningen af processen var en selvstændig handling og kan ikke tilskrives politikken.

Hvorfor en registreringspost ikke i sig selv beviser deaktivering

Tilstedeværelsen af det rigtige tal i registreringsdatabasen bekræfter ikke, at Windows har accepteret det som en gældende MDM-politik. Derfor er situationen «værdien er skrevet, men CrossDeviceResume starter alligevel» ikke i modstrid med resultatet af denne undersøgelse.

I den offentliggjorte dokumentation for denne politik findes der ingen færdig tilsvarende almindelig Registry-indstilling. I vores serie er der ingen separat kontrolleret sammenligning af alle varianter af direkte skrivning. Direkte skrivning er ikke bekræftet som erstatning for anvendelse af politikken, men der er heller ikke grundlag for at hævde, at enhver ændring i registreringsdatabasen altid er nytteløs. Det fungerende resultat blev opnået via politikstyringsmekanismen, med verifikation af tilstanden og den faktiske start efter login.

Rollen af systemets DLL og laboratorieomgåelsen

I eksperimentet brugte vi den indbyggede mdmlocalmanagement.dll. Den tilbyder et interface til lokal styring: RegisterDeviceWithLocalManagement og ApplyLocalManagementSyncML. Deres erklæringer findes i den offentlige header i Windows SDK. Systembiblioteket accepterede anmodningen om at anvende politikken; det var ikke nødvendigt at downloade tredjeparts-DLL’er, erstatte Windows-filer eller patche eksekverbar kode. Intune og cloudstyring blev ikke brugt i forsøget.

Almindelig lokal registrering på den testede Windows Pro returnerede «ikke understøttet». I laboratoriet lykkedes det at omgå denne begrænsning ved midlertidigt at aktivere Embedded Mode, hvorefter politikken blev anvendt, og den oprindelige tilstand for tilstanden blev gendannet. Microsoft beskriver Embedded Mode i forbindelse med specialiserede enheder Windows IoT. En sådan brug på Pro er ikke et Microsoft-bekræftet supportscenarie.

Gendannelsen af den midlertidige tilstand fjernede ikke den lokale styringsregistrering og den tildelte politik. Bivirkninger ved midlertidig aktivering af tilstanden uden for det testede scenarie blev ikke undersøgt. Her beskrives princippet i eksperimentet; kommandoer, indholdet af anmodningen og rækkefølgen for reproduktion af omgåelsen offentliggøres ikke.

Resultater

Test	Resultat og grænse for konklusion
Anvendelse af den forbydende politik	Operationen lykkedes, tilbagelæsning bekræftede tilstanden
Allerede kørende proces	Afsluttedes ikke automatisk
Genstart og login med forbud	Processen var fraværende; i 153 sekunder efter shell-start blev der ikke registreret nogen start af den
Tilladelse, genstart og login	Processen optrådte, oprettelsen blev bekræftet af loggen
Fornyet forbud og separat afslutning af processen	Efter 10 sekunder var processen fraværende; ingen fornyet start blev fundet i 120 sekunders observation
Fuld tilbagerulning af testopsætningen	Den oprindelige tilstand blev gendannet med VM-snapshot og verificeret

Stikprøven indeholder én VM og én sekvens af tests. Gentagne observationer inden for 120-sekundersintervallet er ikke uafhængige eksperimenter. Der findes ingen uafhængig reproduktion på en anden computer.

Hvad der er bekræftet

• I det testede scenarie forhindrede politikken den normale start af den separate proces efter genstart og login.
• Tilladelse af funktionen igen bragte starten tilbage på samme testopsætning.
• Anvendelse af politikken alene lukker ikke en allerede kørende proces.
• For det opnåede resultat var det ikke nødvendigt at erstatte system-DLL’er eller patche EXE.

Den forhindrede start udelukker, at denne proces kører i det observerede scenarie. Det er en konkret effekt af at deaktivere en unødvendig baggrundsfunktion, selv uden måling af FPS.

Hvad der ikke er bekræftet

Stigning i FPS, ændring i frametime, samlet CPU-belastning og RAM-besparelse er ikke målt. Manuel start af EXE, alle alternative aktiveringsmetoder, placering af Resume inde i ShellHost og kørsel fra en anden konto eller SYSTEM er ikke testet. Der var ingen separat parret test af anvendelse via BoosterX’ færdige interface i denne serie: tabellen beskriver Windows’ laboratoriemekanisme.

Begrænsninger

På testdatoen markerer Microsoft politikken som gældende for Windows Insider Preview. Observationen på den angivne Windows 11 Pro 25H2 erstatter ikke den officielle supportmatrix. Testen på en anden planlagt VM blev ikke gennemført, derfor findes der ingen resultater for den. Fraværet af hændelser i 153 sekunder betyder ikke et forbud mod enhver start for evigt: den bekræftede effekt vedrører den normale start efter genstart og login, og start af processen på andre måder blev ikke undersøgt i denne undersøgelse.

Artiklen fastslår ikke, hvordan BoosterX anvender sin indstilling. Sammenhængen mellem BoosterX-kortet og den her testede MDM-politik indgik ikke i eksperimentets plan; en vurdering af, hvorvidt programmet bruger samme mekanisme, kræver en separat verifikation baseret på applikationens faktiske adfærd.

Deaktiveringen vedrører Resume. Den kan ikke beskrives som deaktivering af hele «Forbindelse til telefon» eller hele Windows’ infrastruktur for enheder imellem.

Praktisk konklusion

Hvis du ikke bruger fortsat arbejde fra telefonen, er deaktivering af Resume velbegrundet. På den testede opsætning gjorde MDM-politikken det muligt at undgå dens normale start. For brugeren er det nemmere at vælge den eksisterende indstilling i BoosterX og genstarte pc’en end manuelt at eksperimentere med politiklagret. Verificér resultatet på din egen Windows-version.

Gendannelse af tilstanden

I eksperimentet bragte tilladelse af funktionen og en ny genstart processens start tilbage. Derefter blev VM’en fuldt gendannet fra det oprindelige snapshot: det blev kontrolleret, at politikken tildelt under testen var fraværende, tilstandens oprindelige værdi, annullering af den midlertidige auto-login og processens tilbagevenden.

I BoosterX tillader aktivering i samme kort Resume efter anvendelse og genstart. Det er ikke fuldt ækvivalent med tilbagerulning af et snapshot: den lokale styringsregistrering, oprettet af laboratorieanvendelsen af politikken, bevares, ligesom tidligere anvendte begrænsninger fra andre værktøjer. Detaljer om tilbageføring findes på indstillingssiden.

Offentlige primære kilder

• Microsoft: Connectivity / DisableCrossDeviceResume: politikens formål, brugerområde og genstart; ikke bevis for resultaterne på vores VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: erklæringer for det lokale styringsinterface; ikke et løfte om tilgængelighed på enhver udgave.
• Microsoft: Embedded Mode: kontekst for Windows IoT; ikke en instruktion i understøttet anvendelse på Pro.

Undersøgelsen og de anvendte værktøjer tilhører udvikleren af BoosterX, derfor har udvikleren en direkte interesse i resultaterne. Metoden og grænserne for anvendelighed er beskrevet ovenfor, og konklusionerne kan verificeres via åbne data og de listede offentlige kilder. Microsoft er ikke forfatter til undersøgelsen og har ikke bekræftet dens konklusioner.

Testdato og ændringshistorik

2026-09-17: første version; offentlige kilder blev kontrolleret, resultaterne fra én VM, grænserne for konklusionen og den omvendte verifikation af starten blev offentliggjort.

2026-09-19: efter uafhængig verifikation blev rammen for konklusionen korrigeret: påstanden om en specifik BoosterX-mekanisme blev fjernet. Undersøgelsen tester Windows’ offentlige MDM-politik og laboratorievejen til at anvende den, ikke implementeringen af indstillingen i programmet; eksperimentets resultater, grænserne for konklusionen og kilderne er bevaret, og forbeholdene om grænserne for den bekræftede effekt er præciseret.

2026-09-20: ansvarsfraskrivelsen om interessekonflikter blev styrket: udviklerens direkte interesse, da undersøgelsen og værktøjerne tilhører denne, anerkendes eksplicit; description blev forkortet.