2

I have a Windows 7 system with 3 hard drives - Disc 0 is the boot disc formatted with MBR, Disc 1 is a 4 TB disc formatted with GPT, and Disc 2 is a 2 TB disc also formatted with GPT.

Disc 1 has one large partition w/ drive letter Q: assigned to it.

I upgraded the system to Windows 10. In Windows 10, however, drive letter Q: does not show up. Disk Management in Windows 10 thinks the disc is now formatted w/ MBR. It reports two partitions on that disk, the first being "Healthy (GPT Protective Partition)" of size 2048 GB and the second being "Unallocated" of remianing size.

If I use diskpart in a Command Prompt in Windows 10, diskpart reports the disc as MBR (not GPT).

If I use diskpart in a Command Prompt after booting into Safe Mode using a Windows 7 repair disc, diskpart does report the disk as GPT.

So, hopefully the disc is still ok (was so before I upgraded to Windows 10) and the data intact. It appears that Windows 7 is able to determine that the disc is formatted using GPT but Windows 10 is not able to do so.

A couple of thing to note: - it is not the disc with the boot partition that is the problematic disc - Windows 10 has no problem detecting that disc 2 is a GPT - this is only a problem with disc 1 - the problematic disc, disc 1, is a 4 TB disc

Before I revert back to Windows 7 so I can access and use this disc, is there something I can do to convince Windows 10 that it is formatted as GPT?

I took a few screenshots in Windows 10:

Windows 10

Then I reverted back to Windows 7 and took the same screenshots:

Windows 7

Edit #2: For the problematic disk, I ran "gdisk64.exe -l :1" and it produced:

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

For the other GPT disk, I ran "gdisk64.exe -l :2" and it produced: 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
   5      3772813312      3907026943   64.0 GiB    0700  Basic data partition

Note, gdisk reported "The protective MBR's 0xEE partition is oversized" for both disks, but Win10 only has a problem with one of them. There are links to screenshots of how Disk Management displays these disks above.

Edit #3: gdisk64.exe 1:, followed by v, produces:

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.

Edit #4: running gdisk on Windows 10

For the problematic disk, I ran gdisk64.exe -l 1: and it produced:

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

This output is different to the output produced by gdisk on Windows 7, where it found a valid GPT with protective MBR, see above. If I re-run gdisk64.exe -l 1: I get a new Disk identifier (GUID) every time.

For the other GPT disk, I ran gdisk64.exe -l 2: and it produced:

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

This output is the same/similar to the output produced by gdisk on Windows 7.

Edit #5: final solution was to downgrade a driver in Windows 10

During the Windows 7-to-Windows 10 upgrade, the system installed a AMD AHCI Compatible RAID Controller driver with version 3.4.1592.3. Through "Update driver..." I noticed there was a newer version available, 3.7.1540.43. I updated to that driver but then the system failed to re-start.

After jumping through some hoops, I managed to revert back to Windows 7. In Windows 7, the AMD AHCI Compatible RAID Controller driver was version 3.1.1540.127 and disk #1 is recognized properly. I did yet another upgrade to Windows 10 and, as before, AMD AHCI Compatible RAID Controller driver with version 3.4.1592.3 was installed and disk #1 was not recognized properly. I then used "Update driver..." and downgraded the driver to version 3.1.1540.127, and voila, Windows 10 now recognizes disk #1 and the q: drive.

2

My initial guess (note: guess) is that you're running into a driver problem. Some (in fact, many) Windows drivers have a known 32-bit limitation/bug that makes them unable to access more than 2TiB of disk space. When an over-2TiB disk is accessed with such a driver, the result is that the disk looks much smaller than it is, and/or attempts to access beyond the 2TiB mark actually result in accesses to earlier parts of the disk. This is similar to the way a car's odometer will "roll over" if you drive it more miles than the odometer supports. This problem is most common with 32-bit versions of Windows, but I've received reports from people running 64-bit versions of Windows who have run into it, too. Because GPT stores data structures at both the start and end of the disk, the backup data structures at the end of the disk will be inaccessible if this is the problem. My hypothesis is that, when Windows sees this, it says "nope -- defective GPT. Let's try MBR..." and shows the disk as MBR. It's conceivable it's also modifying the MBR, so your disk may now be damaged. That's getting a bit ahead of things, though....

If this is what's happening to you, then replacing the defective driver with a working one is the best fix. You might look for updates from the motherboard or disk controller manufacturer. Switching from IDE to AHCI mode may also help, although that may require more hoop-jumping. Note that the disk itself is not the problem; it's the driver for the disk controller (which is usually built into the motherboard) that's the culprit, according to my hypothesis.

Before doing anything else, you might want to boot from a Linux live disk (such as an Ubuntu installation disk) and back up your important data from that drive. You can also use Linux utilities to check the data structures to be sure they haven't been damaged. I'm recommending this because I've never heard of an analogous bug in Linux, so Linux should not be affected by this problem. If the Windows 7 installation you mention is still installed, you could use it in the same way.

You can use my gdisk program, from either Linux or (fixed) Windows to check the disk's data structures. In particular, the v option in gdisk will check the data structures and report on their consistency. See this page of the gdisk documentation for information on repairing the GPT data structures:

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

Be aware that any changes you write to the disk, particularly from the broken Windows installation, are very risky, not just to the partition table, but to the data on the disk. Don't write anything to that disk until you've fixed the problem. A complete low-level backup may be advisable if you suspect significant damage.

  • 1
    I ran "gdisk64.exe 1:", followed by v and it says: 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..........No problems found. 1845 free sectors (1.8 MiB) available in 2 segments, the largest of which is 1006 (1006.0 KiB) in size. – fastfasterfastest Jan 9 '16 at 0:38
  • 1
    Your gdisk output doesn't show any serious problems. (The partition alignment issue is minor and is not related to the problem you're having. The oversized 0xEE partition isn't a concern per se, but could indicate something strange to do with disk size detection.) The details from the screen shots are consistent with my hypothesis. If you run gdisk from Windows 10, my hunch is that it will say that the backup partition data is damaged and/or that the disk is too small to hold its partitions. – Rod Smith Jan 9 '16 at 14:47
  • 1
    I wanted to run gdisk64.exe 1: followed by v on Windows 10, but after gdisk64.exe 1: gdisk tells me "Are you SURE you want to continue? (Y/N):", and since I want to avoid any modifications to the disk, I ctrl-c. Does continue and use the v option modify the disk? Or does the gdisk64.exe -l 1: already expose the needed info? – fastfasterfastest Jan 9 '16 at 19:41
  • 1
    As stated in my original answer, the driver in question is for the disk controller, not for the disk itself. You won't find anything helpful on Seagate's site. The different GUIDs each time you run gdisk under Windows 10 are understandable given the nature of the problem, since gdisk can't read the GPT data, so it's trying to regenerate what it can (unsuccessfully, it seems). I do still think this is a driver issue. You should check with Microsoft or with whoever created the disk controller chipset for your disk. – Rod Smith Jan 10 '16 at 15:04
  • 2
    Thanks - I appreciate your input and guidance. Windows 10 now recognizes disk #1. I tried upgrading the AMD AHCI Compatible RAID Controller driver but that failed miserably, but downgrading it to same version as used in my Windows 7 installation did work. – fastfasterfastest Jan 12 '16 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.