How to disable Cross-Device Resume
On this page
Short answer
Section titled “Short answer”Cross-Device Resume can be disabled through a Windows MDM policy. In our
experiment, after applying it, rebooting and signing in,
CrossDeviceResume.exe did not start during 153 seconds of observation.
When the feature was allowed again and the machine was rebooted once more, the process reappeared.
The simpler way to apply the setting is through BoosterX → Optimization → Tweaks → Cross-Device Resume: select the disable option, click “Apply” and reboot the PC. This study tested a public Windows mechanism, not the BoosterX implementation: how exactly the program applies the setting was not tested in this series and is not claimed in the article. Details on applying and reverting it are on the setting page.
What was tested
Section titled “What was tested”We were interested not only in the disappearance of Resume notifications, but also in preventing the normal startup of its separate process at Windows sign-in. These are different outcomes: the program may start and immediately exit, keep running without notifications, or never receive a start request at all.
Microsoft describes DisableCrossDeviceResume as a user policy
that disables notifications about continuing work from a phone, and states that a
reboot is required. Documented: the purpose of the policy and when it takes effect.
Observed in our experiment: the absence of the separate process starting.
Microsoft description.
Scope of the study
Section titled “Scope of the study”| Condition | Tested environment |
|---|---|
| System | Windows 11 Pro 25H2, build 26200.9445 |
| Component | CrossDeviceResume 2607.27000.0.0 |
| Test bench | One VMware virtual machine |
| Scenario | Reboot and interactive sign-in by the same user |
| Observation | Process list and audit of their creation, events 4688 |
| Experiment date | 2026-09-17 |
This is a functional experiment, not an FPS or memory consumption test. The physical CPU model, the virtual resource configuration and driver versions are not included in the published sample. The result cannot be carried over to physical PCs, other builds or other launch methods without verification.
How the test was performed
Section titled “How the test was performed”First we recorded the running process and the initial state of the policy. Then we applied the prohibiting policy through the local Windows management mechanism, checked that the operation succeeded and read the state back. After the reboot we waited for the interactive sign-in and for the shell to start, then checked the processes and the log of their creation.
For the reverse control we allowed Resume and repeated the reboot with sign-in. Separately, we disabled the feature again, explicitly terminated the already running process and observed a possible restart. Terminating the process was an independent action and cannot be attributed to the policy.
Why a Registry entry alone does not yet prove the feature is disabled
Section titled “Why a Registry entry alone does not yet prove the feature is disabled”The presence of the required value in the Registry does not confirm that Windows accepted it as an active MDM policy. Therefore the situation “the value is written, but CrossDeviceResume still starts” does not contradict the result of this study.
In the published documentation for this policy there is no ready-made correspondence to a regular Registry setting. Our series has no separate controlled comparison of all variants of direct writing. Direct writing is not confirmed as a replacement for applying the policy, but there are also no grounds to claim that any Registry edit is always useless. The working result was obtained through the policy management mechanism, with verification of the state and of the actual startup after sign-in.
The role of the system DLL and the laboratory workaround
Section titled “The role of the system DLL and the laboratory workaround”The experiment used the built-in mdmlocalmanagement.dll. It provides
a local management interface: RegisterDeviceWithLocalManagement and
ApplyLocalManagementSyncML. Their declarations are available in the
public Windows SDK header.
The system library accepted the request to apply the policy; there was no need to download third-party
DLLs, replace Windows files or patch executable code.
Intune and cloud management were not used in the experiment.
A regular local registration on the tested Windows Pro returned “not supported”. In the laboratory we were able to get past this limitation by temporarily enabling Embedded Mode, after which we applied the policy and restored the original mode parameter. Microsoft describes Embedded Mode in the context of specialized Windows IoT devices. Such use on Pro is not a Microsoft-confirmed support scenario.
Restoring the temporary mode did not remove the local management registration or the assigned policy. Side effects of temporarily enabling the mode beyond the tested scenario were not studied. What is described here is the principle of the experiment; the commands, the contents of the request and the sequence for reproducing the workaround are not published.
Results
Section titled “Results”| Check | Result and limit of the conclusion |
|---|---|
| Applying the prohibiting policy | Operation successful, reading back confirmed the state |
| Already running process | Did not terminate automatically |
| Reboot and sign-in with the feature disabled | Process absent; no starts registered during 153 seconds after the shell started |
| Allowing it, rebooting and signing in | Process appeared, creation confirmed by the log |
| Disabling again and separately terminating the process | After 10 seconds the process was absent; no restart detected during 120 seconds of observation |
| Full rollback of the test bench | Initial state restored from a VM snapshot and verified |
The sample contains one VM and one sequence of checks. Repeated observations within the 120-second interval are not independent experiments. There is no independent reproduction on a second computer.
What is confirmed
Section titled “What is confirmed”- In the tested scenario the policy prevented the normal startup of the separate process after a reboot and sign-in.
- Allowing the feature again brought the startup back on the same test bench.
- Applying the policy by itself does not close an already running process.
- The result obtained did not require replacing system DLLs or patching an EXE.
The prevented startup rules out the operation of this process in the observed scenario. This is a concrete effect of disabling an unnecessary background feature, even without measuring FPS.
What is not confirmed
Section titled “What is not confirmed”FPS gains, frametime changes, overall CPU load and RAM savings were not measured.
Manual launch of the EXE, all alternative activation methods, placement of
Resume inside ShellHost and operation from another account or SYSTEM were not tested.
There was no separate paired test of applying the setting through the ready-made BoosterX interface in this
series: the table describes the laboratory Windows mechanism.
Limitations
Section titled “Limitations”As of the test date, Microsoft marks the policy as applicable to Windows Insider Preview. Observation on the specified Windows 11 Pro 25H2 does not replace the official support matrix. Testing on another planned VM did not take place, so there are no results for it. The absence of events for 153 seconds does not mean that any startup is prohibited forever: the confirmed effect concerns the normal startup after a reboot and sign-in, and this study did not examine starting the process by other means.
The article does not establish how BoosterX applies its setting. The relationship between the BoosterX card and the MDM policy tested here was not part of the experiment plan; judging whether the program uses this same mechanism requires a separate check based on the application’s actual behavior.
The disabling concerns Resume. It cannot be described as disabling all of “Phone Link” or the entire cross-device infrastructure of Windows.
Practical conclusion
Section titled “Practical conclusion”If you do not use continuing work from a phone, disabling Resume is justified. On the tested bench the MDM policy made it possible to avoid its normal startup. For the user it is simpler to select the existing setting in BoosterX and reboot the PC than to experiment manually with the policy store. Verify the result on your own version of Windows.
Restoring the state
Section titled “Restoring the state”In the experiment, allowing the feature and rebooting again brought the process startup back. Then the VM was fully restored from the original snapshot: we verified the absence of the policy assigned during the test, the original state of the mode, the cancellation of the temporary automatic sign-in and the return of the process.
In BoosterX, enabling the option in the same card allows Resume after applying and rebooting. This is not a complete equivalent of a snapshot rollback: the local management registration created by the laboratory application of the policy remains, as do previously applied restrictions from other tools. Details on reverting are given on the setting page.
Public primary sources
Section titled “Public primary sources”- Microsoft: Connectivity / DisableCrossDeviceResume: purpose of the policy, user scope and reboot; not proof of our VM’s results.
- Microsoft Windows SDK: mdmlocalmanagement.h: declarations of the local management interface; not a promise of availability on any edition.
- Microsoft: Embedded Mode: the Windows IoT context; not an instruction for supported use on Pro.
The study and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and the limits of applicability are described above, and the conclusions can be verified against open data and the public sources listed. Microsoft is not the author of the study and has not confirmed its conclusions.
Test date and change history
Section titled “Test date and change history”2026-09-17: first version; public sources checked, results published for one VM, limits of the conclusion and the reverse startup check.
2026-09-19: after an independent review the framing of the conclusion was corrected: the claim about a specific BoosterX mechanism was removed. The study tests the public Windows MDM policy and the laboratory path for applying it, not the implementation of the setting in the program; the experiment results, limits of the conclusion and sources are preserved, and the caveats about the limits of the confirmed effect were refined.
2026-09-20: the conflict-of-interest disclaimer was strengthened: the developer’s direct interest is explicitly acknowledged, since the developer owns the study and the tools; the description was shortened.