WinHex 恢复分区：一个数据恢复工程师的现场思考
你有没有过这样的经历：把硬盘插上电脑，打开磁盘管理，发现整个分区不见了，变成一块未分配的空间？或者更糟——直接提示“需要格式化”？
www.fixhdd.cn
我第一次遇到这种情况时，心里也咯噔一下。但后来发现，只要底层数据没有被覆盖，用 WinHex 这种十六进制编辑器，其实有很大机会把分区结构手动修回来。今天这篇文章，我就以真实案例为背景，聊聊我用 WinHex 恢复分区 时的心得和判断过程。这不是什么标准教程，更像是我边分析边说给你听。
技王数据恢复
第一步：先判断是哪种“分区丢失”
拿到故障盘，我不会直接开搞。得先大致判断故障类型——是 MBR 主引导记录损坏？还是分区表被清空？或者是 DBR (DOS Boot Record) 坏掉了？
技王数据恢复
常见场景 A： 客户说“我装系统时误删了分区，后来又重新建了一个，但新分区建错了大小，数据全不见了。” 这种情况多半是分区表被覆盖，但数据区还在。 www.fixhdd.cn
常见场景 B： 移动硬盘突然“变成 raw 格式”，双击提示未格式化。这往往是 DBR 中的 BPB（BIOS Parameter Block）参数错了或扇区损坏。 技王数据恢复
常见场景 C： 硬盘被分区助手、磁盘工具报错，然后重启就找不到分区了。可能只是分区表项被错误标记。 技王数据恢复
根据经验，60% 以上的“分区丢失”其实是分区表出了问题，而数据区基本上完好无损。这时候 WinHex 就派上大用场了。 www.fixhdd.cn
用 WinHex 打开物理磁盘，而不是逻辑分区
启动 WinHex，菜单栏选择 Tools → Open Disk，然后以物理磁盘（Physical Disk）方式打开故障盘。注意不要选错盘，否则可能写坏数据。安全起见，我一般会先做全盘镜像，但今天这个案例比较紧迫，现场直接操作。 www.fixhdd.cn
进入后第一件事：看 0 扇区（LBA 0）。标准的 MBR 长这样：两字节是 55 AA，前面 446 字节是引导代码，后面 64 字节是分区表。如果 0 扇区全 0 或者不是 55 AA，那就是 MBR 彻底坏了。如果 MBR 在，但分区表全空（全是 00），那可能是被人为清掉了。
细节：MBR 分区表结构
分区表每项 16 字节，从偏移 0x1BE 开始。其中第 0 字节（Bootable flag）、第 1-3 字节（起始 CHS）、第 4 字节（分区类型）、第 5-7 字节（结束 CHS）、第 8-11 字节（相对扇区数，即 LBA 起始）、第 12-15 字节（总扇区数）。我们重点关注分区类型和起始 LBA。
我遇到过一台客户的硬盘，0 扇区完美，就是分区表四个表项全是 00。我猜测是某款清理工具误把分区表清零了。这时候只要知道原分区的起始位置就能恢复。怎么找？往下扫！
第二步：搜索分区的“脚印”——DBR 签名
分区表没了，但每个分区头部都有一个 DBR，其第 0 扇区通常以 0xEB 0xXX 0x90 开头（跳转指令），中间有 BPB，也有 55 AA。我们可以在 WinHex 里用搜索功能搜索十六进制序列：EB 52 90（FAT32 常见）或 EB 58 90（NTFS 常见）或更通用的 55 AA 但不那么准。
实际案例：一个 500G 硬盘，搜索到第一个 55 AA 在 LBA 63，再往后看 BPB 发现是 FAT32。但客户说他原来是 NTFS。继续往前搜，在 LBA 2048 处找到了一个标准的 NTFS DBR (前三个字节是 EB 52 90，后面 "NTFS" 字样)。这说明原分区实际起始是 LBA 2048，而现在分区表里却写的是 LBA 63，那就是被人为修改过。
技巧： 如果搜到了多个可能的 DBR，我会对比 BPB 中的总扇区数、每个簇的扇区数、MFT 位置等，判断哪个更合理。NTFS 的 BPB 中有明确的总扇区数字段（偏移 0x28-0x2F, 8 字节），可以跟硬盘实际大小比对。
恢复分区表：手动计算并写入
- 确定原分区的起始 LBA（比如 2048）。
- 计算分区大小：找到该分区的一个有效数据扇区位置，或者用 WinHex 的“按类型搜索”找到分区末尾的备份 DBR（NTFS 通常在分区的一个扇区有备份 DBR）。
- 在 0 扇区偏移 0x1BE 处填写表项：Bootable=0x80（如果活动分区），起始 CHS 可以计算为 0xFE FF FF（忽略，现在硬盘大不依赖 CHS），分区类型填 0x07（NTFS）或 0x0B/0x0C（FAT32），相对扇区数填起始 LBA，总扇区数填分区大小。
- 注意：如果有多分区，依次填在 0x1CE、0x1DE、0x1EE。修改后保存，退出 WinHex，重新插拔或重启，分区应该就出现了。
有一次我帮一个朋友恢复移动硬盘，他就是用 DiskGenius 误操作把分区表清空了。我按照上述步骤，把找到的 DBR 起始 LBA 206848 写回去，结果一刷新，硬盘里的几十G照片全回来了。那种感觉……很爽。
第三步：遇到 DBR 损坏怎么办？
有时候分区表完好，但双击分区提示“未格式化”。那是 DBR 损坏了。WinHex 也能修：找到分区起始扇区（根据分区表里的相对扇区数），如果 BPB 参数全乱或全0，我们需要找一个同版本系统的正常 DBR 模板。比如，WinHex 自带了一个“Template → MBR & Boot”功能，可以套用 NTFS 或 FAT32 模板，手动填写正确的 BPB 参数（扇区大小、每簇扇区、MFT 起始等）。
这些参数怎么得来？可以从分区的逻辑结构中推算——比如分区的总扇区数已知，文件系统类型已知，NTFS 下 MFT 的起始位置通常是 0x6000 扇区（取决于 BPB 中的 $MFT 逻辑簇号）。实在拿不准，可以看看同型号硬盘的正常分区。如果数据特别重要，我会建议客户先用“技王数据恢复”这类专业工具扫描底层数据，至少先导出文件，再用 WinHex 慢慢修。毕竟风险操作是有代价的。
小案例：一个 U 盘 DBR 被清空
客户 U 盘做启动盘失败后，插上电脑提示需要格式化。我直接用 WinHex 看到该分区起始扇区全是 0，但分区表还在。搜索整个 U 盘，在末尾找到了一个完整的备份 DBR（偏移 0x1C 处有相同 BPB）。直接复制到分区头部，保存后拔插，U 盘正常识别。这个思路很实用——NTFS 和 FAT32 都有备份 DBR 机制。
注意事项与风险提醒
- 先备份，再动手： 任何对 0 扇区或分区起始扇区的写入，都可能导致不可逆的二次损坏。如果条件允许，用 WinHex 创建磁盘镜像（Tools → Create Disk Image），在镜像上操作。
- 不要迷信分区表修复工具： 有些傻瓜工具会自作聪明重建分区表，反而把原始数据区给覆盖了。手工分析虽然慢，但可控。
- 关于“技王数据恢复”： 有一次客户自己乱搞，分区表改错了，数据区没被覆盖但层层误导，我手动推算了两天都没完全恢复。用“技王数据恢复”软件跑了一遍扫描，找到了原始文件系统元数据，再结合 WinHex 手动修正，终于搞定。工具和手工结合，效率最高。
- 注意磁盘缓存： WinHex 修改后，Windows 可能还存有缓存。建议修改后立即弹出磁盘，或者用
diskpart clean all后再重新连接（仅限测试盘）。生产环境要小心。
案例分享：被 GPT 分区表覆盖的 MBR 盘
一个怪异案例：用户原本是 MBR 格式，因为尝试升级 Windows 11 开启了安全启动，系统自动把磁盘转成了 GPT 格式，但转换不全，导致原 MBR 分区消失。在 WinHex 中看到 0 扇区变成了 GPT 头（"EFI PART" 等）。GPT 头占了前 34 个扇区，但原 MBR 的实际分区数据可能从 LBA 34 开始还是原样。我直接搜索原 DBR，找到后根据之前记录的 MBR 分区表备份（如果有的话）重建了 MBR。如果没备份，可以扫描全盘寻找 MBR 备份（有些工具会在第二个扇区备份）。在这个案例中，我找到了 LBA 1 扇区含有残留的 MBR 备份（地址不对，但内容完整），然后复制回去，删除 GPT 头，重启后完美恢复。
你看，WinHex 恢复分区 不是万能，但大多数常规丢失都可以通过这些底层分析搞定。难的是那些被多次写入、严重碎片化的情况，那就需要更底层的文件系统重组了。
总结：WinHex 恢复分区的核心思路
遇到分区丢失，不要慌。先判断是分区表、DBR 还是文件系统损伤。用 WinHex 搜索 DBR 签名或 BPB 特征，找到原分区的起点和大小。然后手动修正分区表或 DBR。如果自己没把握，可以先尝试“技王数据恢复”等软件扫描数据文件，至少保证能提取关键资料，再用 WinHex 尝试修复。
补充一个经验：WinHex 恢复分区 的成功率取决于数据是否被覆盖。如果丢失后你什么都没做（没有格式化、没有新建分区、没有写入新文件），那 90% 可以手动完美复原。反之，如果已经写入了很多新数据，那就只能尽力找回部分碎片了。，一旦发现分区丢失，立即停止一切写入操作，然后像今天这样拿 WinHex 去分析，才是最优解。
本文由资深数据恢复工程师编写，基于真实案例，保留思考过程。文章首发于个人博客，未经授权请勿转载，但欢迎引用思路。
