如何停用 Cross-Device Resume
本頁內容
Cross-Device Resume 可以透過 Windows 的 MDM 原則停用。 在我們的
實驗中，套用該原則、重新開機並登入系統後，
CrossDeviceResume.exe 在 153 秒的觀察期間內並未啟動。
當功能被重新允許並再次重新開機後，該處理程序又再次出現。
更簡單的方式是透過 BoosterX → 最佳化 → 微調 → Cross-Device Resume 套用設定： 選擇停用，按下 「套用」，然後重新開機。 本研究檢驗的是 Windows 的公開機制，而非 BoosterX 的實作方式： 程式究竟如何套用設定，並未在本系列中測試， 本文也不作此主張。套用與還原的詳細說明請見 設定頁面。
我們檢驗了什麼
Section titled “我們檢驗了什麼”我們關注的不只是 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 在專用裝置的情境中描述了 Embedded Mode Windows IoT。 在 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。