Surface Duo 救砖

碎碎念：2025年11月30号，我购买了自己心水已久的SurfaceDuo并体验（其实是被11月整麻了，想买个玩具奖励奖励自己），结果1天就变砖了。后来按照老方法查找XDA，Reddit，完全没有解决方法，大家都砖着（像极了当年我玩多亲的时候进不去Fastboot，结果要上电前就按着音量下，然后插电直接就进了），后来自己借助ChatGPT慢慢摸索到了一些解决方法，一点一点给重建回来了。

PS：ChatGPT从头到尾胡说八道，里面很多信息其实都是胡编乱造出来的，本人甚至因为ChatGPT差点从Fastboot砖变黑砖，Fastboot砖其实也是本人疏于判断执行以后造成的。

1. 问题描述

鉴于之前小米Mix2s使用Mindows工具箱刷Windows比较顺利，故这次也打算使用Mindows工具箱刷写。不料因为Mindows工具箱里面的驱动版本已经更新到最新但是UEFI没有更新，在UEFI部署的时候直接将分区表破坏，导致无法开机，只能无限循环进BootLoader。Fastbootd，Recovery都没有办法进入。本以为只是一次普通的小问题，把boot刷进去就好了，结果完全无法操作。执行flash的时候提示如下：

C:\Users\bisucrose\Desktop\Duo\platform-tools>fastboot flash partition ./duo_backup/gpt_main.bin
Warning: skip copying partition image avb footer (partition partition size: 0, partition image size: 32768).
Sending 'partition' (32 KB)                        OKAY [  0.012s]
Writing 'partition'                                FAILED (remote: 'Flashing is not allowed for Critical Partitions ')
fastboot: error: Command failed

C:\Users\bisucrose\Desktop\Duo\platform-tools>fastboot flash boot extracted/boot.img
Sending 'boot_a' (98304 KB)                        OKAY [  2.596s]
Writing 'boot_a'                                   FAILED (remote: 'Error flashing partition : Device Error')
fastboot: error: Command failed

C:\Users\bisucrose\Desktop\Duo\platform-tools>fastboot boot "C:\Users\bisucrose\Desktop\Mindows\bin\res\duo\and\rec-12.img"
Sending 'boot.img' (51960 KB)                      OKAY [  1.374s]
Booting                                            FAILED (remote: 'Failed to load/authenticate boot image: Device Error')
fastboot: error: Command failed

可以看到，这个问题并不是单纯的 boot 分区损坏。因为如果只是 boot 坏了，那么理论上刷入官方 boot 或者临时启动一个 recovery 以后，机器至少应该有反应。但是实际上无论是 flash boot 还是 fastboot boot 都失败了，说明这时候坏掉的并不只是 boot，而是 boot 后面依赖的那一整套分区状态也已经不正常了。

2. 为什么 flash 失败，而且 boot 也失败

先说为什么 flash partition 会失败。partition 这种东西本质上已经属于 Critical Partitions 了，Duo 即使已经解锁 bootloader，也不会让你在当前状态下随便写这种分区，所以它直接回了：

1	remote: 'Flashing is not allowed for Critical Partitions '

这个报错说明一件事：底层引导链还活着，但是它不允许你直接修改最关键的分区。

再说为什么 flash boot 也失败。这里最容易误判成“是不是 boot.img 不对”，但后面我折腾下来发现并不是这么简单。因为如果只是 boot 镜像本身有问题，那么大概率会报签名不对、镜像格式不对之类的错误；而这里返回的是：

1	remote: 'Error flashing partition : Device Error'

这更像是当前机器内部的分区状态已经不一致了，导致 bootloader 虽然还能识别到你发过去了一个 boot.img，但是在真正准备写入或者校验的时候直接出错。也就是说，这时候的 boot 分区问题很可能只是表象，真正坏掉的是后面的动态分区或者 metadata。

至于为什么 fastboot boot 一个 recovery 也失败，道理其实和上面差不多。因为 fastboot boot 并不是“只要解锁了就必定能启动任何镜像”，它仍然会做加载和校验。这里报的是：

1	remote: 'Failed to load/authenticate boot image: Device Error'

说明这台机器当前不仅不能正常写入 boot，连临时加载一个外部 boot 镜像也过不了。到这里基本可以判断，问题已经不是“刷个 boot 就好”这么简单了。

3. 为什么刷入 super_dummy.img 以后反而修好了

这里是整个修复过程中最关键，也最反直觉的一步。

我一开始一直在盯着 boot 分区折腾，后来才发现真正有问题的是 super 里面那套动态分区状态。Surface Duo 的 system_a、vendor_a、product_a、system_ext_a 这些都不是独立的物理分区，而是 super 里面的 logical partitions。前面 Mindows 工具箱把分区表和后面的状态搞乱以后，bootloader 虽然还能进，但是它已经没法正常处理这套动态分区了。

这时候直接重刷官方 super 也不一定有用，因为旧的 metadata 和旧的校验状态还在，新的东西未必能顺利接管。所以要先用一个极小的 dummy 文件把 super 的旧状态破坏掉。命令如下：

1 2	fsutil file createnew super_dummy.img 4096 fastboot wipe-super super_dummy.img

这一步做完以后，旧的 super metadata 会被清掉。可以理解为先把原来已经乱掉的逻辑分区状态彻底废掉，让后面新的 super 重新建立映射关系。也正因为这样，后面再刷官方提取出来的 super chunk 时，机器终于不再卡在原来那套坏掉的状态里了。

所以后面能修好，并不是因为这个 super_dummy.img 本身有什么神奇作用，而是因为它先把旧的错误状态清掉了，给后面官方 super 接管铺了路。

4. 修复过程

4.1 先清掉旧的 super 状态

先在 Windows 下创建一个 4KB 的空文件：

1	fsutil file createnew super_dummy.img 4096

然后执行：

1	fastboot wipe-super super_dummy.img

执行完这一步以后，旧的 super metadata 基本就没了。此时机器还是不能正常开机，但是状态已经和前面不一样了。

4.2 刷入官方 recovery 包里面提取出来的 super

微软官网的恢复镜像虽然说是给 adb sideload 用的，但本质上它还是 OTA 包，里面有 payload.bin。把 payload.bin 解开以后，就能拿到 boot.img、vbmeta.img、dtbo.img 以及 super 相关的 chunk。

例如：

1	payload-dumper-go payload.bin

提取出来以后，把 super 对应的分片重新刷回去。这里不同版本的 recovery 包文件名可能不一样，总之就是把解出来的 super 相关镜像按顺序刷完。

fastboot flash super super_1.img
fastboot flash super super_2.img
fastboot flash super super_3.img
...

这一步时间比较长，而且中间很容易怀疑人生，但它是必须的。因为前面不把旧的 super 状态清掉，后面这一步也很难成功。

4.3 super 恢复以后，boot 终于能过验证了

前面之所以 fastboot boot rec-12.img 一直报：

1	Failed to load/authenticate boot image: Device Error

并不一定是因为这个 recovery 本身坏了，而是因为当时整台机器后面的分区状态本来就是乱的。前面 super 重建完以后，再去使用官方 recovery 包里面提取出来的 boot.img，情况就不一样了。

这里用的必须是官方 recovery 包里提取出来的官方 boot.img，而不是随便找来的第三方 boot。

1	fastboot boot extracted\boot.img

到这里机器终于不再是直接报错，而是能够继续往 recovery 那条链上走了。

4.4 为什么改版 TWRP 不能直接用

这里还得专门说一下那个改版 TWRP。

Surface Duo 其实并没有完善适配的 TWRP，我这里能进的那个 TWRP 本质上是魔改版本，只能说“能亮”。它的问题很多：

触摸基本不能正常使用
对 Duo 的分区和 block 设备支持并不完整
它并不是官方 recovery，很多官方更新和恢复操作它根本处理不了
它最多只能作为一个临时跳板，不能作为最终修复环境

也就是说，这个改版 TWRP 不能直接拿来恢复原装系统。它的作用更多是帮助我在某些阶段把机器从完全死锁状态里拉出来，或者作为进入后续环境的中转站。真正能完成官方恢复流程的，还是 Duo 自己的官方 recovery。

4.5 进入官方 recovery，恢复原装系统

前面的 super 和 boot 都恢复到官方状态以后，机器终于可以进入官方 recovery。到这里事情反而简单了，因为微软给 Duo 设计的正经恢复方式本来就是 adb sideload。

把微软官网下载到的恢复包放好，然后执行：

1	adb sideload ota_b1-12-customer_att_2022.902.48.zip

这里包名按你自己的版本来。

sideload 完成以后，官方 recovery 会把 system、vendor、product 以及相关状态重新处理一遍。刷完重启，机器终于恢复正常启动，原装系统也回来了。

5. 小结

这次救砖最容易误判的地方，就是看见 boot 报错以后，下意识觉得“boot 坏了，那就刷 boot”。但实际上这个问题并不是单独一个 boot 分区的问题，而是后面的 super 动态分区状态也已经乱了，所以单刷 boot 根本解决不了。

真正有效的顺序是：

先用 super_dummy.img 清掉旧的 super 状态
重刷官方 super
让官方 boot 重新能够通过加载和校验
借助改版 TWRP 作为跳板进入官方 recovery
最后在官方 recovery 中 sideload 恢复原装系统

Welcome to bisucrose's Island