Cómo desactivar Cross-Device Resume
En esta página
Respuesta breve
Sección titulada «Respuesta breve»Cross-Device Resume se puede desactivar mediante una política MDM de Windows. En nuestro
experimento, tras aplicarla, reiniciar e iniciar sesión,
CrossDeviceResume.exe no se ejecutó durante 153 segundos de observación.
Al volver a permitir la función y reiniciar de nuevo, el proceso reapareció.
Lo más sencillo es aplicar el ajuste mediante BoosterX → Optimización → Tweaks → Cross-Device Resume: seleccionar la desactivación, pulsar «Aplicar» y reiniciar el PC. Este estudio verificaba un mecanismo público de Windows, no la implementación de BoosterX: cómo aplica exactamente el programa el ajuste no se probó en esta serie ni se afirma en el artículo. Los detalles de aplicación y reversión están en la página del ajuste.
Qué se verificó
Sección titulada «Qué se verificó»No solo nos interesaba la desaparición de las notificaciones de Resume, sino también evitar el inicio habitual de su proceso independiente al iniciar sesión en Windows. Son resultados distintos: el programa puede iniciarse y finalizar de inmediato, seguir funcionando sin notificaciones o no recibir ninguna solicitud de inicio.
Microsoft describe DisableCrossDeviceResume como una política de usuario
que desactiva las notificaciones de continuación del trabajo desde el teléfono, e indica la necesidad de
reiniciar. Documentado: la finalidad de la política y el momento de su aplicación.
Observado en nuestro experimento: la ausencia de inicio del proceso independiente.
Descripción de Microsoft.
Ámbito del estudio
Sección titulada «Ámbito del estudio»| Condición | Entorno verificado |
|---|---|
| Sistema | Windows 11 Pro 25H2, compilación 26200.9445 |
| Componente | CrossDeviceResume 2607.27000.0.0 |
| Banco de pruebas | Una máquina virtual VMware |
| Escenario | Reinicio e inicio de sesión interactivo del mismo usuario |
| Observación | Lista de procesos y auditoría de su creación, eventos 4688 |
| Fecha del experimento | 2026-09-17 |
Es un experimento funcional, no una prueba de FPS ni de consumo de memoria. El modelo de CPU física, la configuración de recursos virtuales y las versiones de controladores no se incluyen en la muestra publicada. No se puede trasladar el resultado a PC físicos, otras compilaciones ni otras formas de inicio sin verificarlo.
Cómo se realizó la verificación
Sección titulada «Cómo se realizó la verificación»Primero se registró el proceso en ejecución y el estado inicial de la política. Después se aplicó la política de bloqueo mediante el mecanismo local de administración de Windows, se comprobó el éxito de la operación y se leyó el estado de vuelta. Tras el reinicio se esperó al inicio de sesión interactivo y al arranque del shell, y se comprobaron los procesos y el registro de su creación.
Para el control inverso se permitió Resume y se repitió el reinicio con inicio de sesión. Por separado se volvió a bloquear la función, se finalizó explícitamente el proceso ya en ejecución y se observó un posible reinicio. La finalización del proceso fue una acción independiente y no puede atribuirse a la política.
Por qué una entrada en el registro aún no demuestra la desactivación
Sección titulada «Por qué una entrada en el registro aún no demuestra la desactivación»La presencia del valor necesario en el registro no confirma que Windows lo haya aceptado como una política MDM vigente. Por eso, la situación «el valor está escrito, pero CrossDeviceResume sigue iniciándose» no contradice el resultado de este estudio.
En la documentación publicada de esta política no hay una correspondencia directa con un ajuste normal del Registry. En nuestra serie no hay una comparación controlada independiente de todas las variantes de escritura directa. La escritura directa no está confirmada como sustituto de la aplicación de la política, pero tampoco hay motivos para afirmar que cualquier modificación del registro sea siempre inútil. El resultado funcional se obtuvo mediante el mecanismo de administración de políticas, con verificación del estado y del inicio real tras el inicio de sesión.
El papel de la DLL del sistema y del rodeo de laboratorio
Sección titulada «El papel de la DLL del sistema y del rodeo de laboratorio»En el experimento se utilizó la mdmlocalmanagement.dll integrada. Proporciona
una interfaz de administración local: RegisterDeviceWithLocalManagement y
ApplyLocalManagementSyncML. Sus declaraciones están disponibles en el
encabezado público del Windows SDK.
La biblioteca del sistema aceptaba la solicitud de aplicación de la política; no fue necesario descargar
DLL de terceros, sustituir archivos de Windows ni parchear código ejecutable.
Intune y la administración en la nube no se utilizaron en el experimento.
El registro local normal en la Windows Pro verificada devolvió «no compatible». En el laboratorio se pudo superar esta limitación activando temporalmente el Embedded Mode, tras lo cual se aplicó la política y se restauró el parámetro original del modo. Microsoft describe Embedded Mode en el contexto de dispositivos especializados Windows IoT. Tal uso en Pro no es un escenario de soporte confirmado por Microsoft.
La restauración del modo temporal no eliminó el registro local de administración ni la política asignada. Los efectos secundarios de la activación temporal del modo fuera del escenario verificado no se investigaron. Aquí se describe el principio del experimento; los comandos, el contenido de la solicitud y la secuencia de reproducción del rodeo no se publican.
Resultados
Sección titulada «Resultados»| Verificación | Resultado y límite de la conclusión |
|---|---|
| Aplicación de la política de bloqueo | Operación exitosa, la lectura inversa confirmó el estado |
| Proceso ya en ejecución | No finalizó automáticamente |
| Reinicio e inicio de sesión con bloqueo | El proceso no estaba presente; en 153 segundos tras el arranque del shell no se registró su inicio |
| Permiso, reinicio e inicio de sesión | El proceso apareció, la creación confirmada por el registro |
| Bloqueo repetido y finalización independiente del proceso | A los 10 segundos el proceso no estaba presente; no se detectó un reinicio en 120 segundos de observación |
| Reversión completa del banco de pruebas | El estado inicial se restauró con una instantánea de la VM y se verificó |
En la muestra hay una VM y una secuencia de verificaciones. Las observaciones repetidas dentro del intervalo de 120 segundos no son experimentos independientes. No hay reproducción independiente en un segundo equipo.
Qué está confirmado
Sección titulada «Qué está confirmado»- En el escenario verificado, la política evitó el inicio habitual del proceso independiente tras el reinicio y el inicio de sesión.
- Volver a permitir la función devolvió el inicio en el mismo banco de pruebas.
- La aplicación de la política por sí sola no cierra un proceso ya en ejecución.
- Para el resultado obtenido no se necesitaron sustituir DLL del sistema ni parchear el EXE.
El inicio evitado excluye el funcionamiento de este proceso en el escenario observado. Es un efecto concreto de desactivar una función en segundo plano innecesaria, incluso sin medir FPS.
Qué no está confirmado
Sección titulada «Qué no está confirmado»No se midieron el aumento de FPS, el cambio de frametime, la carga total de CPU ni el ahorro de RAM.
No se verificaron el inicio manual del EXE, todas las formas alternativas de activación, la ubicación
de Resume dentro de ShellHost ni el funcionamiento desde otra cuenta o SYSTEM.
No hubo una prueba pareada independiente de la aplicación mediante la interfaz lista de BoosterX en esta
serie: la tabla describe el mecanismo de laboratorio de Windows.
Limitaciones
Sección titulada «Limitaciones»En la fecha de la verificación, Microsoft marca la política como aplicable a Windows Insider Preview. La observación en la Windows 11 Pro 25H2 indicada no sustituye la matriz oficial de soporte. La verificación en otra VM prevista no se realizó, por lo que no hay resultados para ella. La ausencia de eventos durante 153 segundos no significa la prohibición de cualquier inicio para siempre: el efecto confirmado se refiere al inicio habitual tras el reinicio y el inicio de sesión, y el inicio del proceso por otras vías no fue estudiado en esta investigación.
El artículo no establece de qué manera aplica BoosterX su ajuste. La relación entre la tarjeta de BoosterX y la política MDM verificada aquí no formaba parte del plan del experimento; un juicio sobre si el programa utiliza este mismo mecanismo requiere una verificación independiente basada en el comportamiento real de la aplicación.
La desactivación se refiere a Resume. No puede describirse como la desactivación de toda la «Vinculación con el teléfono» ni de toda la infraestructura entre dispositivos de Windows.
Conclusión práctica
Sección titulada «Conclusión práctica»Si no utilizas la continuación del trabajo desde el teléfono, desactivar Resume está justificado. En el banco de pruebas verificado, la política MDM permitió evitar su inicio habitual. Para el usuario es más sencillo elegir el ajuste existente en BoosterX y reiniciar el PC que experimentar manualmente con el almacén de políticas. Verifica el resultado en tu versión de Windows.
Restauración del estado
Sección titulada «Restauración del estado»En el experimento, permitir la función y reiniciar de nuevo devolvió el inicio del proceso. Después se restauró por completo la VM desde la instantánea inicial: se verificó la ausencia de la política asignada durante la verificación, el estado inicial del modo, la cancelación del inicio de sesión automático temporal y el retorno del proceso.
En BoosterX, activar en la misma tarjeta permite Resume tras la aplicación y el reinicio. No es un análogo completo de la reversión de la instantánea: el registro local de administración, creado por la aplicación de laboratorio de la política, se conserva, igual que las restricciones previamente aplicadas de otras herramientas. Los detalles de la reversión se indican en la página del ajuste.
Fuentes primarias públicas
Sección titulada «Fuentes primarias públicas»- Microsoft: Connectivity / DisableCrossDeviceResume: finalidad de la política, ámbito de usuario y reinicio; no es prueba de los resultados de nuestra VM.
- Microsoft Windows SDK: mdmlocalmanagement.h: declaraciones de la interfaz de administración local; no es una promesa de disponibilidad en cualquier edición.
- Microsoft: Embedded Mode: contexto de Windows IoT; no es una instrucción de aplicación compatible en Pro.
La investigación y las herramientas utilizadas pertenecen al desarrollador de BoosterX, por lo que el desarrollador tiene un interés directo en los resultados. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones pueden verificarse con los datos abiertos y las fuentes públicas enumeradas. Microsoft no es el autor de la investigación ni ha confirmado sus conclusiones.
Fecha de verificación e historial de cambios
Sección titulada «Fecha de verificación e historial de cambios»2026-09-17: primera versión; verificadas las fuentes públicas, publicados los resultados de una VM, los límites de la conclusión y la verificación inversa del inicio.
2026-09-19: tras una revisión independiente se corrigió el marco de la conclusión: se eliminó la afirmación sobre el mecanismo concreto de BoosterX. La investigación verifica la política MDM pública de Windows y la vía de laboratorio para aplicarla, no la implementación del ajuste en el programa; los resultados del experimento, los límites de la conclusión y las fuentes se conservan, y se precisaron las salvedades sobre los límites del efecto confirmado.
2026-09-20: se reforzó el descargo de responsabilidad sobre el conflicto de intereses: se reconoce explícitamente el interés directo del desarrollador, a quien pertenecen la investigación y las herramientas; se acortó la description.