Após a atualização do Windows 7 para o Windows 10, o sistema acha que a partição GPT é MBR

Question

Eu tenho um sistema Windows 7 com 3 discos rígidos - Disco 0 é o disco de inicialização formatado com MBR, Disco 1 é um disco de 4 TB formatado com GPT e Disco 2 é um disco de 2 TB também formatado com GPT. p>

O disco 1 tem uma partição grande com letra de unidade Q: atribuída a ela.

Eu atualizei o sistema para o Windows 10. No Windows 10, no entanto, letra de unidade Q: não aparece. Gerenciamento de disco no Windows 10 acha que o disco agora está formatado com MBR. Ele relata duas partições nesse disco, sendo a primeira "Saudável (GPT Protective Partition)" de tamanho 2048 GB e a segunda sendo "Não alocado" de tamanho de remianing.

Se eu usar o diskpart em um Prompt de Comando no Windows 10, o diskpart reportará o disco como MBR (não GPT).

Se eu usar o diskpart em um Prompt de Comando após inicializar no Modo de Segurança usando um disco de reparo do Windows 7, o diskpart reportará o disco como GPT.

Então, esperamos que o disco ainda esteja ok (foi assim antes de eu atualizar para o Windows 10) e os dados estarem intactos. Parece que o Windows 7 é capaz de determinar se o disco está formatado usando o GPT, mas o Windows 10 não é capaz de fazê-lo.

Algumas coisas a notar: - não é o disco com a partição de inicialização que é o disco problemático - O Windows 10 não tem problema em detectar que o disco 2 é um GPT - isso é apenas um problema com o disco 1 - o disco problemático, disco 1, é um disco de 4 TB

Antes de voltar ao Windows 7 para poder acessar e usar este disco, há algo que eu possa fazer para convencer o Windows 10 de que ele está formatado como GPT?

Eu tirei algumas capturas de tela no Windows 10:

Depois,volteiaoWindows7etireiasmesmascapturasdetela:

Editar#2:Paraodiscoproblemático,executei"gdisk64.exe -l: 1" e ele produziu:

GPT fdisk (gdisk) version 1.0.1

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk 1:: 3907018584 sectors, 3.6 TiB
Logical sector size: 1024 bytes
Disk identifier (GUID): 4CB4A691-9E3E-4D3D-94A2-DD0EF91CA76A
Partition table holds up to 128 entries
First usable sector is 18, last usable sector is 3907018566
Partitions will be aligned on 8-sector boundaries
Total free space is 1845 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              18          131089   128.0 MiB   0C01  Microsoft reserved ...
   2          132096      3907017727   3.6 TiB     0700  Basic data partition

Para o outro disco GPT, executei "gdisk64.exe -l: 2" e ele produziu:     GPT fdisk (gdisk) versão 1.0.1

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk 2:: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 71E15BEC-18A7-4AA8-AA1E-04D8678C6FCF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 4205 sectors (2.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34          262177   128.0 MiB   0C01  Microsoft reserved ...
   2          264192       671352831   320.0 GiB   0700  Basic data partition
   3       671352832      3705704447   1.4 TiB     0700  Basic data partition
   4      3705704448      3772813311   32.0 GiB    0700  Basic data partition
   5      3772813312      3907026943   64.0 GiB    0700  Basic data partition

Observe que o gdisk informou que "A partição 0xEE do MBR de proteção é superdimensionada" para ambos os discos, mas o Win10 só tem um problema com um deles. Há links para capturas de tela de como o Gerenciamento de Disco exibe esses discos acima.

Editar # 3: gdisk64.exe 1 :, seguido por v, produz:

Caution: Partition 1 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

No problems found. 1845 free sectors (1.8 MiB) available in 2
segments, the largest of which is 1006 (1006.0 KiB) in size.

Editar # 4: executando o gdisk no Windows 10

Para o disco problemático, eu corri gdisk64.exe -l 1: e ele produziu:

GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.
Disk 1:: 7814037168 sectors, 3.6 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): E5BE667C-E50A-4C44-BC4F-A2AFA7BF80AF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7814037134
Partitions will be aligned on 2048-sector boundaries
Total free space is 7814037101 sectors (3.6 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Esta saída é diferente da saída produzida pelo gdisk no Windows 7, onde encontrou uma GPT válida com MBR de proteção, veja acima. Se eu executar novamente o gdisk64.exe -l 1: , obtenho um novo Disk identifier (GUID) todas as vezes.

Para o outro disco GPT, corri gdisk64.exe -l 2: e foi produzido:

GPT fdisk (gdisk) version 1.0.1

The protective MBR's 0xEE partition is oversized! Auto-repairing.

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk 2:: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 71E15BEC-18A7-4AA8-AA1E-04D8678C6FCF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 4205 sectors (2.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34          262177   128.0 MiB   0C01  Microsoft reserved ...
   2          264192       671352831   320.0 GiB   0700  Basic data partition
   3       671352832      3705704447   1.4 TiB     0700  Basic data partition
   4      3705704448      3772813311   32.0 GiB    0700  Basic data partition

Esta saída é igual / semelhante à saída produzida pelo gdisk no Windows 7.

Editar # 5: a solução final foi o downgrade de um driver no Windows 10

Durante a atualização do Windows 7 para o Windows 10, o sistema instalou um driver AMD AHCI Compatible RAID Controller com a versão 3.4.1592.3. Através de "Atualizar driver ...", notei que havia uma versão mais nova disponível, 3.7.1540.43. Eu atualizei para esse driver, mas, em seguida, o sistema não conseguiu reiniciar.

Depois de passar por alguns obstáculos, consegui reverter para o Windows 7. No Windows 7, o driver AMD AHCI Compatible RAID Controller era a versão 3.1.1540.127 e o disco nº 1 era reconhecido corretamente. Fiz ainda outra atualização para o Windows 10 e, como antes, o driver AMD AHCI Compatible RAID Controller com a versão 3.4.1592.3 foi instalado e o disco nº 1 não foi reconhecido corretamente. Em seguida, usei "Atualizar driver ..." e o rebaixou o driver para a versão 3.1.1540.127, e voila, o Windows 10 agora reconhece o disco nº 1 e a unidade q :.

    

Answer 1

Minha primeira palpite (nota: palpite ) é que você está com problemas de driver. Alguns (na verdade, muitos ) drivers do Windows têm uma limitação / bug conhecido de 32 bits que os torna incapazes de acessar mais de 2TiB de espaço em disco. Quando um disco com mais de 2 TB é acessado com tal driver, o resultado é que o disco parece muito menor do que é, e / ou tentativas de acesso além da marca de 2TiB resultam em acessos a partes anteriores do disco. Isso é semelhante à maneira como o hodômetro de um carro vai "rolar" se você dirigir mais milhas do que o hodômetro suporta. Esse problema é mais comum em versões de 32 bits do Windows, mas recebi relatórios de pessoas que executam versões de 64 bits do Windows que também o executaram. Como o GPT armazena estruturas de dados no início e no final do disco, as estruturas de dados de backup no final do disco ficarão inacessíveis se esse for o problema. Minha hipótese é que, quando o Windows vê isso, ele diz "GPT sem defeito. Vamos tentar o MBR ..." e mostra o disco como MBR. É concebível que também modifique o MBR, para que o disco possa estar danificado. Isso está ficando um pouco à frente das coisas, embora ....

Se isto é o que está acontecendo com você, então substituir o driver defeituoso por um que funcione é a melhor solução. Você pode procurar atualizações da placa-mãe ou do fabricante do controlador de disco. Alternar do IDE para o modo AHCI também pode ajudar, embora isso possa exigir mais saltos. Note que o disco em si não é o problema; é o driver para o controlador de disco (que normalmente é construído na placa-mãe) que é o culpado, de acordo com a minha hipótese.

Antes de fazer qualquer outra coisa, você pode querer inicializar a partir de um disco live do Linux (como um disco de instalação do Ubuntu) e fazer backup de seus dados importantes dessa unidade. Você também pode usar os utilitários do Linux para verificar as estruturas de dados para ter certeza de que elas não foram danificadas. Eu estou recomendando isso porque eu nunca ouvi falar de um bug análogo no Linux, então o Linux não deve ser afetado por esse problema. Se a instalação do Windows 7 mencionada ainda estiver instalada, você poderá usá-la da mesma maneira.

Você pode usar meu programa gdisk , do Linux ou do Windows (fixo), para verificar as estruturas de dados do disco. Em particular, a opção v em gdisk verificará as estruturas de dados e relatará sua consistência. Veja esta página da documentação de gdisk para obter informações sobre como reparar as estruturas de dados da GPT:

link

Esteja ciente de que quaisquer alterações que você gravar no disco, particularmente na instalação quebrada do Windows, são muito arriscadas, não apenas para a tabela de partição, mas para os dados no disco. Não escreva qualquer coisa nesse disco até que você tenha resolvido o problema. Um backup completo de baixo nível pode ser aconselhável se você suspeitar de danos significativos.