Jak wyłączyć Cross-Device Resume

Krótka odpowiedź

Cross-Device Resume można wyłączyć przez politykę MDM systemu Windows. W naszym eksperymencie po jej zastosowaniu, ponownym uruchomieniu i zalogowaniu się CrossDeviceResume.exe nie uruchamiał się przez 153 sekundy obserwacji. Po ponownym włączeniu funkcji i kolejnym ponownym uruchomieniu proces pojawił się znowu.

Prościej zastosować ustawienie przez BoosterX → Optymalizacja → Tweaki → Cross-Device Resume: wybrać wyłączenie, nacisnąć «Zastosuj» i ponownie uruchomić PC. To badanie sprawdzało publiczny mechanizm Windows, a nie implementację BoosterX: jak dokładnie program stosuje ustawienie, w tej serii nie testowano i w artykule tego nie twierdzimy. Szczegóły zastosowania i przywracania są na stronie ustawienia.

Co sprawdzano

Interesowało nas nie tylko zniknięcie powiadomień Resume, ale też zapobieżenie standardowemu uruchomieniu jego osobnego procesu przy logowaniu do Windows. To różne wyniki: program może uruchamiać się i od razu kończyć, dalej działać bez powiadomień albo w ogóle nie otrzymywać żądania uruchomienia.

Microsoft opisuje DisableCrossDeviceResume jako politykę użytkownika, wyłączającą powiadomienia o kontynuowaniu pracy z telefonu, i wskazuje konieczność ponownego uruchomienia. Udokumentowane: przeznaczenie polityki i moment zastosowania. Zaobserwowane w naszym eksperymencie: brak uruchomienia osobnego procesu. Opis Microsoft.

Zakres badania

Warunek	Sprawdzone środowisko
System	Windows 11 Pro 25H2, kompilacja 26200.9445
Komponent	CrossDeviceResume 2607.27000.0.0
Stanowisko	Jedna maszyna wirtualna VMware
Scenariusz	Ponowne uruchomienie i interaktywne logowanie tego samego użytkownika
Obserwacja	Lista procesów i audyt ich tworzenia, zdarzenia 4688
Data eksperymentu	2026-09-17

To eksperyment funkcjonalny, a nie test FPS lub zużycia pamięci. Model fizycznego CPU, konfiguracja zasobów wirtualnych i wersje sterowników nie są uwzględnione w opublikowanej próbie. Przenoszenie wyniku na fizyczne PC, inne kompilacje lub inne sposoby uruchamiania bez weryfikacji jest niedozwolone.

Jak przeprowadzano weryfikację

Najpierw zarejestrowano działający proces i początkowy stan polityki. Następnie zastosowano politykę blokującą przez lokalny mechanizm zarządzania Windows, sprawdzono powodzenie operacji i odczytano stan z powrotem. Po ponownym uruchomieniu doczekano się interaktywnego logowania i rozpoczęcia pracy powłoki, sprawdzono procesy i dziennik ich tworzenia.

Dla kontroli odwrotnej włączono Resume i powtórzono ponowne uruchomienie z logowaniem. Osobno ponownie zablokowano funkcję, jawnie zakończono już działający proces i obserwowano możliwe ponowne uruchomienie. Zakończenie procesu było samodzielnym działaniem, nie można go przypisywać polityce.

Dlaczego wpis w rejestrze jeszcze nie dowodzi wyłączenia

Obecność odpowiedniej liczby w rejestrze nie potwierdza, że Windows przyjął ją jako obowiązującą politykę MDM. Dlatego sytuacja «wartość zapisana, a CrossDeviceResume mimo to się uruchamia» nie przeczy wynikowi tego badania.

W opublikowanej dokumentacji tej polityki nie ma gotowego odpowiednika zwykłego ustawienia Registry. W naszej serii nie ma osobnego kontrolowanego porównania wszystkich wariantów bezpośredniego zapisu. Bezpośredni zapis nie został potwierdzony jako zamiennik zastosowania polityki, ale nie ma też podstaw, by twierdzić, że każda modyfikacja rejestru jest zawsze bezużyteczna. Działający wynik uzyskano przez mechanizm zarządzania politykami, z weryfikacją stanu i faktycznego uruchomienia po zalogowaniu.

Rola systemowej DLL i obejścia laboratoryjnego

W eksperymencie użyto wbudowanej mdmlocalmanagement.dll. Udostępnia ona interfejs lokalnego zarządzania: RegisterDeviceWithLocalManagement i ApplyLocalManagementSyncML. Ich deklaracje są dostępne w publicznym nagłówku Windows SDK. Biblioteka systemowa przyjmowała żądanie zastosowania polityki; pobieranie zewnętrznych DLL, zastępowanie plików Windows ani patchowanie kodu wykonywalnego nie było potrzebne. Intune i zarządzanie w chmurze nie były używane w doświadczeniu.

Zwykła lokalna rejestracja na sprawdzonym Windows Pro zwróciła «nieobsługiwane». W laboratorium udało się przejść to ograniczenie przez tymczasowe włączenie Embedded Mode, po czym zastosować politykę i przywrócić początkowy parametr trybu. Microsoft opisuje Embedded Mode w kontekście wyspecjalizowanych urządzeń Windows IoT. Takie użycie na Pro nie jest potwierdzonym przez Microsoft scenariuszem wsparcia.

Przywrócenie trybu tymczasowego nie usunęło lokalnej rejestracji zarządzania i przypisanej polityki. Skutki uboczne tymczasowego włączenia trybu poza sprawdzonym scenariuszem nie były badane. Tutaj opisano zasadę eksperymentu; polecenia, zawartość żądania i kolejność odtwarzania obejścia nie są publikowane.

Wyniki

Weryfikacja	Wynik i granica wniosku
Zastosowanie polityki blokującej	Operacja udana, odczyt zwrotny potwierdził stan
Już działający proces	Nie zakończył się automatycznie
Ponowne uruchomienie i logowanie z blokadą	Proces nieobecny; przez 153 sekundy po starcie powłoki nie zarejestrowano jego uruchomień
Włączenie, ponowne uruchomienie i logowanie	Proces pojawił się, utworzenie potwierdzone dziennikiem
Ponowna blokada i osobne zakończenie procesu	Po 10 sekundach proces był nieobecny; ponownego uruchomienia przez 120 sekund obserwacji nie wykryto
Pełne wycofanie stanowiska	Stan początkowy przywrócony migawką VM i sprawdzony

W próbie jedna VM i jedna sekwencja weryfikacji. Powtórne obserwacje w obrębie 120-sekundowego interwału nie są niezależnymi eksperymentami. Nie ma niezależnego odtworzenia na drugim komputerze.

Co potwierdzono

• W sprawdzonym scenariuszu polityka zapobiegła standardowemu uruchomieniu osobnego procesu po ponownym uruchomieniu i zalogowaniu.
• Ponowne włączenie funkcji przywróciło uruchamianie na tym samym stanowisku.
• Zastosowanie polityki samo w sobie nie zamyka już działającego procesu.
• Dla uzyskanego wyniku nie były potrzebne zastąpienie systemowych DLL ani patch EXE.

Zapobieżone uruchomienie wyklucza działanie tego procesu w obserwowanym scenariuszu. To konkretny efekt wyłączenia niepotrzebnej funkcji działającej w tle, nawet bez pomiaru FPS.

Co nie zostało potwierdzone

Nie zmierzono przyrostu FPS, zmiany frametime, ogólnego obciążenia CPU i oszczędności RAM. Nie sprawdzono ręcznego uruchomienia EXE, wszystkich alternatywnych sposobów aktywacji, umieszczenia Resume wewnątrz ShellHost ani działania z innego konta lub SYSTEM. Osobnego testu porównawczego zastosowania przez gotowy interfejs BoosterX w tej serii nie było: tabela opisuje laboratoryjny mechanizm Windows.

Ograniczenia

Na dzień weryfikacji Microsoft oznacza politykę jako mającą zastosowanie do Windows Insider Preview. Obserwacja na wskazanym Windows 11 Pro 25H2 nie zastępuje oficjalnej macierzy wsparcia. Weryfikacja na innej planowanej VM nie doszła do skutku, więc nie ma dla niej wyników. Brak zdarzeń przez 153 sekundy nie oznacza zakazu wszelkich uruchomień na zawsze: potwierdzony efekt dotyczy standardowego uruchomienia po ponownym uruchomieniu i zalogowaniu, a uruchamiania procesu innymi sposobami to badanie nie badało.

Artykuł nie ustala, w jaki sposób BoosterX stosuje swoje ustawienie. Związek między kartą BoosterX a sprawdzoną tutaj polityką MDM nie wchodził w plan eksperymentu; sąd o tym, czy program używa tego samego mechanizmu, wymaga osobnej weryfikacji na podstawie faktycznego zachowania aplikacji.

Wyłączenie dotyczy Resume. Nie można go opisywać jako wyłączenia całej «Łączności z telefonem» ani całej międzynrządzeniowej infrastruktury Windows.

Wniosek praktyczny

Jeśli nie korzystasz z kontynuowania pracy z telefonu, wyłączenie Resume jest uzasadnione. Na sprawdzonym stanowisku polityka MDM pozwoliła uniknąć jego standardowego uruchomienia. Dla użytkownika prościej jest wybrać istniejące ustawienie w BoosterX i ponownie uruchomić PC, niż ręcznie eksperymentować z magazynem polityk. Sprawdzaj wynik na swojej wersji Windows.

Przywracanie stanu

W eksperymencie włączenie funkcji i ponowne uruchomienie przywróciły uruchamianie procesu. Następnie VM całkowicie przywrócono z początkowej migawki: sprawdzono brak polityki przypisanej w trakcie weryfikacji, początkowy stan trybu, anulowanie tymczasowego automatycznego logowania i powrót procesu.

W BoosterX włączenie w tej samej karcie włącza Resume po zastosowaniu i ponownym uruchomieniu. To nie jest pełny odpowiednik wycofania migawki: lokalna rejestracja zarządzania, utworzona przez laboratoryjne zastosowanie polityki, pozostaje, podobnie jak wcześniej zastosowane ograniczenia innych narzędzi. Szczegóły przywracania podano na stronie ustawienia.

Publiczne źródła pierwotne

• Microsoft: Connectivity / DisableCrossDeviceResume: przeznaczenie polityki, zakres użytkownika i ponowne uruchomienie; nie dowód wyników naszej VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: deklaracje interfejsu lokalnego zarządzania; nie obietnica dostępności w każdej edycji.
• Microsoft: Embedded Mode: kontekst Windows IoT; nie instrukcja obsługiwanego zastosowania na Pro.

Badanie i użyte narzędzia należą do dewelopera BoosterX, dlatego deweloper ma bezpośredni interes w wynikach. Metodyka i granice stosowalności opisano powyżej, a wnioski można sprawdzić na podstawie otwartych danych i wymienionych publicznych źródeł. Microsoft nie jest autorem badania i nie potwierdzał jego wniosków.

Data weryfikacji i historia zmian

2026-09-17: pierwsza wersja; sprawdzono publiczne źródła, opublikowano wyniki jednej VM, granice wniosku i kontrolę odwrotną uruchomienia.

2026-09-19: po niezależnej weryfikacji skorygowano ramę wniosku: usunięto twierdzenie o konkretnym mechanizmie BoosterX. Badanie sprawdza publiczną politykę MDM systemu Windows i laboratoryjną drogę jej zastosowania, a nie implementację ustawienia w programie; wyniki eksperymentu, granice wniosku i źródła zachowano, doprecyzowano zastrzeżenia o granicach potwierdzonego efektu.

2026-09-20: wzmocniono disclaimer o konflikcie interesów: wyraźnie uznano bezpośredni interes dewelopera, do którego należą badanie i narzędzia; skrócono description.