Kā atspējot Cross-Device Resume

Īsā atbilde

Cross-Device Resume var atslēgt, izmantojot Windows MDM politiku. Mūsu eksperimentā pēc tās piemērošanas, pārstartēšanas un pieteikšanās sistēmā CrossDeviceResume.exe netika palaists 153 sekunžu novērojuma laikā. Kad funkcija tika atkal atļauta un veikta atkārtota pārstartēšana, process atkal parādījās.

Vienkāršāk ir piemērot iestatījumu, izmantojot BoosterX → Optimizācija → Tviki → Cross-Device Resume: izvēlēties atslēgšanu, nospiest «Piemaņot» un pārstartēt datoru. Šis pētījums pārbaudīja publisku Windows mehānismu, nevis BoosterX realizāciju: kā tieši programma piemēro iestatījumu, šajā sērijā netika pārbaudīts un rakstā netiek apgalvots. Piemērošanas un atgriešanas detaļas ir pieejamas iestatījuma lapā.

Ko pārbaudījām

Mūs interesēja ne tikai Resume paziņojumu pazušana, bet arī tā atsevišķā procesa kārtējās palaišanas novēršana pieteikšanās laikā sistēmā Windows. Tie ir dažādi rezultāti: programma var palaisties un uzreiz beigties, turpināt darboties bez paziņojumiem vai vispār nesaņemt palaišanas pieprasījumu.

Microsoft apraksta DisableCrossDeviceResume kā lietotāja politiku, kas atslēdz paziņojumus par darba turpināšanu no tālruņa, un norāda uz nepieciešamību pārstartēt. Dokumentēts: politikas mērķis un piemērošanas brīdis. Mūsu eksperimentā novērots: atsevišķa procesa palaišanas neesamība. Microsoft apraksts.

Pētījuma tvērums

Nosacījums	Pārbaudītā vide
Sistēma	Windows 11 Pro 25H2, būvējums 26200.9445
Komponents	CrossDeviceResume 2607.27000.0.0
Stends	Viena VMware virtuālā mašīna
Scenārijs	Pārstartēšana un tā paša lietotāja interaktīva pieteikšanās
Novērojums	Procesu saraksts un to izveides audits, notikumi 4688
Eksperimenta datums	2026-09-17

Šis ir funkcionāls eksperiments, nevis FPS vai atmiņas patēriņa tests. Fiziskā CPU modelis, virtuālo resursu konfigurācija un draiveru versijas nav iekļautas publicētajā izlasē. Pārnest rezultātu uz fiziskiem datoriem, citiem būvējumiem vai citiem palaišanas veidiem bez pārbaudes nav pieļaujams.

Kā veicām pārbaudi

Vispirms fiksējām strādājošu procesu un politikas sākotnējo stāvokli. Pēc tam piemērojām aizliedzošo politiku, izmantojot Windows lokālo pārvaldības mehānismu, pārbaudījām operācijas veiksmi un nolasījām stāvokli atpakaļ. Pēc pārstartēšanas nogaidījām interaktīvu pieteikšanos un čaulas darba sākumu, pārbaudījām procesus un to izveides žurnālu.

Apgrieztajai kontrolei atļāvām Resume un atkārtojām pārstartēšanu ar pieteikšanos. Atsevišķi atkal aizliedzām funkciju, skaidri pārtraucām jau strādājošu procesu un novērojām iespējamu atkārtotu palaišanu. Procesa pārtraukšana bija patstāvīga darbība, to nedrīkst piedēvēt politikai.

Kāpēc ieraksts reģistrā vēl nepierāda atslēgšanu

Vajadzīgā skaitļa esamība reģistrā neapstiprina, ka Windows to ir pieņēmusi kā spēkā esošu MDM politiku. Tāpēc situācija «vērtība ierakstīta, bet CrossDeviceResume joprojām palaižas» nav pretrunā ar šī pētījuma rezultātu.

Publicētajā šīs politikas dokumentācijā nav gatavas atbilstības parastam Registry iestatījumam. Mūsu sērijā nav atsevišķa kontrolēta visu tiešās ierakstīšanas variantu salīdzinājuma. Tieša ierakstīšana nav apstiprināta kā politikas piemērošanas aizvietotājs, taču arī apgalvot, ka jebkurš reģistra labojums vienmēr ir bezjēdzīgs, nav pamata. Darba rezultāts iegūts, izmantojot politiku pārvaldības mehānismu, ar stāvokļa un faktiskās palaišanas pārbaudi pēc pieteikšanās.

Sistēmas DLL loma un laboratorijas apiešanas ceļš

Eksperimentā izmantojām iebūvēto mdmlocalmanagement.dll. Tā nodrošina lokālās pārvaldības saskarni: RegisterDeviceWithLocalManagement un ApplyLocalManagementSyncML. To deklarācijas ir pieejamas publiskajā Windows SDK galvenē. Sistēmas bibliotēka pieņēma politikas piemērošanas pieprasījumu; lejupielādēt trešo pušu DLL, aizstāt Windows failus vai labot izpildāmo kodu nebija nepieciešams. Intune un mākoņpārvaldība pieredzē netika izmantoti.

Parastā lokālā reģistrācija pārbaudītajā Windows Pro atgrieza «nav atbalstīts». Laboratorijā izdevās šo ierobežojumu apiet, uz laiku ieslēdzot Embedded Mode, pēc tam piemērot politiku un atjaunot režīma sākotnējo parametru. Microsoft apraksta Embedded Mode specializētu ierīču kontekstā Windows IoT. Šāda izmantošana Pro versijā nav Microsoft apstiprināts atbalsta scenārijs.

Pagaidu režīma atjaunošana neizdzēsa lokālo pārvaldības reģistrāciju un piešķirto politiku. Pagaidu režīma ieslēgšanas blakusefekti ārpus pārbaudītā scenārija netika pētīti. Šeit aprakstīts eksperimenta princips; komandas, pieprasījuma saturs un apiešanas reproducēšanas secība netiek publicēti.

Rezultāti

Pārbaude	Rezultāts un secinājuma robeža
Aizliedzošās politikas piemērošana	Operācija veiksmīga, atpakaļnolasīšana apstiprināja stāvokli
Jau strādājošs process	Automātiski netika pārtraukts
Pārstartēšana un pieteikšanās ar aizliegumu	Process nebija; 153 sekunžu laikā pēc čaulas starta tā palaišanas nav reģistrētas
Atļaušana, pārstartēšana un pieteikšanās	Process parādījās, izveide apstiprināta ar žurnālu
Atkārtots aizliegums un atsevišķa procesa pārtraukšana	Pēc 10 sekundēm process nebija; atkārtota palaišana 120 sekunžu novērojuma laikā netika konstatēta
Pilnīga stenda atritināšana	Sākotnējais stāvoklis atjaunots ar VM momentuzņēmumu un pārbaudīts

Izlasē ir viena VM un viena pārbaužu secība. Atkārtoti novērojumi 120 sekunžu intervālā nav neatkarīgi eksperimenti. Neatkarīgas reproducēšanas otrajā datorā nav.

Kas apstiprināts

• Pārbaudītajā scenārijā politika novērsa atsevišķa procesa kārtējo palaišanu pēc pārstartēšanas un pieteikšanās.
• Funkcijas atkārtota atļaušana atgrieza palaišanu tajā pašā stendā.
• Politikas piemērošana pati par sevi neaizver jau strādājošu procesu.
• Iegūtajam rezultātam nebija nepieciešama sistēmas DLL aizstāšana vai EXE labošana.

Novērstā palaišana izslēdz šī procesa darbību novērotajā scenārijā. Tas ir konkrēts nevajadzīgas fona funkcijas atslēgšanas efekts, pat bez FPS mērīšanas.

Kas nav apstiprināts

Nav mērīts FPS pieaugums, frametime izmaiņas, kopējā CPU noslodze un RAM ietaupījums. Nav pārbaudīta manuāla EXE palaišana, visi alternatīvie aktivizācijas veidi, Resume izvietojums ShellHost iekšienē un darbība no cita konta vai SYSTEM. Atsevišķa pāru pārbaude ar piemērošanu caur gatavo BoosterX saskarni šajā sērijā nebija: tabula apraksta Windows laboratorijas mehānismu.

Ierobežojumi

Pārbaudes datumā Microsoft atzīmē politiku kā piemērojamu Windows Insider Preview. Novērojums norādītajā Windows 11 Pro 25H2 neaizstāj oficiālo atbalsta matricu. Pārbaude citā plānotajā VM nenotika, tāpēc rezultātu tam nav. Notikumu neesamība 153 sekunžu laikā nenozīmē jebkādu palaišanu aizliegumu uz visiem laikiem: apstiprinātais efekts attiecas uz kārtējo palaišanu pēc pārstartēšanas un pieteikšanās, bet procesa palaišanu citos veidos šis pētījums nepētīja.

Raksts nenosaka, kādā veidā BoosterX piemēro savu iestatījumu. Saikne starp BoosterX kartīti un šeit pārbaudīto MDM politiku nebija eksperimenta plānā; spriedums par to, vai programma izmanto šo pašu mehānismu, prasa atsevišķu pārbaudi pēc lietotnes faktiskās uzvedības.

Atslēgšana attiecas uz Resume. To nedrīkst aprakstīt kā visas «Saziņas ar tālruni» vai visas Windows starpierīču infrastruktūras atslēgšanu.

Praktiskais secinājums

Ja neizmantojat darba turpināšanu no tālruņa, Resume atslēgšana ir pamatota. Pārbaudītajā stendā MDM politika ļāva izvairīties no tā kārtējās palaišanas. Lietotājam vienkāršāk ir izvēlēties esošo iestatījumu BoosterX un pārstartēt datoru, nekā manuāli eksperimentēt ar politiku krātuvi. Pārbaudiet rezultātu savā Windows versijā.

Stāvokļa atjaunošana

Eksperimentā funkcijas atļaušana un atkārtota pārstartēšana atgrieza procesa palaišanu. Pēc tam VM pilnībā atjaunoja no sākotnējā momentuzņēmuma: pārbaudīja pārbaudes gaitā piešķirtās politikas neesamību, režīma sākotnējo stāvokli, pagaidu automātiskās pieteikšanās atcelšanu un procesa atgriešanos.

BoosterX ieslēgšana tajā pašā kartītē atļauj Resume pēc piemērošanas un pārstartēšanas. Tas nav pilnīgs momentuzņēmuma atritināšanas analogs: lokālā pārvaldības reģistrācija, kas izveidota ar laboratorijas politikas piemērošanu, saglabājas, tāpat kā iepriekš piemērotie citu rīku ierobežojumi. Atgriešanas detaļas ir norādītas iestatījuma lapā.

Publiski primārie avoti

• Microsoft: Connectivity / DisableCrossDeviceResume: politikas mērķis, lietotāja tvērums un pārstartēšana; nav mūsu VM rezultātu pierādījums.
• Microsoft Windows SDK: mdmlocalmanagement.h: lokālās pārvaldības saskarnes deklarācijas; nav solījums par pieejamību jebkurā izdevumā.
• Microsoft: Embedded Mode: Windows IoT konteksts; nav instrukcija par atbalstītu piemērošanu Pro versijā.

Pētījums un izmantotie rīki pieder BoosterX izstrādātājam, tāpēc izstrādātājam ir tieša interese par rezultātiem. Metodika un piemērojamības robežas ir aprakstītas iepriekš, un secinājumus var pārbaudīt pēc atklātiem datiem un uzskaitītajiem publiskajiem avotiem. Microsoft nav pētījuma autors un nav apstiprinājis tā secinājumus.

Pārbaudes datums un izmaiņu vēsture

2026-09-17: pirmā versija; pārbaudīti publiskie avoti, publicēti vienas VM rezultāti, secinājumu robežas un palaišanas apgrieztā pārbaude.

2026-09-19: pēc neatkarīgas pārbaudes koriģēts secinājumu ietvars: noņemts apgalvojums par konkrētu BoosterX mehānismu. Pētījums pārbauda publisku Windows MDM politiku un laboratorijas ceļu tās piemērošanai, nevis iestatījuma realizāciju programmā; eksperimenta rezultāti, secinājumu robežas un avoti saglabāti, precizēti atrunas par apstiprinātā efekta robežām.

2026-09-20: pastiprināts interešu konflikta atruna: skaidri atzīta tieša izstrādātāja interese, kam pieder pētījums un rīki; saīsināts description.