Win8x64, after format/upgrade from Win7x86, "GPT Protective Partition" on secondary drive

I backed up all important data prior to formatting the C: drive, but I cannot read the backup drive after reinstalling Windows. More details provided after the screenshots.

Additionally

As you can see, there are three physical disks in this system:
- 1TB System (C:) drive.
- 0.5TB basic MBR disk (D:) for general storage.
- 3TB basic disk with a single 3TB GPT partition (E:) for general storage.

Since the D: drive did not have enough free space, I used the 3TB GPT E: drive to backup everything I needed from the C: drive before formatting.

The 3TB E: drive was initialized as GPT and formatted as NTFS using the disk management GUI from Windows 7 Ultimate x86 while it was still installed. However, after formatting the C: drive and installing Windows 8 Enterprise x64, I get the "GPT Protective Partition" problem shown in the screenshot above. Almost all options in the right-click menus are greyed out, so I don't even know where to begin.

I've found a lot of interesting ideas on the internet, but nothing that really fits my situation.

If my understanding is correct, the 2TB "Protective" partition is a fake partition that the GPT system emulates. The idea is, if your system cannot read GPT, and can only read MBR, it will see this fake 2TB MBR partition, so you don't accidentally format it thinking it's empty - hence "protective."

This leads me to the main questions:
- Why would Windows 8 Enterprise x64 be unable to read GPT drives, while Windows 7 Ultimate x86 had no problems whatsoever creating and using this partition?
- How can I get Windows 8 Enterprise x64 to read this drive properly as GPT, so I can recover the backup data stored there?

EDIT:
Here's the GPT and MPR data for the disk, produced by gdisk. The fact that it says all 2.7 TB are "free sectors" worries me a bit, as the disk should be quite full of stored files. Prior to re-installing Windows, this drive functioned flawlessly as a GPT disk with a single 2.7 TB basic non-boot partition.

It looks like something has trashed your GPT data -- both the main data structures and the backup data structures. I don't know specifically what might have done this, but a buggy partitioning tool seems like the most likely culprit. Another possibility is that there's been some confusion over something like a RAID configuration -- if the disk was originally prepared with your motherboard's RAID features active and then accessed with the RAID features inactive, something like this might have happened.

Two options seem most reasonable at this point:

1. Re-create your partition "blind." The vast majority of modern partitioning tools begin partitions at sector 2048, so you could use gdisk to create a partition that begins at that point and that ends at the last possible sector. This stands a good chance of succeeding, but there's a risk that if your original partition did not start at sector 2048, you could end up damaging it when you try to access the new partition. Also, some tools will try to create a new filesystem when you create a new partition, so using them would be risky at best. (I recommended gdisk for this task because it does not touch the partitions' contents, just the partition table that defines them.) Also, if the disk held an EFI System Partition in addition to the main data partition, the main data partition would not begin at sector 2048.
2. Use a tool like TestDisk (included on many Linux emergency systems, such as PartedMagic and System Rescue CD) to search for your missing partition. (There are Windows equivalents to TestDisk, but I don't know what they are, offhand. You could do a Web search to find them, if you prefer to work from Windows rather than boot a Linux emergency disc.) This will be more likely to find your partition if it was placed strangely, but tools like this can become confused if the disk has been re-partitioned in the past -- they can sometimes detect the remnants of deleted partitions and try to re-create them even though they're no longer valid.

Take your pick as to the approach, and good luck! Whatever you do, though, be cautious. You might consider doing a raw disk backup to a spare disk, if you've got one that's big enough to hold all your data. If you do this, though, be very careful in specifying the source and destination disks, or your backup could end up trashing the data you intend to save!