Як вимкнути Cross-Device Resume

Коротка відповідь

Cross-Device Resume можна вимкнути через MDM-політику Windows. У нашому експерименті після її застосування, перезавантаження і входу в систему CrossDeviceResume.exe не запускався протягом 153 секунд спостереження. При зворотному дозволі функції та повторному перезавантаженні процес знову з’явився.

Простіше застосувати налаштування через BoosterX → Оптимізація → Твіки → Cross-Device Resume: вибрати вимкнення, натиснути «Застосувати» і перезавантажити ПК. Це дослідження перевіряло публічний механізм Windows, а не реалізацію BoosterX: як саме програма застосовує налаштування, у цій серії не випробовувалося і в статті не стверджується. Подробиці застосування та повернення є на сторінці налаштування.

Що перевіряли

Нас цікавило не лише зникнення повідомлень Resume, а й запобігання штатному запуску його окремого процесу при вході в Windows. Це різні результати: програма може запускатися і відразу завершуватися, продовжувати працювати без повідомлень або взагалі не отримувати запит на запуск.

Microsoft описує DisableCrossDeviceResume як користувацьку політику, що вимикає повідомлення про продовження роботи з телефона, і вказує необхідність перезавантаження. Документовано: призначення політики та момент застосування. Спостерігалося в нашому експерименті: відсутність запуску окремого процесу. Опис Microsoft.

Область дослідження

Умова	Перевірене середовище
Система	Windows 11 Pro 25H2, збірка 26200.9445
Компонент	CrossDeviceResume 2607.27000.0.0
Стенд	Одна віртуальна машина VMware
Сценарій	Перезавантаження та інтерактивний вхід того самого користувача
Спостереження	Список процесів і аудит їх створення, події 4688
Дата експерименту	2026-09-17

Це функціональний експеримент, а не тест FPS чи споживання пам’яті. Модель фізичного CPU, конфігурація віртуальних ресурсів і версії драйверів не включені до опублікованої вибірки. Переносити результат на фізичні ПК, інші збірки або інші способи запуску без перевірки не можна.

Як проводили перевірку

Спочатку зафіксували працюючий процес і початковий стан політики. Потім застосували заборонну політику через локальний механізм управління Windows, перевірили успішність операції та прочитали стан назад. Після перезавантаження дочекалися інтерактивного входу та початку роботи оболонки, перевірили процеси і журнал їх створення.

Для зворотного контролю дозволили Resume і повторили перезавантаження з входом. Окремо знову заборонили функцію, явно завершили вже працюючий процес і спостерігали можливий повторний запуск. Завершення процесу було самостійною дією, його не можна приписувати політиці.

Чому запис у реєстрі ще не доводить вимкнення

Наявність потрібного числа в реєстрі не підтверджує, що Windows прийняла його як чинну MDM-політику. Тому ситуація «значення записано, а CrossDeviceResume все одно запускається» не суперечить результату цього дослідження.

В опублікованій документації цієї політики немає готової відповідності звичайному Registry-налаштуванню. У нашій серії немає окремого контрольованого порівняння всіх варіантів прямого запису. Прямий запис не підтверджено як заміну застосуванню політики, але й стверджувати, що будь-яка правка реєстру завжди марна, підстав немає. Робочий результат отримано через механізм управління політиками, з перевіркою стану та фактичного запуску після входу.

Роль системної DLL і лабораторного обходу

В експерименті використали вбудовану mdmlocalmanagement.dll. Вона надає інтерфейс локального управління: RegisterDeviceWithLocalManagement та ApplyLocalManagementSyncML. Їхні оголошення доступні в публічному заголовку Windows SDK. Системна бібліотека приймала запит на застосування політики; завантажувати сторонні DLL, замінювати файли Windows або патчити виконуваний код не довелося. Intune і хмарне управління в досліді не використовувалися.

Звичайна локальна реєстрація на перевіреній Windows Pro повернула «не підтримується». У лабораторії вдалося пройти це обмеження тимчасовим увімкненням Embedded Mode, після чого застосувати політику і відновити початковий параметр режиму. Microsoft описує Embedded Mode у контексті спеціалізованих пристроїв Windows IoT. Таке використання на Pro не є підтвердженим Microsoft сценарієм підтримки.

Відновлення тимчасового режиму не видалило локальну реєстрацію управління і призначену політику. Побічні ефекти тимчасового увімкнення режиму за межами перевіреного сценарію не досліджувалися. Тут описано принцип експерименту; команди, вміст запиту та послідовність відтворення обходу не публікуються.

Результати

Перевірка	Результат і межа висновку
Застосування заборонної політики	Операція успішна, зворотне читання підтвердило стан
Вже працюючий процес	Автоматично не завершився
Перезавантаження і вхід із забороною	Процес був відсутній; за 153 секунди після старту оболонки не зареєстровано його запусків
Дозвіл, перезавантаження і вхід	Процес з’явився, створення підтверджено журналом
Повторна заборона і окреме завершення процесу	Через 10 секунд процес був відсутній; повторного запуску за 120 секунд спостереження не виявлено
Повне відкочування стенда	Початковий стан відновлено знімком VM і перевірено

У вибірці одна VM і одна послідовність перевірок. Повторні спостереження всередині 120-секундного інтервалу не є незалежними експериментами. Незалежного відтворення на другому комп’ютері немає.

Що підтверджено

• У перевіреному сценарії політика запобігла штатному запуску окремого процесу після перезавантаження і входу.
• Зворотний дозвіл функції повернув запуск на тому самому стенді.
• Застосування політики саме по собі не закриває вже працюючий процес.
• Для отриманого результату не знадобилися заміна системних DLL або патч EXE.

Запобігнутий запуск виключає роботу цього процесу в спостережуваному сценарії. Це конкретний ефект вимкнення непотрібної фонової функції, навіть без вимірювання FPS.

Що не підтверджено

Не виміряно приріст FPS, зміну frametime, загальне навантаження CPU та економію RAM. Не перевірено ручний запуск EXE, усі альтернативні способи активації, розміщення Resume всередині ShellHost і роботу від іншого облікового запису або SYSTEM. Окремого парного випробування застосування через готовий інтерфейс BoosterX у цій серії не було: таблиця описує лабораторний механізм Windows.

Обмеження

На дату перевірки Microsoft позначає політику як застосовну до Windows Insider Preview. Спостереження на зазначеній Windows 11 Pro 25H2 не замінює офіційну матрицю підтримки. Перевірка на іншій запланованій VM не відбулася, тому результатів для неї немає. Відсутність подій за 153 секунди не означає заборону будь-яких запусків назавжди: підтверджений ефект стосується штатного запуску після перезавантаження і входу, а запуск процесу іншими способами це дослідження не вивчало.

Стаття не встановлює, яким способом BoosterX застосовує своє налаштування. Зв’язок між карткою BoosterX і перевіреною тут MDM-політикою не входив до плану експерименту; судження про те, чи використовує програма цей самий механізм, потребує окремої перевірки за фактичною поведінкою застосунку.

Вимкнення стосується Resume. Його не можна описувати як вимкнення всієї «Зв’язку з телефоном» або всієї міжпристроєвої інфраструктури Windows.

Практичний висновок

Якщо не користуєтеся продовженням роботи з телефона, вимкнення Resume обґрунтоване. На перевіреному стенді MDM-політика дозволила уникнути його штатного запуску. Для користувача простіше вибрати наявне налаштування в BoosterX і перезавантажити ПК, ніж вручну експериментувати зі сховищем політик. Перевіряйте результат на своїй версії Windows.

Відновлення стану

В експерименті дозвіл функції та повторне перезавантаження повернули запуск процесу. Потім VM повністю відновили з початкового знімка: перевірили відсутність призначеної під час перевірки політики, початковий стан режиму, скасування тимчасового автовходу і повернення процесу.

У BoosterX увімкнення в тій самій картці дозволяє Resume після застосування і перезавантаження. Це не повний аналог відкочування знімка: локальна реєстрація управління, створена лабораторним застосуванням політики, зберігається, як і раніше застосовані обмеження інших інструментів. Подробиці повернення наведено на сторінці налаштування.

Публічні первинні джерела

• Microsoft: Connectivity / DisableCrossDeviceResume: призначення політики, область користувача і перезавантаження; не доказ результатів нашої VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: оголошення інтерфейсу локального управління; не обіцянка доступності на будь-якій редакції.
• Microsoft: Embedded Mode: контекст Windows IoT; не інструкція з підтримуваного застосування на Pro.

Дослідження та використані інструменти належать розробнику BoosterX, тому в розробника є прямий інтерес до результатів. Методику і межі застосовності описано вище, а висновки можна перевірити за відкритими даними і переліченими публічними джерелами. Microsoft не є автором дослідження і не підтверджувала його висновки.

Дата перевірки та історія змін

2026-09-17: перша версія; перевірено публічні джерела, опубліковано результати однієї VM, межі висновку та зворотну перевірку запуску.

2026-09-19: після незалежної звірки скориговано рамку висновку: прибрано твердження про конкретний механізм BoosterX. Дослідження перевіряє публічну MDM-політику Windows і лабораторний шлях її застосування, а не реалізацію налаштування в програмі; результати експерименту, межі висновку та джерела збережено, уточнено застереження про межі підтвердженого ефекту.

2026-09-20: дисклеймер про конфлікт інтересів посилено: явно визнано прямий інтерес розробника, якому належать дослідження та інструменти; скорочено description.