如何禁用 Cross-Device Resume
本页内容
Cross-Device Resume 可以通过 Windows 的 MDM 策略禁用。 在我们的
实验中，应用该策略、重启并登录系统后，
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 型号、 虚拟资源配置和驱动程序版本未包含在 已发布的样本中。未经检查，不能将结果推广到物理 PC、其他版本 或其他启动方式。
如何进行检查
Section titled “如何进行检查”首先记录了正在运行的进程和策略的初始状态。然后 通过 Windows 本地管理机制应用了禁止策略， 检查操作是否成功并回读状态。重启后， 等待交互式登录和外壳启动，检查了进程 及其创建日志。
作为反向对照，允许了 Resume 并重复了重启和登录。 另外再次禁用了该功能，显式结束了已在运行的进程， 并观察了可能的再次启动。结束进程是独立操作，不能归因于该策略。
为什么注册表中的记录还不能证明已禁用
Section titled “为什么注册表中的记录还不能证明已禁用”注册表中存在所需数值并不确认 Windows 已将其接受为 有效的 MDM 策略。因此，“值已写入，但 CrossDeviceResume 仍然启动”的情况并不与本研究的结论矛盾。
在该策略的已发布文档中，没有与普通 Registry 设置对应的现成映射。在我们的系列中没有对所有 直接写入方案进行单独的可控比较。直接写入未被确认可以替代策略的应用， 但也没有依据断言任何注册表修改总是无效。 有效结果是通过策略管理机制获得的，并检查了 状态以及登录后的实际启动情况。
系统 DLL 和实验室绕过的作用
Section titled “系统 DLL 和实验室绕过的作用”实验中使用了内置的 mdmlocalmanagement.dll。它提供了
本地管理接口：RegisterDeviceWithLocalManagement 和
ApplyLocalManagementSyncML。它们的声明可在
Windows SDK 公开头文件中找到。
系统库接受了应用策略的请求；无需下载第三方
DLL、替换 Windows 文件或修补可执行代码。
实验中未使用 Intune 和云管理。
在已验证的 Windows Pro 上进行普通本地注册返回了“不支持”。 在实验室中，通过临时启用 Embedded Mode 绕过了这一限制， 之后应用策略并恢复该模式的原始参数。 Microsoft 在专用设备 Windows IoT 的上下文中描述了 Embedded Mode。 在 Pro 上这样使用并非 Microsoft 确认的支持场景。
恢复临时模式并未删除本地管理注册 和已分配的策略。临时启用该模式在已验证场景之外的 副作用未进行研究。这里描述的是实验原理； 命令、请求内容以及绕过方法的复现步骤不予发布。
| 检查 | 结果和结论边界 |
|---|---|
| 应用禁止策略 | 操作成功，回读确认了状态 |
| 已在运行的进程 | 未自动结束 |
| 禁止状态下重启并登录 | 进程不存在；外壳启动后 153 秒内未记录到其启动 |
| 允许、重启并登录 | 进程出现，创建已由日志确认 |
| 再次禁止并单独结束进程 | 10 秒后进程不存在；120 秒观察期内未发现再次启动 |
| 完全回滚测试平台 | 已通过 VM 快照恢复初始状态并验证 |
样本中只有一台 VM 和一条检查序列。120 秒 间隔内的重复观察不是独立实验。 没有在第二台计算机上进行独立复现。
已确认的内容
Section titled “已确认的内容”- 在已验证场景中，策略阻止了独立进程在重启和登录后的正常启动。
- 反向允许该功能后，同一测试平台上启动恢复。
- 应用策略本身不会关闭已在运行的进程。
- 获得该结果无需替换系统 DLL 或修补 EXE。
被阻止的启动排除了该进程在观察场景中的运行。 这是禁用不必要后台功能的具体效果，即使没有测量 FPS。
未确认的内容
Section titled “未确认的内容”未测量 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。这不是快照回滚的完全等价物：实验室应用策略 创建的本地管理注册会保留，其他工具先前应用的 限制也会保留。还原的详细信息见 设置页面。
公开一手来源
Section titled “公开一手来源”- Microsoft: Connectivity / DisableCrossDeviceResume：策略用途、用户范围和重启；不是我们 VM 结果的证明。
- Microsoft Windows SDK: mdmlocalmanagement.h：本地管理接口的声明；不保证在任何版本上可用。
- Microsoft: Embedded Mode：Windows IoT 上下文；不是关于在 Pro 上受支持应用的说明。
研究和所用工具归 BoosterX 开发者所有， 因此开发者对结果有直接利益。方法和适用边界 已在上文描述，结论可通过公开数据 和所列公开来源进行验证。Microsoft 不是 本研究的作者，也未确认其结论。
检查日期和变更历史
Section titled “检查日期和变更历史”2026-09-17： 第一版；检查了公开来源，发布了一台 VM 的结果、 结论边界和启动反向检查。
2026-09-19： 经独立核对后调整了结论框架：删除了 关于 BoosterX 具体机制的断言。研究检验的是 Windows 公开 MDM 策略及其实验室应用路径，而不是程序中设置的实现； 实验结果、结论边界和来源保持不变， 并明确了已确认效果范围的说明。
2026-09-20： 加强了利益冲突免责声明：明确承认 拥有研究和工具的开发者有直接利益； 缩短了 description。