После обновления с Windows 7 до Windows 10 система считает, что раздел GPT является MBR

Question

У меня есть система Windows 7 с 3 жесткими дисками - Диск 0 - это загрузочный диск, отформатированный с MBR, Диск 1 - это диск объемом 4 ТБ, отформатированный с GPT, а Диск 2 - это диск с 2 ТБ, также отформатированный с GPT.

Диск 1 имеет один большой раздел с буквой Q: назначенный ему.

Я обновил систему до Windows 10. Однако в Windows 10 буква диска Q: не отображается. Управление дисками в Windows 10 считает, что диск теперь отформатирован с MBR. Он сообщает о двух разделах на этом диске, первый из которых «Healthy (Защитный раздел GPT)» размером 2048 ГБ, а второй - "Нераспределенный" с размером ремианирования.

Если я использую diskpart в командной строке в Windows 10, diskpart сообщает диск как MBR (не GPT).

Если я использую diskpart в командной строке после загрузки в безопасном режиме с использованием диска восстановления Windows 7, diskpart действительно сообщает о диске как GPT.

Итак, мы надеемся, что диск все еще в порядке (так было до обновления до Windows 10) и данные не повреждены. Похоже, что Windows 7 может определить, что диск отформатирован с использованием GPT, но Windows 10 не может это сделать.

Несколько вещей, на которые следует обратить внимание:- проблематичным диском является не диск с загрузочным разделом - Windows 10 без проблем обнаруживает, что диск 2 является GPT - это проблема только с диском 1 - проблемный диск, диск 1, это диск 4 ТБ

Прежде чем вернуться к Windows 7, чтобы я мог получить доступ к этому диску и использовать его, могу ли я что-то сделать, чтобы убедить Windows 10 в том, что он отформатирован как GPT?

Я сделал несколько скриншотов в Windows 10:

Затем я вернулся к Windows 7 и сделал те же снимки экрана:

Редактирование # 2: Для проблемного диска я запустил «gdisk64.exe -l: 1», и он произвел:

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

Для другого GPT-диска я запустил «gdisk64.exe -l:2», и он произвел:GPT fdisk (gdisk) версии 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

Обратите внимание, что gdisk сообщил: «Размер защитного раздела MBR 0xEE слишком велик» для обоих дисков, но Win10 имеет проблему только с одним из них. Есть ссылки на скриншоты того, как Disk Management отображает эти диски выше.

Изменить # 3: gdisk64.exe 1:, а затем v, производит:

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.

Редактирование # 4: запуск gdisk в Windows 10

Для проблемного диска я запустил gdisk64.exe -l 1: :

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

Этот вывод отличается от вывода, созданного gdisk в Windows 7, где он нашел действительный GPT с защитной MBR, см. Выше. Если я перезапущу gdisk64.exe -l 1: я получаю новый Disk identifier (GUID) каждый раз.

Для другого GPT-диска я запустил gdisk64.exe -l 2: и он выдал:

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

Этот вывод такой же / похож на вывод gdisk в Windows 7.

Правка № 5: окончательное решение было понизить версию драйвера в Windows 10

Во время обновления Windows 7 до Windows 10 система установила драйвер RAID-контроллера, совместимого с AMD AHCI Compatible RAID Controller версии 3.4.1592.3. Через "Обновить драйвер ..." я заметил, что появилась более новая версия, 3.7.1540.43. Я обновил до этого драйвера, но затем система не удалось перезапустить.

Прыгнув через несколько обручей, мне удалось вернуться к Windows 7. В Windows 7 драйвер RAID-контроллера, совместимого с AMD AHCI Compatible RAID Controller был версии 3.1.1540.127, и диск № 1 распознается правильно. Я сделал еще одно обновление до Windows 10, и, как и прежде, был установлен AMD AHCI Compatible RAID Controller версии 3.4.1592.3, а диск № 1 не был распознан должным образом. Затем я использовал «Обновить драйвер ...» и понизил версию драйвера до версии 3.1.1540.127, и вуаля, Windows 10 теперь распознает диск № 1 и диск q:.

Answer 1

Мое первоначальное предположение (примечание: предположение) состоит в том, что вы столкнулись с проблемой драйвера. Некоторые (на самом деле, многие) драйверы Windows имеют известное 32-разрядное ограничение / ошибку, из-за которой они не могут получить доступ к более чем 2 ТБ дискового пространства. Когда доступ к диску размером более 2 ТБ осуществляется с помощью такого драйвера, результатом является то, что диск выглядит намного меньше, чем он есть, и / или попытки получить доступ выше отметки 2 ТБ фактически приводят к доступу к более ранним частям диска. Это похоже на то, как одометр автомобиля "перевернется", если вы проезжаете на нем больше миль, чем поддерживает одометр. Эта проблема чаще всего встречается в 32-разрядных версиях Windows, но я получал отчеты от людей, использующих 64-разрядные версии Windows, которые тоже сталкивались с ней. Поскольку GPT хранит структуры данных как в начале, так и в конце диска, резервные структуры данных в конце диска будут недоступны, если это является проблемой. Моя гипотеза состоит в том, что, когда Windows видит это, она говорит «нет дефектного GPT. Давайте попробуем MBR ...» и отображает диск как MBR. Вполне возможно, что он также изменяет MBR, поэтому ваш диск теперь может быть поврежден. Это становится немного впереди вещей, хотя ....

Если это то, что происходит с вами, то замена неисправного драйвера на исправный является лучшим решением. Вы можете искать обновления от производителя материнской платы или контроллера диска. Переключение из IDE в режим AHCI также может помочь, хотя это может потребовать большего количества прыжков с обручем. Обратите внимание, что сам диск не является проблемой; это драйвер для контроллера диска (который обычно встроен в материнскую плату), что является виновником, согласно моей гипотезе.

Прежде чем делать что-либо еще, вы можете захотеть загрузиться с живого диска Linux (например, с установочного диска Ubuntu) и сделать резервную копию важных данных с этого диска. Вы также можете использовать утилиты Linux для проверки структур данных, чтобы убедиться, что они не были повреждены. Я рекомендую это, потому что я никогда не слышал об аналогичной ошибке в Linux, поэтому эта проблема не должна затрагивать Linux. Если упомянутая вами установка Windows 7 все еще установлена, вы можете использовать ее таким же образом.

Вы можете использовать мою программу gdisk из Linux или (фиксированной) Windows для проверки структур данных диска. В частности, опция v в gdisk проверит структуры данных и сообщит об их согласованности. См. Эту страницу документации по gdisk для получения информации о восстановлении структур данных GPT:

http://www.rodsbooks.com/gdisk/repairing.html

Имейте в виду, что любые изменения, которые вы записываете на диск, особенно из-за неработающей установки Windows, очень опасны не только для таблицы разделов, но и для данных на диске. Не пишите ничего на этот диск, пока не решите проблему. Полное низкоуровневое резервное копирование может быть целесообразным, если вы подозреваете существенный ущерб.