Как отключить 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.