从 Windows 7 升级到 Windows 10 后,系统认为 GPT 分区是 MBR

从 Windows 7 升级到 Windows 10 后,系统认为 GPT 分区是 MBR

我有一台带有 3 个硬盘的 Windows 7 系统 - 磁盘 0 是使用 MBR 格式化的启动盘,磁盘 1 是使用 GPT 格式化的 4 TB 磁盘,磁盘 2 也是使用 GPT 格式化的 2 TB 磁盘。

磁盘 1 有一个大分区,分配有驱动器号 Q:。

我将系统升级到 Windows 10。然而,在 Windows 10 中,驱动器号 Q: 没有显示。Windows 10 中的磁盘管理认为磁盘现在已使用 MBR 格式化。它报告该磁盘上有两个分区,第一个是“健康(GPT 保护分区)”,大小为 2048 GB,第二个是“未分配”,剩余大小。

如果我在 Windows 10 中的命令提示符中使用 diskpart,diskpart 会将磁盘报告为 MBR(而不是 GPT)。

如果我使用 Windows 7 修复光盘启动到安全模式后在命令提示符中使用 diskpart,diskpart 会将该磁盘报告为 GPT。

因此,希望光盘仍然完好无损(在我升级到 Windows 10 之前是这样的),并且数据完好无损。看来 Windows 7 能够确定光盘是使用 GPT 格式化的,但 Windows 10 却无法做到这一点。

需要注意以下几点: - 有问题的光盘不是带有启动分区的光盘 - Windows 10 可以毫无问题地检测到光盘 2 是 GPT - 这只是光盘 1 的问题 - 有问题的光盘(光盘 1)是 4 TB 的光盘

在我恢复到 Windows 7 以便可以访问和使用该磁盘之前,我可以做些什么来让 Windows 10 它已被格式化为 GPT?

我在 Windows 10 中截取了一些屏幕截图:

Windows 10

然后我恢复到 Windows 7 并截取了相同的屏幕截图:

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 只有其中一个磁盘存在问题。上面有磁盘管理如何显示这些磁盘的屏幕截图链接。

编辑#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:在 Windows 10 上运行 gdisk

对于有问题的磁盘,我运行了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

此输出与 Windows 7 上 gdisk 生成的输出不同,在 Windows 7 上,它找到了具有保护性 MBR 的有效 GPT,见上文。如果我重新运行,每次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

此输出与 Windows 7 上 gdisk 生成的输出相同/相似。

编辑 #5:最终解决方案是在 Windows 10 中降级驱动程序

在从 Windows 7 升级到 Windows 10 的过程中,系统安装了AMD AHCI Compatible RAID Controller版本为 3.4.1592.3 的驱动程序。通过“更新驱动程序...”,我注意到有一个较新的版本可用,即 3.7.1540.43。我更新了该驱动程序,但系统无法重新启动。

经过一番折腾,我终于恢复到了 Windows 7。在 Windows 7 中,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:驱动器。

答案1

我的初始猜测(笔记:猜测)是您遇到了驱动程序问题。有些(事实上,许多) Windows 驱动程序有一个已知的 32 位限制/错误,导致它们无法访问超过 2TiB 的磁盘空间。当使用这样的驱动程序访问超过 2TiB 的磁盘时,结果是磁盘看起来比实际小得多,并且/或者尝试访问超过 2TiB 标记的部分实际上会导致访问磁盘的早期部分。这类似于汽车里程表在行驶里程超过里程表支持的里程数时会“翻转”的方式。此问题在 32 位版本的 Windows 中最为常见,但我收到过运行 64 位版本的 Windows 的人的报告,他们也遇到过此问题。由于 GPT 在磁盘的开始和结束处都存储数据结构,因此如果这是问题所在,则磁盘末尾的备份数据结构将无法访问。我的假设是,当 Windows 看到此问题时,它会说“不 - GPT 有缺陷。让我们试试 MBR...”并将磁盘显示为 MBR。可以想象它还会修改 MBR,所以你的磁盘现在可能已损坏。不过,这有点太夸张了……

如果您遇到这种情况,那么用正常工作的驱动程序替换有缺陷的驱动程序是最好的解决方法。您可以查找主板或磁盘控制器制造商的更新。从 IDE 切换到 AHCI 模式也可能有帮助,尽管这可能需要更多麻烦。请注意,磁盘本身不是问题;而是磁盘的驱动程序控制器(通常内置于主板中)根据我的假设,这就是罪魁祸首。

在做其他任何事情之前,您可能需要从 Linux 实时磁盘(例如 Ubuntu 安装磁盘)启动并从该驱动器备份重要数据。您还可以使用 Linux 实用程序检查数据结构以确保它们没有被损坏。我推荐这样做是因为我从未听说过 Linux 中存在类似的错误,因此 Linux 不应该受到此问题的影响。如果您提到的 Windows 7 安装仍处于安装状态,您可以以相同的方式使用它。

您可以使用我的gdisk程序(无论是 Linux 还是(固定的)Windows)来检查磁盘的数据结构。特别是,v中的选项gdisk将检查数据结构并报告其一致性。有关修复 GPT 数据结构的信息,请参阅文档的此页面gdisk

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

请注意,写入磁盘的任何更改(尤其是来自损坏的 Windows 安装的更改)都非常危险,不仅会损坏分区表,还会损坏磁盘上的数据。不要写入任何事物直到问题解决为止,不要将任何文件复制到该磁盘。如果您怀疑存在严重损坏,则建议进行完整的低级备份。

相关内容