Como desativar o Cross-Device Resume

Resposta curta

O Cross-Device Resume pode ser desativado através de uma política MDM do Windows. No nosso experimento, após a sua aplicação, reinício e início de sessão, CrossDeviceResume.exe não foi iniciado durante 153 segundos de observação. Ao permitir novamente a funcionalidade e reiniciar outra vez, o processo voltou a aparecer.

É mais simples aplicar a definição através de BoosterX → Otimização → Tweaks → Cross-Device Resume: selecionar a desativação, clicar em «Aplicar» e reiniciar o PC. Este estudo testou um mecanismo público do Windows, não a implementação do BoosterX: a forma exata como o programa aplica a definição não foi testada nesta série e não é afirmada no artigo. Os detalhes de aplicação e reversão estão na página da definição.

O que foi testado

Interessou-nos não só o desaparecimento das notificações do Resume, mas também a prevenção do arranque normal do seu processo separado ao iniciar sessão no Windows. São resultados diferentes: o programa pode iniciar-se e terminar logo de seguida, continuar a funcionar sem notificações ou simplesmente não receber qualquer pedido de arranque.

A Microsoft descreve o DisableCrossDeviceResume como uma política de utilizador que desativa as notificações de continuação do trabalho a partir do telefone, e indica a necessidade de reiniciar. Documentado: a finalidade da política e o momento de aplicação. Observado no nosso experimento: a ausência de arranque do processo separado. Descrição da Microsoft.

Âmbito do estudo

Condição	Ambiente testado
Sistema	Windows 11 Pro 25H2, compilação 26200.9445
Componente	CrossDeviceResume 2607.27000.0.0
Bancada	Uma máquina virtual VMware
Cenário	Reinício e início de sessão interativo do mesmo utilizador
Observação	Lista de processos e auditoria da sua criação, eventos 4688
Data do experimento	2026-09-17

Este é um experimento funcional, não um teste de FPS ou de consumo de memória. O modelo do CPU físico, a configuração dos recursos virtuais e as versões dos drivers não estão incluídos na amostra publicada. Não se pode transferir o resultado para PCs físicos, outras compilações ou outras formas de arranque sem verificação.

Como foi feita a verificação

Primeiro registou-se o processo em funcionamento e o estado inicial da política. Depois aplicou-se a política de proibição através do mecanismo local de gestão do Windows, verificou-se o sucesso da operação e leu-se o estado de volta. Após o reinício, aguardou-se o início de sessão interativo e o arranque da shell, verificaram-se os processos e o registo da sua criação.

Para o controlo inverso, permitiu-se o Resume e repetiu-se o reinício com início de sessão. Separadamente, voltou-se a proibir a funcionalidade, terminou-se explicitamente o processo já em funcionamento e observou-se um possível novo arranque. A terminação do processo foi uma ação autónoma, não pode ser atribuída à política.

Porque é que o registo no Registry ainda não prova a desativação

A presença do número necessário no Registry não confirma que o Windows o tenha aceite como uma política MDM em vigor. Por isso, a situação «valor escrito, mas o CrossDeviceResume continua a iniciar-se» não contradiz o resultado deste estudo.

Na documentação publicada desta política não existe uma correspondência pronta para uma definição normal do Registry. Na nossa série não há uma comparação controlada separada de todas as variantes de escrita direta. A escrita direta não está confirmada como substituto da aplicação da política, mas também não há fundamento para afirmar que qualquer alteração ao Registry é sempre inútil. O resultado funcional foi obtido através do mecanismo de gestão de políticas, com verificação do estado e do arranque efetivo após o início de sessão.

O papel da DLL do sistema e do contorno laboratorial

No experimento utilizou-se a mdmlocalmanagement.dll incorporada. Esta fornece uma interface de gestão local: RegisterDeviceWithLocalManagement e ApplyLocalManagementSyncML. As suas declarações estão disponíveis no cabeçalho público do Windows SDK. A biblioteca do sistema aceitou o pedido de aplicação da política; não foi necessário descarregar DLL de terceiros, substituir ficheiros do Windows ou aplicar patches ao código executável. O Intune e a gestão na cloud não foram utilizados na experiência.

O registo local normal na Windows Pro testada devolveu «não suportado». No laboratório foi possível ultrapassar esta limitação ativando temporariamente o Embedded Mode, após o que se aplicou a política e se restaurou o parâmetro original do modo. A Microsoft descreve o Embedded Mode no contexto de dispositivos especializados Windows IoT. Essa utilização em Pro não é um cenário de suporte confirmado pela Microsoft.

A restauração do modo temporário não removeu o registo local de gestão nem a política atribuída. Os efeitos secundários da ativação temporária do modo fora do cenário testado não foram investigados. Aqui descreve-se o princípio do experimento; os comandos, o conteúdo do pedido e a sequência de reprodução do contorno não são publicados.

Resultados

Verificação	Resultado e limite da conclusão
Aplicação da política de proibição	Operação bem-sucedida, a leitura de volta confirmou o estado
Processo já em funcionamento	Não terminou automaticamente
Reinício e início de sessão com proibição	O processo estava ausente; nos 153 segundos após o arranque da shell não se registou nenhum arranque seu
Permissão, reinício e início de sessão	O processo apareceu, a criação confirmada pelo registo
Nova proibição e terminação separada do processo	Após 10 segundos o processo estava ausente; não se detetou novo arranque durante 120 segundos de observação
Reversão completa da bancada	Estado inicial restaurado com um snapshot da VM e verificado

Na amostra há uma VM e uma sequência de verificações. Observações repetidas dentro do intervalo de 120 segundos não são experimentos independentes. Não há reprodução independente num segundo computador.

O que está confirmado

• No cenário testado, a política impediu o arranque normal do processo separado após o reinício e o início de sessão.
• A permissão inversa da funcionalidade devolveu o arranque na mesma bancada.
• A aplicação da política por si só não fecha um processo já em funcionamento.
• Para o resultado obtido não foram necessárias a substituição de DLL do sistema nem um patch ao EXE.

O arranque impedido exclui o funcionamento desse processo no cenário observado. Este é um efeito concreto da desativação de uma funcionalidade em segundo plano desnecessária, mesmo sem medir FPS.

O que não está confirmado

Não foram medidos o aumento de FPS, a alteração do frametime, a carga total do CPU e a poupança de RAM. Não foram testados o arranque manual do EXE, todas as formas alternativas de ativação, a colocação do Resume dentro do ShellHost e o funcionamento a partir de outra conta ou do SYSTEM. Não houve um ensaio emparelhado separado da aplicação através da interface pronta do BoosterX nesta série: a tabela descreve o mecanismo laboratorial do Windows.

Limitações

Na data da verificação, a Microsoft assinala a política como aplicável ao Windows Insider Preview. A observação na referida Windows 11 Pro 25H2 não substitui a matriz oficial de suporte. A verificação numa outra VM planeada não se realizou, por isso não há resultados para ela. A ausência de eventos durante 153 segundos não significa a proibição de quaisquer arranques para sempre: o efeito confirmado diz respeito ao arranque normal após o reinício e o início de sessão, e o arranque do processo por outras formas não foi estudado neste estudo.

O artigo não estabelece de que forma o BoosterX aplica a sua definição. A relação entre o cartão do BoosterX e a política MDM aqui testada não fazia parte do plano do experimento; um juízo sobre se o programa utiliza este mesmo mecanismo exige uma verificação separada com base no comportamento efetivo da aplicação.

A desativação diz respeito ao Resume. Não pode ser descrita como a desativação de toda a «Ligação ao telefone» ou de toda a infraestrutura interdispositivos do Windows.

Conclusão prática

Se não utiliza a continuação do trabalho a partir do telefone, a desativação do Resume é justificada. Na bancada testada, a política MDM permitiu evitar o seu arranque normal. Para o utilizador é mais simples escolher a definição existente no BoosterX e reiniciar o PC do que experimentar manualmente com o armazenamento de políticas. Verifique o resultado na sua versão do Windows.

Restauração do estado

No experimento, a permissão da funcionalidade e um novo reinício devolveram o arranque do processo. Depois a VM foi totalmente restaurada a partir do snapshot inicial: verificou-se a ausência da política atribuída durante a verificação, o estado inicial do modo, o cancelamento do início de sessão automático temporário e o regresso do processo.

No BoosterX, a ativação no mesmo cartão permite o Resume após a aplicação e o reinício. Isto não é um equivalente completo da reversão por snapshot: o registo local de gestão, criado pela aplicação laboratorial da política, mantém-se, tal como as restrições previamente aplicadas de outras ferramentas. Os detalhes da reversão são apresentados na página da definição.

Fontes primárias públicas

• Microsoft: Connectivity / DisableCrossDeviceResume: finalidade da política, âmbito de utilizador e reinício; não é prova dos resultados da nossa VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: declarações da interface de gestão local; não é uma promessa de disponibilidade em qualquer edição.
• Microsoft: Embedded Mode: contexto do Windows IoT; não é uma instrução de aplicação suportada em Pro.

O estudo e as ferramentas utilizadas pertencem ao programador do BoosterX, por isso o programador tem um interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas através dos dados abertos e das fontes públicas enumeradas. A Microsoft não é autora do estudo e não confirmou as suas conclusões.

Data da verificação e histórico de alterações

2026-09-17: primeira versão; fontes públicas verificadas, publicados os resultados de uma VM, os limites da conclusão e a verificação inversa do arranque.

2026-09-19: após uma revisão independente, corrigiu-se o enquadramento da conclusão: retirou-se a afirmação sobre o mecanismo concreto do BoosterX. O estudo verifica a política MDM pública do Windows e o caminho laboratorial da sua aplicação, e não a implementação da definição no programa; os resultados do experimento, os limites da conclusão e as fontes foram mantidos, e as ressalvas sobre os limites do efeito confirmado foram precisadas.

2026-09-20: o aviso de conflito de interesses foi reforçado: reconhece-se explicitamente o interesse direto do programador, a quem pertencem o estudo e as ferramentas; a description foi encurtada.