Windows7からWindows10にアップグレードした後、システムはGPTパーティションがMBRであると見なします
3台のハードドライブを搭載したWindows7システムがあります-ディスク0はMBRでフォーマットされたブートディスク、ディスク1は4 TB GPTでフォーマットされたディスク、ディスク2は2 TBディスクもGPTでフォーマットされています。
ディスク1には、ドライブ文字Q：が割り当てられた1つの大きなパーティションがあります。
システムをWindows10にアップグレードしました。ただし、Windows 10では、ドライブ文字Q：が表示されません。 Windows 10のディスクの管理では、ディスクがMBRでフォーマットされていると見なされます。そのディスク上の2つのパーティションを報告します。1つはサイズ2048GBの「正常（GPT保護パーティション）」で、もう1つはサイズ変更の「未割り当て」です。
Windows 10のコマンドプロンプトでdiskpartを使用すると、diskpartはディスクを（GPTではなく）MBRとして報告します。
Windows 7修復ディスクを使用してセーフモードで起動した後、コマンドプロンプトでdiskpartを使用すると、diskpartはディスクをGPTとして報告します。
したがって、ディスクがまだ問題なく（Windows 10にアップグレードする前は問題がなかった）、データが損なわれていないことを願っています。 Windows 7はディスクがGPTを使用してフォーマットされていると判断できるようですが、Windows10はそうすることができません。
注意すべき点がいくつかあります：-問題のあるディスクはブートパーティションのあるディスクではありません-Windows 10はディスク2がGPTであることを問題なく検出します-これはディスク1の問題のみです-問題のあるディスク、ディスク1、4 TBディスク
このディスクにアクセスして使用できるようにWindows7に戻る前に、GPTとしてフォーマットされていることをWindows 10に納得させるためにできることはありますか？
Windows10でいくつかのスクリーンショットを撮りました。
次に、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：Windows10で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
_この出力は、保護MBRを備えた有効なGPTが見つかったWindows7のgdiskによって生成された出力とは異なります。上記を参照してください。 _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
_この出力は、Windows7のgdiskによって生成される出力と同じ/類似しています。
編集＃5：最終的な解決策は、Windows10でドライバーをダウングレードすることでした
Windows7からWindows10へのアップグレード中に、システムはバージョン3.4.1592.3の_AMD AHCI Compatible RAID Controller_ドライバーをインストールしました。 「ドライバの更新...」を通じて、新しいバージョン3.7.1540.43が利用可能であることに気付きました。そのドライバーに更新しましたが、システムを再起動できませんでした。
いくつかのフープを飛び越えた後、私はなんとかWindows 7に戻ることができました。Windows7では、_AMD AHCI Compatible RAID Controller_ドライバーはバージョン3.1.1540.127であり、ディスク＃1は正しく認識されています。 Windows 10にさらに別のアップグレードを行いましたが、以前と同様に、バージョン3.4.1592.3の_AMD AHCI Compatible RAID Controller_ドライバーがインストールされ、ディスク＃1が正しく認識されませんでした。次に、「ドライバーの更新...」を使用し、ドライバーをバージョン3.1.1540.127にダウングレードしました。これで、Windows 10はディスク＃1とq：ドライブ。
私の最初のguess（注：guess）はあなたが実行していることですドライバーの問題に。一部の（実際には、多くの）Windowsドライバーには、2TiBを超えるディスク領域にアクセスできないという既知の32ビット制限/バグがあります。このようなドライバを使用して2TiBを超えるディスクにアクセスすると、ディスクが実際よりもはるかに小さく見えるか、2TiBマークを超えてアクセスしようとすると、実際にはディスクの以前の部分にアクセスすることになります。これは、走行距離計がサポートする距離よりも長い距離を運転した場合に、自動車の走行距離計が「ロールオーバー」する方法に似ています。この問題は32ビットバージョンのWindowsで最も一般的ですが、64ビットバージョンのWindowsを実行している人々からもこの問題に遭遇したという報告を受けています。 GPTはディスクの最初と最後の両方にデータ構造を格納するため、これが問題になると、ディスクの最後にあるバックアップデータ構造にアクセスできなくなります。私の仮説では、Windowsがこれを見ると、「いいえ、GPTに欠陥があります。MBRを試してみましょう...」と表示され、ディスクがMBRとして表示されます。 MBRも変更されていると考えられるため、ディスクが損傷している可能性があります。しかし、それは少し先を行っています。
これがあなたに起こっていることであるならば、それから欠陥のあるドライバーを機能しているものと交換することが最良の修正です。マザーボードまたはディスクコントローラの製造元からのアップデートを探す場合があります。 IDEからAHCIモードに切り替えることも役立つ場合がありますが、フープジャンプがさらに必要になる場合があります。ディスク自体は問題ではなく、ディスクのドライバーですコントローラー（通常はマザーボードに組み込まれています）が原因であると私の仮説は述べています。
他のことをする前に、Linuxライブディスク（Ubuntuインストールディスクなど）から起動し、そのドライブから重要なデータをバックアップすることをお勧めします。 Linuxユーティリティを使用して、データ構造をチェックし、データ構造が損傷していないことを確認することもできます。 Linuxで同様のバグを聞いたことがないので、これをお勧めします。したがって、Linuxはこの問題の影響を受けないはずです。言及したWindows7のインストールがまだインストールされている場合は、同じように使用できます。
Linuxまたは（固定）Windowsのいずれかから私のgdiskプログラムを使用して、ディスクのデータ構造を確認できます。特に、vのgdiskオプションは、データ構造をチェックし、それらの整合性についてレポートします。 GPTデータ構造の修復については、gdiskドキュメントの次のページを参照してください。
http://www.rodsbooks.com/gdisk/repairing.html
特に壊れたWindowsインストールからディスクに書き込む変更は、パーティションテーブルだけでなく、ディスク上のデータに対しても非常に危険であることに注意してください。問題を修正するまで、そのディスクにanythingを書き込まないでください。重大な損傷が疑われる場合は、完全な低レベルのバックアップをお勧めします。