全局唯一标识分区表（GUID Partition Table，缩写：GPT）是一个物理硬盘的分区结构。它是可扩展固件接口标准的一部分，用来替代BIOS中的主引导记录分区表。但因为MBR分区表不支持容量大于2TB的分区，所以也有一些BIOS系统为了支持大容量硬盘而用GPT分区表取代MBR分区表。GPT分区表支持最多128PB的硬盘和分区。
EFI介绍：
了解GUID分区表之前我们先要了解一下什么是EFI(Extensible Firmware Interface 可扩展固件接口)：
含义EFI的产生
BIOS技术的兴起源于IBM PC/AT机器的流行以及第一台由康柏公司研制生产的“克隆”PC。在PC启动的过程中，BIOS担负着初始化硬件，检测硬件功能，以及引导操作系统的责任，在早期，BIOS还提供一套运行时的服务程序给操作系统及应用程序使用。BIOS程序存放于一个掉电后内容不会丢失的只读存储器中，系统加电时处理器的第一条指令的地址会被定位到BIOS的存储器中，便于使初始化程序得到执行。
众所周知，英特尔在近二十年来引领以x86系列处理器为基础的PC技术潮流，它的产品如CPU，芯片组等在PC生产线中占据绝对领导的位置。因此，不少人认为这一举动显示了英特尔公司欲染指固件产品市场的野心。事实上，EFI技术源于英特尔安腾处理器(Itanium)平台的推出。安腾处理器是英特尔瞄准服务器高端市场投入近十年研发力量设计产生的与x86系列完全不同的64位新架构。在x86系列处理器进入32位的时代，由于兼容性的原因，新的处理器(i80386)保留了16位的运行方式(实模式)，此后多次处理器的升级换代都保留了这种运行方式。甚至在含64位扩展技术的至强系列处理器中，处理器加电启动时仍然会切换到16位的实模式下运行。英特尔将这种情况归咎于BIOS技术的发展缓慢。自从PC兼容机厂商通过净室的方式复制出第一套BIOS源程序，BIOS就以16位汇编代码，寄存器参数调用方式，静态链接，以及1MB以下内存固定编址的形式存在了十几年。虽然由于各大BIOS厂商近年来的努力，有许多新元素添加到产品中，如PnP BIOS，ACPI，传统USB设备支持等等，但BIOS的根本性质没有得到任何改变。这迫使英特尔在开发更新的处理器时，都必须考虑加进使效能大大降低的兼容模式。有人曾打了一个比喻：这就像保时捷新一代的全自动档跑车被人生套上去一个蹩脚的挂档器。
然而，安腾处理器并没有这样的顾虑，它是一个新生的处理器架构，系统固件和操作系统之间的接口都可以完全重新定义。并且这一次，英特尔将其定义为一个可扩展的，标准化的固件接口规范，不同于传统BIOS的固定的，缺乏文档的，完全基于经验和晦涩约定的一个事实标准。基于EFI的第一套系统产品的出现至今已经有五年的时间，如今，英特尔试图将成功运用在高端服务器上的技术推广到市场占有率更有优势的PC产品线中，并承诺在2006年间会投入全力的技术支持。
比较EFI和BIOS
一个显著的区别就是EFI是用模块化，C语言风格的参数堆栈传递方式，动态链接的形式构建的系统，较BIOS而言更易于实现，容错和纠错特性更强，缩短了系统研发的时间。它运行于32位或64位模式，乃至未来增强的处理器模式下，突破传统16位代码的寻址能力，达到处理器的最大寻址。它利用加载EFI驱动的形式，识别及操作硬件，不同于BIOS利用挂载实模式中断的方式增加硬件功能。后者必须将一段类似于驱动的16位代码，放置在固定的0x000C0000至0x000DFFFF之间存储区中，运行这段代码的初始化部分，它将挂载实模式下约定的中断向量向其他程序提供服务。例如，VGA图形及文本输出中断(INT 10h)，磁盘存取中断服务(INT 13h)等等。由于这段存储空间有限(128KB)，BIOS对于所需放置的驱动代码大小超过空间大小的情况无能为力。另外，BIOS的硬件服务程序都已16位代码的形式存在，这就给运行于增强模式的操作系统访问其服务造成了困难。因此BIOS提供的服务在现实中只能提供给操作系统引导程序或MS-DOS类操作系统使用。而EFI系统下的驱动并不是由可以直接运行在CPU上的代码组成的，而是用EFI Byte Code编写而成的。这是一组专用于EFI驱动的虚拟机器指令，必须在EFI驱动运行环境(Driver Execution Environment，或DXE)下被解释运行。这就保证了充分的向下兼容性，打个比方说，一个带有EFI驱动的扩展设备，既可以将其安装在安腾处理器的系统中，也可以安装于支持EFI的新PC系统中，而它的EFI驱动不需要重新编写。这样就无需对系统升级带来的兼容性因素作任何考虑。另外，由于EFI驱动开发简单，所有的PC部件提供商都可以参与，情形非常类似于现代操作系统的开发模式，这个开发模式曾使Windows在短短的两三年时间内成为功能强大，性能优越的操作系统。基于EFI的驱动模型可以使EFI系统接触到所有的硬件功能，在操作操作系统运行以前浏览万维网站不再是天方夜谭，甚至实现起来也非常简单。这对基于传统BIOS的系统来说是件不可能的任务，在BIOS中添加几个简单的USB设备支持都曾使很多BIOS设计师痛苦万分，更何况除了添加对无数网络硬件的支持外，还得凭空构建一个16位模式下的TCP/IP协议栈。
一些人认为BIOS只不过是由于兼容性问题遗留下来的无足轻重的部分，不值得为它花费太大的升级努力。而反对者认为，当BIOS的出现制约了PC技术的发展时，必须有人对它作必要的改变。
EFI和操作系统
EFI在概念上非常类似于一个低阶的操作系统，并且具有操控所有硬件资源的能力。不少人感觉它的不断发展将有可能代替现代的操作系统。事实上，EFI的缔造者们在第一版规范出台时就将EFI的能力限制于不足以威胁操作系统的统治地位。首先，它只是硬件和预启动软件间的接口规范；其次，EFI环境下不提供中断的访问机制，也就是说每个EFI驱动程序必须用轮询的方式来检查硬件状态，并且需要以解释的方式运行，较操作系统下的驱动效率更低；再则，EFI系统不提供复杂的存储器保护功能，它只具备简单的存储器管理机制，具体来说就是指运行在x86处理器的段保护模式下，以最大寻址能力为限把存储器分为一个平坦的段，所有的程序都有权限存取任何一段位置，并不提供真实的保护服务。当EFI所有组件加载完毕时，系统可以开启一个类似于操作系统Shell的命令解释环境，在这里，用户可以调入执行任何EFI应用程序，这些程序可以是硬件检测及除错软件，引导管理，设置软件，操作系统引导软件等等。理论上来说，对于EFI应用程序的功能并没有任何限制，任何人都可以编写这类软件，并且效果较以前MS-DOS下的软件更华丽，功能更强大。一旦引导软件将控制权交给操作系统，所有用于引导的服务代码将全部停止工作，部分运行时代服务程序还可以继续工作，以便于操作系统一时无法找到特定设备的驱动程序时，该设备还可以继续被使用。
EFI的组成
一般认为，EFI由以下几个部分组成：
1. Pre-EFI初始化模块
2. EFI驱动执行环境
3. EFI驱动程序
4. 兼容性支持模块(CSM)
5. EFI高层应用
6. GUID 磁盘分区
各部分功能
在实现中，EFI初始化模块和驱动执行环境通常被集成在一个只读存储器中。Pre-EFI初始化程序在系统开机的时候最先得到执行，它负责最初的CPU，主桥及存储器的初始化工作，紧接着载入EFI驱动执行环境(DXE)。当DXE被载入运行时，系统便具有了枚举并加载其他EFI驱动的能力。在基于PCI架构的系统中，各PCI桥及PCI适配器的EFI驱动会被相继加载及初始化；这时，系统进而枚举并加载各桥接器及适配器后面的各种总线及设备驱动程序，周而复始，直到最后一个设备的驱动程序被成功加载。正因如此，EFI驱动程序可以放置于系统的任何位置，只要能保证它可以按顺序被正确枚举。例如一个具PCI总线接口的ATAPI大容量存储适配器，其EFI驱动程序一般会放置在这个设备的符合PCI规范的扩展只读存储器(PCI Expansion ROM)中，当PCI总线驱动被加载完毕，并开始枚举其子设备时，这个存储适配器旋即被正确识别并加载它的驱动程序。部分EFI驱动程序还可以放置在某个磁盘的EFI专用分区中，只要这些驱动不是用于加载这个磁盘的驱动的必要部件。在EFI规范中，一种突破传统MBR磁盘分区结构限制的GUID磁盘分区系统(GPT)被引入，新结构中，磁盘的分区数不再受限制(在MBR结构下，只能存在4个主分区)，并且分区类型将由GUID来表示。在众多的分区类型中，EFI系统分区可以被EFI系统存取，用于存放部分驱动和应用程序。很多人担心这将会导致新的安全性因素，因为EFI系统比传统的BIOS更易于受到计算机病毒的攻击，当一部分EFI驱动程序被破坏时，系统有可能面临无法引导的情况。实际上，系统引导所依赖的EFI驱动部分通常都不会存放在EFI的GUID分区中，即使分区中的驱动程序遭到破坏，也可以用简单的方法得到恢复，这与操作系统下的驱动程序的存储习惯是一致的。CSM是在x86平台EFI系统中的一个特殊的模块，它将为不具备EFI引导能力的操作系统提供类似于传统BIOS的系统服务。
EFI的发展
英特尔无疑是推广EFI的积极因素，近年来由于业界对其认识的不断深入，更多的厂商正投入这方面的研究。包括英特尔，AMD在内的一些PC生产厂家联合成立了联合可扩展固件接口论坛，它将在近期推出第一版规范。这个组织将接手规划EFI发展的重任，并将英特尔的EFI框架解释为这个规范的一个具体实现。另外，各大BIOS提供商如Phoenix, AMI等，原先被认为是EFI发展的阻碍力量，现在也不断的推出各自的解决方案。分析人士指出，这是由于BIOS厂商在EFI架构中重新找到了诸如Pre-EFI启动环境之类的市场位置，然而，随着EFI在PC系统上的成功运用，以及英特尔新一代芯片组的推出，这一部分市场份额将会不出意料的在英特尔的掌控之中。
引入主题开始了解GPT分区表，首先简要的介绍一下GPT分区的一些特点：
在MBR硬盘中，分区信息直接存储于主引导记录(MBR)中（主引导记录中还存储着系统的引导程序）。但在GPT硬盘中，分区表的位置信息储存在GPT头中。但出于兼容性考虑，硬盘的第一个扇区仍然用作MBR，之后才是GPT头。
跟现代的MBR一样，GPT也使用逻辑区块地址（LBA）取代了早期的CHS寻址方式。传统MBR信息存储于LBA 0，GPT头存储于LBA 1，接下来才是分区表本身。64位Windows操作系统使用16,384字节（或32扇区）作为GPT分区表，接下来的LBA 34是硬盘上第一个分区的开始。
苹果公司曾经警告说：“不要假定所有设备的块大小都是512字节。”一些现代的存储设备如固态硬盘可能使用1024字节的块，一些磁光盘（MO）可能使用2048字节的扇区（但是磁光盘通常是不进行分区的）。一些硬盘生产商在计划生产4096字节一个扇区的硬盘（目前市面上西部数据就有4096字节的一个扇区），但截至2010年初，这种新硬盘使用固件对操作系统伪装成512字节一个扇区。
使用英特尔架构的苹果机也使用GPT。
为了减少分区表损坏的风险，GPT在硬盘最后保存了一份分区表的副本。
传统MBR (LBA 0)
在GPT分区表的最开头，处于兼容性考虑仍然存储了一份传统的MBR，用来防止不支持GPT的硬盘管理工具错误识别并破坏硬盘中的数据，这个MBR也叫做保护MBR。在支持从GPT启动的操作系统中，这里也用于存储第一阶段的启动代码。在这个MBR中，只有一个标识为0xEE的分区，以此来表示这块硬盘使用GPT分区表。不能识别GPT硬盘的操作系统通常会识别出一个未知类型的分区，并且拒绝对硬盘进行操作，除非用户特别要求删除这些分区。这就避免了意外删除分区的危险。另外，能够识别GPT分区表的操作系统会检查保护MBR中的分区表，如果分区类型不是0xEE或者MBR分区表中有多个项，也会拒绝对硬盘进行操作。
在使用MBR/GPT混合分区表的硬盘中，这部分存储了GPT分区表的一部分分区（通常是前四个分区），可以使不支持从GPT启动的操作系统从这个MBR启动，启动后只能操作MBR分区表中的分区。如Boot Camp就是使用这种方式启动Windows。
分区表头 (LBA 1)
|
偏移 |
字节长度 |
说明 |
|
0x00 |
8 |
签名，固定为ASCII码 "EFI PART",16进制表示0x5452415020494645。 |
|
0x08 |
4 |
版本号，目前的版本为V1.0，16进制表示0x00010000。 |
|
0x0C |
4 |
分区表头的大小（单位是字节，通常是92字节，即 5C 00 00 00） |
|
0x10 |
4 |
GPT头中字节的CRC32校验 |
|
0x14 |
4 |
固定值00 00 00 00 |
|
0x18 |
8 |
当前LBA（这个分区表头的位置） |
|
0x20 |
8 |
备份LBA（另一个分区表头的位置） |
|
0x28 |
8 |
第一个可用于分区的LBA（主分区表的最后一个LBA + 1） |
|
0x30 |
8 |
最后一个可用于分区的LBA（备份分区表的最后一个LBA − 1） |
|
0x38 |
16 |
磁盘GUID |
|
0x48 |
8 |
分区表项的起始LBA |
|
0x50 |
4 |
分区表项的数量 |
|
0x54 |
4 |
一个分区表项的大小（通常是128） |
|
0x58 |
4 |
分区表CRC32校验 |
|
0x5C |
420 |
保留，剩余的字节必须是0（对于512字节LBA的硬盘即是420个字节） |
分区表头定义了硬盘的可用空间以及组成分区表的项的大小和数量。在使用64位Windows Server 2003的机器上，最多可以创建128个分区，即分区表中保留了128个项，其中每个都是128字节。（EFI标准要求分区表最小要有16,384字节，即128个分区项的大小）分区表头还记录了这块硬盘的GUID，记录了分区表头本身的位置和大小（位置总是在LBA 1）以及备份分区表头和分区表的位置和大小（在硬盘的最后）。它还储存着它本身和分区表的CRC32校验。固件、引导程序和操作系统在启动时可以根据这个校验值来判断分区表是否出错，如果出错了，可以使用软件从硬盘最后的备份GPT中恢复整个分区表，如果备份GPT也校验错误，硬盘将不可使用。所以GPT硬盘的分区表不可以直接使用16进制编辑器修改。
分区表项 (LBA 2–33)
GUID分区表项
|
偏移 |
字节长度 |
说明 |
|
0x00 |
16 |
分区类型GUID |
|
0x10 |
16 |
唯一的分区GUID |
|
0x20 |
8 |
开始LBA |
|
0x28 |
8 |
结束LBA |
|
0x30 |
8 |
分区属性 |
|
0x38 |
72 |
分区名称 (Unicode码) |
分区属性
|
位 |
说明 |
|
Bit 0 |
系统分区 00 00 00 00 00 00 00 00 |
|
Bit 60 |
分区只读 00 00 00 00 00 00 00 10 |
|
Bit 62 |
隐藏分区 00 00 00 00 00 00 00 40 |
|
Bit 63 |
不挂载此分区（不分配盘符）00 00 00 00 00 00 00 80 |
分区类型GUID
|
相关操作系统 |
分区类型 |
GUID |
|
(None) |
未使用 |
00000000-0000-0000-0000-000000000000 |
|
MBR分区表 |
024DEE41-33E7-11D3-9D69-0008C781F39F |
|
|
EFI系统分区 |
C12A7328-F81F-11D2-BA4B-00A0C93EC93B |
|
|
BIOS引导分区 |
21686148-6449-6E6F-744E-656564454649 |
|
|
Windows |
微软保留分区 |
E3C9E316-0B5C-4DB8-817D-F92DF00215AE |
|
基本数据分区 |
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 |
|
|
逻辑软盘管理工具元数据分区 |
5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 |
|
|
逻辑软盘管理工具数据分区 |
AF9B60A0-1431-4F62-BC68-3311714A69AD |
|
|
Windows恢复环境 |
DE94BBA4-06D1-4D40-A16A-BFD50179D6AC |
|
|
IBM通用并行文件系统(GPFS)分区 |
37AFFC90-EF7D-4e96-91C3-2D7AE055B174 |
|
|
HP-UX |
数据分区 |
75894C1E-3AEB-11D3-B7C1-7B03A0000000 |
|
服务分区 |
E2A1E728-32E3-11D6-A682-7B03A0000000 |
|
|
Linux |
数据分区 |
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 |
|
RAID分区 |
A19D880F-05FC-4D3B-A006-743F0F84911E |
|
|
交换分区 |
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F |
|
|
逻辑卷管理器(LVM)分区 |
E6D6D379-F507-44C2-A23C-238F2A3DF928 |
|
|
保留 |
8DA63339-0007-60C0-C436-083AC8230908 |
|
|
FreeBSD |
启动分区 |
83BD6B9D-7F41-11DC-BE0B-001560B84F0F |
|
数据分区 |
516E7CB4-6ECF-11D6-8FF8-00022D09712B |
|
|
交换分区 |
516E7CB5-6ECF-11D6-8FF8-00022D09712B |
|
|
UFS分区 |
516E7CB6-6ECF-11D6-8FF8-00022D09712B |
|
|
en:Vinum volume manager分区 |
516E7CB8-6ECF-11D6-8FF8-00022D09712B |
|
|
ZFS分区 |
516E7CBA-6ECF-11D6-8FF8-00022D09712B |
|
|
Mac OS X |
HFS(HFS+)分区 |
48465300-0000-11AA-AA11-00306543ECAC |
|
苹果公司UFS |
55465300-0000-11AA-AA11-00306543ECAC |
|
|
ZFS |
6A898CC3-1DD2-11B2-99A6-080020736631 |
|
|
苹果RAID分区 |
52414944-0000-11AA-AA11-00306543ECAC |
|
|
苹果RAID分区，下线 |
52414944-5F4F-11AA-AA11-00306543ECAC |
|
|
苹果启动分区 |
426F6F74-0000-11AA-AA11-00306543ECAC |
|
|
Apple Label |
4C616265-6C00-11AA-AA11-00306543ECAC |
|
|
Apple TV 恢复分区 |
5265636F-7665-11AA-AA11-00306543ECAC |
|
|
Solaris |
启动分区 |
6A82CB45-1DD2-11B2-99A6-080020736631 |
|
根分区 |
6A85CF4D-1DD2-11B2-99A6-080020736631 |
|
|
交换分区 |
6A87C46F-1DD2-11B2-99A6-080020736631 |
|
|
备份分区 |
6A8B642B-1DD2-11B2-99A6-080020736631 |
|
|
/usr 分区 |
6A898CC3-1DD2-11B2-99A6-080020736631 |
|
|
/var 分区 |
6A8EF2E9-1DD2-11B2-99A6-080020736631 |
|
|
/home 分区 |
6A90BA39-1DD2-11B2-99A6-080020736631 |
|
|
备用扇区 |
6A9283A5-1DD2-11B2-99A6-080020736631 |
|
|
保留分区 |
6A945A3B-1DD2-11B2-99A6-080020736631 |
|
|
6A9630D1-1DD2-11B2-99A6-080020736631 |
||
|
6A980767-1DD2-11B2-99A6-080020736631 |
||
|
6A96237F-1DD2-11B2-99A6-080020736631 |
||
|
6A8D2AC7-1DD2-11B2-99A6-080020736631 |
||
|
NetBSD |
交换分区 |
49F48D32-B10E-11DC-B99B-0019D1879648 |
|
FFS分区 |
49F48D5A-B10E-11DC-B99B-0019D1879648 |
|
|
LFS分区 |
49F48D82-B10E-11DC-B99B-0019D1879648 |
|
|
RAID分区 |
49F48DAA-B10E-11DC-B99B-0019D1879648 |
|
|
concatenated分区 |
2DB519C4-B10F-11DC-B99B-0019D1879648 |
|
|
加密分区 |
2DB519EC-B10F-11DC-B99B-0019D1879648 |
GPT分区表使用简单而直接的方式表示分区。一个分区表项的前16字节是分区类型GUID。例如，EFI系统分区的GUID类型是{C12A7328-F81F-11D2-BA4B-00A0C93EC93B}。接下来的16字节是该分区唯一的GUID（这个GUID指的是该分区本身，而之前的GUID指的是该分区的类型）。再接下来是分区起始和末尾的64位LBA编号，以及分区的名字和属性。
操作系统支持
对于不标准的MBR/GPT混合硬盘，不同的系统中的实现有些不一致。除非另加说明，操作系统在处理混合硬盘时优先读取GPT分区表
以下表格中的“不支持”应该理解成：不能识别GPT分区的硬盘，系统只能识别保护分区。GPT硬盘的数据可以通过第三方管理工具进行操作。
类Unix操作系统
|
操作系统 |
版本 |
平台 |
自BIOS/GPT启动 |
自EFI/GPT启动 |
备注 |
|
FreeBSD |
7.0以后 |
x86、x86-64 |
是 |
是 |
在MBR/GPT混合硬盘中，可以同时使用GPT和MBR分区标识。 |
|
Linux |
大多数x86架构的Linux发行版 Fedora 8+、Ubuntu 8.04+ |
x86-64、IA-64、x86 |
是 |
是 |
一些分区工具，如fdisk，不支持GPT。 而gdisk、grub2之类的新工具支持GPT。 |
|
Mac OS X |
10.4.0以后（一些功能要到10.4.6以后） |
x86、x86-64 |
否 |
是 |
|
|
Solaris |
Solaris 10 以后 |
x86、x86-64、SPARC |
No (Work in Progress) |
No (Work in Progress) |
32位Windows
|
操作系统 |
版本 |
平台 |
自BIOS/GPT启动 |
自EFI/GPT启动 |
备注 |
|
Windows XP |
(2001-10-25) |
x86 |
否 |
否 |
不支持 |
|
Windows Server 2003 |
(2003-04-24) |
x86 |
否 |
否 |
不支持 |
|
Windows Server 2003 |
Service Pack 1 (2005-03-30) |
x86 |
否 |
否 |
仅支持作为数据盘使用，在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows Vista |
(2005-07-22) |
x86 |
否 |
否 |
在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows Server 2008 |
(2008-02-27) |
x86 |
否 |
否 |
在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows 7 |
(2009-10-22) |
x86 |
否 |
否 |
在MBR/GPT混合硬盘中优先使用MBR。 |
64位Windows
下表列出了支持GPT的64位版Windows。既包括IA-64架构的服务器版本，也包括x86-64和EM64T架构。
|
操作系统 |
版本 |
平台 |
自BIOS/GPT启动 |
自EFI/GPT启动 |
备注 |
|
Windows XP |
64-bit (2001-10-25) |
IA-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。可拆卸磁盘仅支持MBR分区表。 |
|
Windows XP |
64-bit, Version 2003 (2003-03-28) |
IA-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。可拆卸磁盘仅支持MBR分区表。 |
|
Windows Server 2003 |
64-bit (2003-04-24) |
IA-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。 默认使用GPT。IA-64架构的启动盘必须是GPT硬盘，其余硬盘可以使用MBR也可以使用GPT。 |
|
Windows Server 2003 |
x64, Service Pack 1 (2005-03-30) |
x86-64 |
否 |
否 |
仅支持作为数据盘使用，在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows XP |
Professional x64 (2005-04-25) |
x86-64 |
否 |
否 |
仅支持作为数据盘使用，在MBR/GPT混合硬盘中优先使用MBR。可拆卸磁盘仅支持MBR分区表。 |
|
Windows Vista |
(2005-07-22) |
x86-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows Server 2008 |
(2008-02-27) |
x86-64, IA-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows 7 |
(2009-10-22) |
x86-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。 |
|
Windows Server 2008 R2 |
(2009-10-22) |
x86-64, IA-64 |
否 |
是 |
在MBR/GPT混合硬盘中优先使用MBR。 |
以下是为了方便读者自行分析GPT磁盘结构，本人做的WinHex模板，包含“GPT头模板”、“分区表项模板” （使用时请将字体加粗部分复制到Windows中的记事本，另存为成*.tpl，放到WinHex所在目录中即可使用）
1、GPT头模板
template "GUID Partition Table Header"
description "GUID Partition Table Header"
applies_to disk
sector-aligned
requires 0x00 "45 46 49 20 50 41 52 54"
begin
{
read-only char [8] "签名"
hex 4 "版本 (HEX)"
uint32 "GPT头大小字节数"
hex 4 "GPT头CRC校验和 (HEX)"
hex 4 "保留--必须为零 (HEX)"
int64 "当前GPT头的LBA扇区号"
int64 "GPT头备份LBA扇区号"
int64 "GPT分区区域起始LBA"
int64 "GPT分区区域结束LBA"
read-only guid "磁盘GUID (GUID)"
move -16
hex 16 "磁盘GUID (16Byte HEX)"
int64 "GPT分区表起始LBA"
uint32 "分区表项数"
uint32 "每分区表项占用字节数"
hex 4 "分区表CRC校验和 (HEX)"
hex 420 "保留 (420Byte HEX)"
}
endsection
end
2、分区表项模板
template "GUID Partition Entry"
description "GUID Partition Entry"
applies_to disk
sector-aligned
multiple
begin
{
read-only guid "分区类型GUID (GUID)"
move -16
hex 16 "分区类型GUID (HEX)"
read-only guid "唯一的分区GUID (GUID)"
move -16
hex 16 "唯一的分区GUID (HEX)"
int64 "开始LBA"
int64 "结束LBA"
hex 8 "属性 (HEX)"
char16[36] "分区名称 (Unicode)"
}
end
在此为广大读者献出一个用于修复GPT磁盘的WinHex脚本，主要用于MBR、主GPT头、主分区表项，损坏的修复，本脚本通过备份的GPT头与备份的分区表项进行修复，使用之前先判断备份部分是否正常，脚本如下（使用时请将字体加粗部分复制到Windows中的记事本，另存为成*.whs，放到WinHex所在目录中即可使用）：
GPT Header 修复(用备份修复)
Assign DiskSize GetSize
Goto 0x1B8
Write 0x43C659CF //磁盘签名
Move 2
Write 0x00000200EEFFFFFF01000000FFFFFFFF
Goto 0x1FE
Write 0x55AA
Goto (DiskSize-512)
Move 32
Read Temp1 8
Goto (DiskSize-512)
Read Header 512
Goto (DiskSize-512-16384)
Read ParBak 16384
Goto (Temp1*512)
Write Header
Write ParBak
Goto (Temp1*512)
Move 16
Write 0x00000000
Move 4
Write 0x0000000000000000
Write 0x0100000000000000
Move 32
Write 0x0000000000000000
Goto (DiskSize-512+32)
Read Temp2 8
Goto (Temp1*512+24)
Write Temp2
Goto (DiskSize-512+24)
Read Temp3 8
Goto (Temp1*512+32)
Write Temp3
Goto (Temp1*512+72)
Write ((Temp1*512+512)/512)
Goto (Temp1*512)
Assign Header CurrentPos
Block Header (Header+91)
CalcHash CRC32 HeaderCRC32
Goto (Temp1*512+16)
Write HeaderCRC32
Save
MessageBox "修复成功！"