O computador novo recusava o Windows 11 — e a culpa era da mudança que correu bem

O contexto: um cliente com uma máquina inutilizável

Um cliente contactou-nos com uma queixa que conhecemos bem: o computador já não ligava corretamente e, quando lá chegava, trabalhava de forma tão lenta que o tornava praticamente inútil para o dia a dia. Nada de produtivo se conseguia fazer naquela máquina.

Agendamos uma visita e, no local, fizemos a análise ao equipamento. O diagnóstico foi claro: o computador ainda tinha um processador Pentium Dual-Core, 8 GB de RAM e um SSD de 240 GB. Ou seja, mesmo já com disco SSD — que normalmente é o maior salto de desempenho que se pode dar a uma máquina antiga —, o equipamento arrastava-se. O estrangulamento não estava no disco; estava no processador e na memória, demasiado fracos para o que o cliente precisava.

Perante isto, a recomendação foi honesta: não valia a pena continuar a investir numa base que não dava mais. Propusemos um upgrade de máquina — um equipamento HP com processador Intel Core i7 de 9.ª geração, 16 GB de RAM, e a substituir o SSD SATA por um disco NVMe de 512 GB, bastante mais rápido. O cliente aprovou a proposta.

O passo seguinte foi preservar o trabalho do cliente. Em vez de reinstalar tudo de raiz e obrigá-lo a reconfigurar programas e definições, executámos uma cópia fiel (clonagem) de todas as informações do equipamento antigo para o novo. A máquina antiga corria Windows 10, e foi esse sistema, com tudo dentro, que migramos para o hardware novo.

E é aqui que começa a parte interessante. O hardware novo é mais do que capaz de correr o Windows 11 — o i7 de 9.ª geração passa com folga o requisito mínimo de CPU (Intel 8.ª geração). O objetivo natural era, então, atualizar para o Windows 11 Pro. Mas a clonagem, por mais cómoda que seja, deixa rastos — e foi um desses rastos que travou o upgrade.

O primeiro obstáculo

O Windows 11 exige arranque em UEFI com Secure Boot, e o Secure Boot só funciona com o disco em esquema GPT. Discos clonados a partir de máquinas mais antigas vêm frequentemente em MBR com arranque Legacy/BIOS — e, como o sistema tinha sido copiado de um equipamento com vários anos, era exatamente o caso aqui.

A boa notícia é que a Microsoft fornece uma ferramenta para converter MBR em GPT sem perder dados: o mbr2gpt. O primeiro comando é sempre o de validação, que não altera nada e apenas verifica se o disco está apto a converter.

Num CMD aberto como administrador:

mbr2gpt /validate /allowFullOS

O resultado foi este:

MBR2GPT: Validating layout, disk sector size is: 512 bytes

Cannot find OS partition(s) for disk 0

Tradução: o mbr2gpt diz que não consegue encontrar a partição do sistema operativo. O que é estranho, porque o Windows arrancava sem qualquer problema. Se não houvesse partição do SO, a máquina nem ligava.

Aqui está a primeira lição: este erro raramente significa que falta a partição. Significa quase sempre que algo no mapeamento de arranque está inconsistente — e a clonagem é a suspeita número um.

O diagnóstico

Antes de mexer em seja o que for, é preciso perceber a causa. O mbr2gpt regista os erros num ficheiro de log próprio. Para o ler:

type %windir%\setuperr.log

*(Nota: a variável correta é %windir%, não %win% — um lapso fácil de cometer.)*

O log foi esclarecedor:

GetOSDeviceVolume: Cannot get NT path for entry. [gle=0x000000ea]

FindOSPartitions: Cannot get volume name for the recovery boot entry. Error: 0x000000EA

Cannot find OS partition(s) for disk 0 [gle=0x000000ea]

A linha do meio é a chave: o problema não está na partição do sistema, está numa entrada de recovery do BCD (Boot Configuration Data). O mbr2gpt percorre todas as entradas do BCD para mapear as partições do disco. Quando chega a uma entrada de recovery que aponta para um volume inexistente, não consegue resolvê-la e aborta a operação inteira.

Para ver o conteúdo do BCD:

bcdedit /enum all

E ali estava a confirmação. Existiam duas entradas do tipo "Windows Recovery Environment" com o seguinte aspeto:

device    ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{...}

osdevice  ramdisk=[unknown]\Recovery\WindowsRE\Winre.wim,{...}

O [unknown] é a prova definitiva. Estas entradas apontavam para a partição de recovery de um disco que já não existe. E havia duas, com GUIDs de datas diferentes — sinal de que o sistema do cliente já arrastava este histórico do próprio equipamento antigo, e que a nossa clonagem o trouxe fielmente para o hardware novo, fantasmas incluídos. A cópia foi fiel ao ponto de copiar também os problemas que lá estavam.

A entrada do Windows real estava intacta, com osdevice partition=C:. Por isso o sistema arrancava normalmente. O problema eram apenas os fantasmas das clonagens anteriores.

A resolução

A solução é limpar as entradas de recovery órfãs. É uma operação segura desde que se identifiquem corretamente as entradas a apagar — e este é o ponto onde é preciso ter cuidado.

Aviso importante — Antes de tocar no BCD, faça uma imagem completa do disco (Macrium Reflect ou equivalente). Apagar a entrada errada pode deixar a máquina sem arranque. Apague apenas entradas que cumpram as duas condições em simultâneo: description = Windows Recovery Environment e device = ramdisk=[unknown]. Nunca apague a entrada que tem osdevice partition=C: — essa é o seu Windows.

Primeiro, tentar desativar o WinRE de forma limpa (a Microsoft recomenda este passo antes do mbr2gpt):

reagentc /disable

Se falhar — e neste caso falhou, porque a localização registada estava inválida — não há problema. Avança-se na mesma.

De seguida, apagar as entradas órfãs identificadas (substitua os GUIDs pelos que aparecem no seu bcdedit /enum all):

bcdedit /delete {5b0a02db-5cdc-11e8-8269-b3b750155262}

bcdedit /delete {9d4adeb7-20df-11eb-9f09-eba0d32a6aa0}

Confirmar que ficaram limpas:

bcdedit /enum all

Já não deve aparecer nenhuma entrada com ramdisk=[unknown].

Por fim, repetir a validação:

mbr2gpt /validate /allowFullOS

Desta vez:

MBR2GPT: Validation completed successfully

A porta estava aberta.

A conversão para GPT

Com a validação a passar, e com a imagem de backup confirmada e acessível, executa-se a conversão. Este passo é irreversível.

mbr2gpt /convert /allowFullOS

O processo correu todas as etapas:

MBR2GPT: Trying to shrink the OS partition
MBR2GPT: Creating the EFI system partition
MBR2GPT: Installing the new boot files
MBR2GPT: Performing the layout conversion
MBR2GPT: Migrating default boot entry
MBR2GPT: Conversion completed successfully

Apareceu também um aviso de que não foi possível atualizar o ReAgent.xml — resíduo do mesmo WinRE mal configurado. Não afeta o arranque nem o upgrade; resolve-se no fim.

A linha decisiva é a última que o mbr2gpt mostra:

Before the new system can boot properly you need to switch the firmware to boot to UEFI mode!

Não reinicie normalmente neste ponto. O disco já está em GPT, mas a firmware ainda está configurada para arranque Legacy. Se reiniciar sem ajustar a BIOS, o sistema não arranca. Isto é esperado e não é avaria.

Configurar a BIOS

Reiniciar e, no arranque, premir F10 repetidamente para entrar na BIOS da HP (em alguns modelos prime-se primeiro Esc para abrir o menu de startup). A sequência:

1. Em Boot Options (ou "Boot Mode"), desativar o Legacy Support / CSM e deixar apenas UEFI.

2. Em Security, ativar o TPM — nas máquinas HP com Intel aparece normalmente como "Intel PTT" ou "TPM Device". Colocar em Enabled.

3. Ativar o Secure Boot.

4. Guardar e sair com F10.

O Windows 10 deve arrancar agora normalmente, já em modo UEFI.

Para confirmar, abrir msinfo32 e verificar em "Resumo do Sistema":

• Modo da BIOS: UEFI
• Estado do Arranque Seguro: Ativado

O passo final: recriar o WinRE

Antes de avançar para o Windows 11, fecha-se o cabo solto do recovery. Os comandos abaixo desativam e recriam o WinRE de forma limpa, eliminando os resíduos das clonagens:

reagentc /disable

reagentc /enable

reagentc /info

O reagentc /info deve agora mostrar o Windows RE como "Enabled" e com uma localização válida.

O upgrade para o Windows 11

Com o disco em GPT, TPM 2.0 ativo, Secure Boot ligado e o WinRE recriado, todos os requisitos estão cumpridos. A partir daqui o upgrade é direto e mantém tudo — programas, ficheiros e definições — através do Windows 11 Installation Assistant ou da ISO oficial, correndo o setup.exe por dentro do Windows já arrancado.

No nosso caso, a máquina nova do cliente ficou a correr o Windows 11 Pro sem reinstalação e sem perda de dados — com todo o trabalho, programas e definições preservados do equipamento antigo, agora num hardware capaz de acompanhar o ritmo de quem o usa.

O que fica deste caso

O erro "Cannot find OS partition(s)" raramente é o que parece. Em máquinas com sistema clonado, é quase uma assinatura de entradas de recovery órfãs no BCD. O caminho é sempre o mesmo: ler o log, identificar a causa, limpar com cirurgia e só depois converter — nunca às cegas.

E acima de tudo: backup antes de qualquer passo irreversível. Não é formalidade, é o que separa uma intervenção bem-sucedida de um dia muito mau.

Na Equipetec ajudamos empresas e particulares a manter os seus sistemas atualizados, seguros e a funcionar sem sobressaltos. Se tem máquinas a precisar de migração para o Windows 11, ou se um upgrade lhe correu mal, fale connosco.

Assistência Informática ao Domicílio → · Suporte TI para Empresas →