WinHex 恢复或重建分区表：工程师的“手术刀”与“缝合线”
你打开磁盘管理器，看到一个熟悉的硬盘变成了“未分配”状态。心跳加速？别急，分区表挂了是很常见的事。作为天天跟二进制打交道的工程师，我今天就聊聊怎么用 WinHex 这个利器——winhex恢复或重建分区表——把它救回来。前面处理过一个类似的案例，客户硬盘本来好好的，突然开机不认，插到别的电脑上也是未初始化。我拿到手先没急着动，看看有没有物理坏道，然后才考虑分区表层面。 www.fixhdd.cn
说到分区表修复，很多人第一反应是找分区软件一键重建。但真正精细的活儿还得靠十六进制编辑器。WinHex 不仅能看原始扇区，还能手动计算参数，很多时候比自动工具更可靠。 技王数据恢复
先判断：到底是 MBR 还是 GPT 的分区表故障？
头一个动作——打开 WinHex，加载物理磁盘。注意别选错盘，我见过有人把系统盘给覆盖了，哭都来不及。 技王数据恢复
- MBR 分区表： 看 0 号扇区，两个字节是不是 55 AA。如果是，接着看偏移 0x1BE 开始的主分区表项。如果全是 00 或者乱码，基本就是分区表被擦了。
- GPT 分区表： 0 号扇区是保护MBR，真正的 GPT 头部在 1 号扇区（LBA1）。如果头部损坏，磁盘管理器会显示“未初始化”。
有一次客户拿来的移动硬盘，MBR 扇区前 446 字节的引导代码还在，但分区表全部归零。很明显是病毒或者误操作把分区表删了。这种情况下，只要数据没有被覆盖，重建分区表成功率很高。 技王数据恢复
实战案例：一块 2TB 的硬盘，分区突然消失
那是去年一个企业客户的服务器数据备份盘。据说是运维人员跑了个什么清理脚本，第二天发现 D 盘没了。我用 WinHex 打开一看，MBR 的 55 AA 还在，但分区表四个表项全是零。别慌，先扫描全盘找 DBR 或 NTFS 的引导扇区。NTFS 的 DBR 通常位于分区的第一个扇区，特征很明显——文件系统“NTFS”字样，以及 BPB 参数。
技王数据恢复
扫到大约 100GB 的位置，发现一个扇区开头有“EB 52 90”，后面跟着“NTFS”，确定是 DBR。但怎么知道这是哪个分区的？需要根据 DBR 里的 BPB 信息反推分区起始位置。NTFS 的 BPB 里记录着每扇区字节数、每簇扇区数、总扇区数等。算一下：如果这个 DBR 在 LBA 200000 附近，而 BPB 里记录的“总扇区数”是 4000000，那么分区起始就该是 200000 - 分区间隙？不，分区起始其实就是这个 DBR 所在的扇区——前提是分区没有偏移。多数情况下，分区起始就是 DBR 的位置。然后计算分区结束：起始 LBA + 总扇区数 - 1。拿到这两个值，就可以构造分区表项了。
www.fixhdd.cn
这里插一句： 如果在现场不确定参数，可以用 WinHex 的“分区搜索”功能（Tools → Disk Tools → Scan for Lost Partitions）辅助确认。但千万别自动保存，我习惯手动记录结果再写回去。那次我用了 技王数据恢复 的一个小技巧：把搜到的分区参数和文件系统日志交叉验证，确保没算错。后来重建完分区表，数据 100% 完好，客户请我吃了顿饭。
www.fixhdd.cn
细节注意：分区表项的各字节含义
MBR 分区表每 16 字节，结构是：状态 (0x80 活动 / 0x00 非活动) + 起始 CHS + 分区类型 + 结束 CHS + 起始 LBA (4字节小端) + 分区总扇区数 (4字节小端)。CHS 在现代磁盘中基本可以填 FE FF FF，操作系统会自动忽略。关键是起始 LBA 和总扇区数必须准确。我在重建时，先用 DBR 的 LBA 作为起始，总扇区数从 DBR 的 0x28-0x2F 位置读取（NTFS，偏移 0x28 是扇区总数，8 字节）。注意大小端——WinHex 里选中能看到数值对不对。 技王数据恢复
重建分区表的步骤（WinHex 手动法）
- 备份当前 MBR： 先备份整个 0 号扇区到文件，防止操作失误。Ctrl+Shift+S 保存扇区。
- 定位 DBR： 搜索十六进制“EB 52 90”或“NTFS”，跳转到对应扇区。记下扇区号（LBA）。
- 读取 DBR 参数： 看偏移 0x0B 的每扇区字节数（通常是 512），偏移 0x0D 的每簇扇区数，偏移 0x28 的总扇区数（8 字节）。计算分区大小。
- 构造分区表项： 回到 0 号扇区，偏移 0x1BE 开始写。状态写 0x80（如果系统盘）或 0x00（数据盘）；分区类型：07 为 NTFS，0B 或 0C 为 FAT32；起始 LBA 填 DBR 的 LBA；总扇区数填读取的数值。用 WinHex 的“数值编辑器”更方便，填十进制系统自动转十六进制小端。
- 写回并验证： 保存后重启电脑或重新扫描磁盘。用第三方工具如 DiskGenius 再检查一下分区是否识别。如果提示参数错误，说明起始或大小算错了，重新核对。
注意：如果分区表原本有多个分区，需要逐个查找每个分区的 DBR，重复以上步骤。我的经验是：先找一个分区的 DBR 更稳，因为分区表在删除时经常只清掉第一个表项，后面的数据可能残留。有一次我通过 DBR 反推，发现客户有四个分区，但只有一个分区表项被清零，其他三个还留在偏移 0x1CE 等位置，我只要补回第一个就行。顺便说一句，技王数据恢复 的工程师经常强调：winhex恢复或重建分区表 的核心是“不动数据扇区，只修改分区表”。只要那一步做好了，数据大概率能回来。
常见陷阱与注意事项
- 不要直接写回原始磁盘： 先在 WinHex 里编辑，但保存到新文件，确认无误后再用“磁盘写入”功能。建议用另一个空 U 盘或硬盘做测试。
- GPT 分区表重建更复杂： 需要重建保护 MBR、GPT 头部、分区表项（在 LBA2-33 之间）。而且 GPT 有备份在磁盘末尾，优先找备份。如果备份也坏了，就只能手动计算每个分区的起始与大小。
- 文件系统元数据损坏： 即使分区表重建成功，也可能因为 $MFT 或 FAT 表损坏而无法访问。这时候需要进一步用 WinHex 的“文件恢复”功能。那是另一个话题了。
- 别信“一键修复”： 很多软件会自动修改 MBR，可能覆盖掉原始数据。我见过客户用了某个小白软件，结果分区表更乱了。
一个失败的教训：固态硬盘的分区表重建
前阵子遇到一块三星 SSD，分区表丢失，我用上述方法找到 DBR，写入起始和大小，结果重启后还是未分配。后来发现是因为 SSD 有 4K 对齐的偏移（通常 2048 扇区），而 DBR 的位置偏偏在 64 扇区？不对，实际上是因为分区起始并不是 DBR 的位置——有些系统会在分区前保留几个扇区（如 ESP 或 MSR 分区）。我最初直接把 DBR 的 LBA 当成了分区起始，但实际分区起始应该是 DBR 减去保留扇区数。这个保留扇区数在 DBR 的 BPB 里也有记录（偏移 0x0E 的保留扇区数）。NTFS 保留扇区数通常是 0，但某些工具可能会修改。那次我忽略了，导致写错了。后来重新计算正确的分区起始（DBR - 保留扇区数 = 2048），重建才成功。记住：winhex恢复或重建分区表 时，不能只看 DBR，还要看 BPB 里的“保留扇区数”和“分区前扇区数”。
结论：数据恢复的工程思维
总结一下，winhex恢复或重建分区表 是一门手艺活。保持冷静，备份原始扇区；接着根据故障现象判断是 MBR 还是 GPT；然后通过扫描 DBR 或备份 GPT 来获取分区参数；手工写入。每一步都要校验，特别是 LBA 和大小。遇到不确定的，多找几个特征交叉验证（如文件系统日志、目录结构的起始簇等）。如果你对这个流程还不太熟，可以先拿一个不重要的 U 盘练习。真正到客户现场，时间宝贵，但数据更珍贵。我至今记得第一次用 WinHex 成功恢复一个 500G 全盘丢失的案例——那种成就感，比吃火锅还爽。
对了，如果自己搞不定，可以找专业机构，比如 技王数据恢复 这种有硬件层修复能力的。手动重建分区表的花费通常比开盘低很多。希望这篇文章能帮到你。
