Como desativar o Cross-Device Resume

Resposta curta

O Cross-Device Resume pode ser desativado por meio de uma política MDM do Windows. Em nosso experimento, após sua aplicação, reinicialização e login no sistema, CrossDeviceResume.exe não foi iniciado durante 153 segundos de observação. Ao permitir novamente o recurso e reiniciar outra vez, o processo reapareceu.

É mais simples aplicar a configuração pelo BoosterX → Otimização → Tweaks → Cross-Device Resume: selecionar a desativação, clicar em «Aplicar» e reiniciar o PC. Este estudo verificou um mecanismo público do Windows, e não a implementação do BoosterX: como exatamente o programa aplica a configuração não foi testado nesta série e não se afirma isso no artigo. Detalhes de aplicação e reversão estão na página da configuração.

O que verificamos

Interessava-nos não apenas o desaparecimento das notificações do Resume, mas também a prevenção do início padrão de seu processo separado no login do Windows. São resultados diferentes: o programa pode iniciar e encerrar imediatamente, continuar em execução sem notificações ou simplesmente não receber solicitação de início.

A Microsoft descreve o DisableCrossDeviceResume como uma política de usuário que desativa as notificações de continuação do trabalho pelo telefone, e indica a necessidade de reinicialização. Documentado: a finalidade da política e o momento de aplicação. Observado em nosso experimento: a ausência de início do processo separado. Descrição da Microsoft.

Escopo do estudo

Condição	Ambiente verificado
Sistema	Windows 11 Pro 25H2, build 26200.9445
Componente	CrossDeviceResume 2607.27000.0.0
Bancada	Uma máquina virtual VMware
Cenário	Reinicialização e login interativo do mesmo usuário
Observação	Lista de processos e auditoria de sua criação, eventos 4688
Data do experimento	2026-09-17

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

Como foi feita a verificação

Primeiro registramos o processo em execução e o estado inicial da política. Em seguida aplicamos a política de proibição por meio do mecanismo local de gerenciamento do Windows, verificamos o sucesso da operação e lemos o estado de volta. Após a reinicialização, aguardamos o login interativo e o início do funcionamento do shell, verificamos os processos e o log de sua criação.

Para o controle inverso, permitimos o Resume e repetimos a reinicialização com login. Separadamente, proibimos o recurso novamente, encerramos explicitamente o processo já em execução e observamos um possível novo início. O encerramento do processo foi uma ação independente, não se pode atribuí-lo à política.

Por que uma entrada no registro ainda não prova a desativação

A presença do número necessário no registro não confirma que o Windows o aceitou como uma política MDM vigente. Por isso, a situação «valor gravado, mas o CrossDeviceResume continua sendo iniciado» não contradiz o resultado deste estudo.

Na documentação publicada dessa política não há uma correspondência pronta com uma configuração comum do Registry. Em nossa série não há uma comparação controlada separada de todas as variantes de gravação direta. A gravação direta não foi confirmada como substituta da aplicação da política, mas também não há fundamento para afirmar que qualquer alteração no registro é sempre inútil. O resultado funcional foi obtido por meio do mecanismo de gerenciamento de políticas, com verificação do estado e do início efetivo após o login.

O papel da DLL do sistema e do contorno laboratorial

No experimento utilizamos a mdmlocalmanagement.dll integrada. Ela fornece a interface de gerenciamento local: RegisterDeviceWithLocalManagement e ApplyLocalManagementSyncML. Suas declarações estão disponíveis no cabeçalho público do Windows SDK. A biblioteca do sistema aceitou a solicitação de aplicação da política; não foi necessário baixar DLLs de terceiros, substituir arquivos do Windows ou aplicar patch no código executável. Intune e gerenciamento em nuvem não foram usados no experimento.

O registro local comum na Windows Pro verificada retornou «não suportado». No laboratório foi possível superar essa limitação com a ativação temporária do 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. Esse uso em Pro não é um cenário de suporte confirmado pela Microsoft.

A restauração do modo temporário não removeu o registro local de gerenciamento nem a política atribuída. Os efeitos colaterais da ativação temporária do modo fora do cenário verificado não foram investigados. Aqui se descreve o princípio do experimento; os comandos, o conteúdo da solicitação 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 execução	Não foi encerrado automaticamente
Reinicialização e login com proibição	O processo estava ausente; em 153 segundos após o início do shell não foi registrado seu início
Permissão, reinicialização e login	O processo apareceu, a criação foi confirmada pelo log
Nova proibição e encerramento separado do processo	Após 10 segundos o processo estava ausente; não foi detectado novo início em 120 segundos de observação
Reversão completa da bancada	O estado inicial foi restaurado pelo 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 em um segundo computador.

O que foi confirmado

• No cenário verificado, a política impediu o início padrão do processo separado após a reinicialização e o login.
• A permissão inversa do recurso devolveu o início na mesma bancada.
• A aplicação da política por si só não encerra um processo já em execução.
• Para o resultado obtido não foram necessárias a substituição de DLLs do sistema nem patch no EXE.

O início impedido exclui o funcionamento desse processo no cenário observado. É um efeito concreto da desativação de um recurso em segundo plano desnecessário, mesmo sem medição de FPS.

O que não foi confirmado

Não foram medidos ganho de FPS, alteração de frametime, carga total de CPU e economia de RAM. Não foram verificados o início 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, nesta série, um teste pareado separado de aplicação pelo interface pronto do BoosterX: a tabela descreve o mecanismo laboratorial do Windows.

Limitações

Na data da verificação, a Microsoft marca 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 em outra VM planejada não ocorreu, portanto não há resultados para ela. A ausência de eventos por 153 segundos não significa a proibição de quaisquer inícios para sempre: o efeito confirmado diz respeito ao início padrão após a reinicialização e o login, e o início do processo por outras formas não foi estudado neste estudo.

O artigo não estabelece de que maneira o BoosterX aplica sua configuração. A relação entre o cartão do BoosterX e a política MDM aqui verificada não fazia parte do plano do experimento; um juízo sobre se o programa usa esse mesmo mecanismo exige verificação separada pelo comportamento real do aplicativo.

A desativação diz respeito ao Resume. Não se pode descrevê-la como desativação de toda a «Conexão com o telefone» ou de toda a infraestrutura entre dispositivos do Windows.

Conclusão prática

Se você não usa a continuação do trabalho pelo telefone, a desativação do Resume é justificada. Na bancada verificada, a política MDM permitiu evitar seu início padrão. Para o usuário, é mais simples escolher a configuração existente no BoosterX e reiniciar o PC do que experimentar manualmente com o repositório de políticas. Verifique o resultado na sua versão do Windows.

Restauração do estado

No experimento, a permissão do recurso e a nova reinicialização devolveram o início do processo. Em seguida, 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 login automático temporário e o retorno do processo.

No BoosterX, a ativação no mesmo cartão permite o Resume após a aplicação e a reinicialização. Isso não é um análogo completo da reversão por snapshot: o registro local de gerenciamento, criado pela aplicação laboratorial da política, permanece, assim como as restrições previamente aplicadas de outras ferramentas. Os detalhes da reversão estão na página da configuração.

Fontes primárias públicas

• Microsoft: Connectivity / DisableCrossDeviceResume: finalidade da política, escopo de usuário e reinicialização; não é prova dos resultados da nossa VM.
• Microsoft Windows SDK: mdmlocalmanagement.h: declarações da interface de gerenciamento local; não é promessa de disponibilidade em qualquer edição.
• Microsoft: Embedded Mode: contexto do Windows IoT; não é instrução de aplicação suportada em Pro.

O estudo e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, portanto o desenvolvedor tem interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas listadas. A Microsoft não é autora do estudo e não confirmou 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 início.

2026-09-19: após conferência independente, o enquadramento da conclusão foi corrigido: removida a afirmação sobre o mecanismo específico do BoosterX. O estudo verifica a política MDM pública do Windows e o caminho laboratorial de sua aplicação, e não a implementação da configuração no programa; os resultados do experimento, os limites da conclusão e as fontes foram preservados, e as ressalvas sobre os limites do efeito confirmado foram esclarecidas.

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