これまでこのサイトでは、Surface Duoに「Surface-Duo Desktop Experience (Android 14 / 15)」などのカスタムROMを導入し、カスタマイズする手順の一例を紹介してきました。
しかし今回、諸事情によりMicrosoftの純正ROM（ストックROM）へ戻そうとしたところ、「PCから焼き込めない」「TWRPから転送できない」「起動しない」という三重苦のブートループ（文鎮化） に陥ってしまいました。
数日間にわたるデッドロック状態から、Androidの深層システムとコマンドを駆使して完全復旧（工場出荷状態）にこぎつけた全プロセスを、備忘録として残しておきます。
ブートループ時、唯一表示できた画面
絶望の症状：なぜ純正ROMに戻せなかったのか
当初、カスタムROMの導入時と同じようにFastbootから純正イメージを焼こうとしましたが、以下のような不可解なエラーの連続に見舞われました。
Macからの
fastboot flashがすべて拒否される
通常のブートローダー画面（青文字画面）からMacで書き込もうとすると、Device Errorを吐いて1文字も書き込めない。TWRPで大容量ファイルが弾かれる
TWRPを一時起動させ、adb pushで純正のOTA ZIP（約2GB）を送ろうとすると、cat: xwrite: No space left on deviceというエラーが発生。ストレージは128GB/256GBあるはずなのに、なぜか「2.6GBの壁」で転送が止まる。ddコマンドで強制書き込みしてもループする
TWRPの内部シェルから直接ブロックデバイス（/dev/block/bootdevice/by-name/boot_aなど）にddで焼き込んでも、通常起動すると無限ループする。
判明した「3つの罠」の正体
ログとシステム構造を解析した結果、これらのエラーは故障ではなく、複数の仕様とバグが最悪の形で噛み合った結果でした。
罠1：TWRPが「Xiaomi Mi 9」の移植版だった
Surface Duo専用の公式TWRPは存在せず、出回っているものはXiaomi Mi 9（cepheus）ベースの移植版です。そのため、Surface Duoのストレージ構造（fstab）を正しくマウントできず、実ストレージではなくRAM（メモリの空き容量2.6GB）を仮想ストレージとして誤認識していました。転送エラーの理由はこれです。罠2：カーネルの強力な書き込み保護（Write Protection）
su（root権限）を取得してddコマンドで物理ストレージを上書きして成功したように見えても、実はカーネルがブロックレベルで書き込みを黙殺していました。再起動すると古いカスタムROMの残骸が読み込まれ、パニック（ブートループ）を起こしていました。罠3：UEFIスロットロックと青文字画面の仕様
Surface Duoの通常のブートローダー画面（Boot Select）はセキュリティが極めて高く、PCからの書き込みを一律で拒否します。また、起動失敗を繰り返すと「このスロットは壊れている」とUEFIが判断し、強制的に起動不可フラグ（unbootable）を立ててしまいます。
解決編：完全復旧への道のり
これらの罠をすべて無効化する唯一の方法は、「一時起動したAndroidの内部から、Magiskの特権バイナリを使って物理ストレージを上書きし、純正の fastbootd へ移行する」 という力技でした。
ステップ1：Magiskによる「一時root起動」
本体のシステムはループしていても、外から送り込んだカーネルなら起動できます。
fastboot boot boot.imgで純正Androidを一時起動。起動したAndroidに「Magisk」アプリをインストールし、純正の
boot.imgをパッチ（改造）。パッチされたイメージをPCに引き抜き、再度
fastboot boot magisk_patched.imgで一時起動（これでroot権限を持ったAndroidが立ち上がる）。
ステップ2：Magiskのフラッシュエンジンで書き込み保護を突破
dd コマンドが弾かれるなら、Magiskのインストールスクリプトに丸投げします。
root状態で起動したAndroid上で「Magisk」アプリを開く。
インストール ＞ 「空きスロットにインストール (Install to Inactive Slot)」 を実行。
これにより、カーネルの保護をバイパスして物理ストレージにブートイメージが強制書き込みされ、UEFIの起動ロックフラグも回避されます。
ステップ3：正規の書き込みモード「fastbootd」への突入
Macと接続した状態で、一時起動しているAndroidから以下のコマンドを叩きます。
Bash
adb reboot fastboot端末が再起動し、画面に大きく 「fastbootd」 と表示されます。 この黒背景の画面こそが、Mac直結でも
Device Errorが出ないMicrosoft純正の書き込みモードです。
ステップ4：論理パーティションの再構築とフラッシュ
カスタムROM時代に破壊された枠組みを再作成し、純正のシステムを流し込みます。
Bash
# 枠組みの作成
fastboot create-logical-partition odm_a 0
fastboot create-logical-partition product_a 0
fastboot create-logical-partition system_a 0
fastboot create-logical-partition system_ext_a 0
fastboot create-logical-partition vendor_a 0
# 本命ファイルのフラッシュ
fastboot flash odm odm.img
fastboot flash product product.img
fastboot flash system system.img
fastboot flash system_ext system_ext.img
fastboot flash vendor vendor.img
# 起動コアのフラッシュ
fastboot flash boot boot.img
fastboot flash dtbo dtbo.img
fastboot flash vbmeta vbmeta.img
fastboot flash vbmeta_system vbmeta_system.img
ステップ5：完全初期化と再起動
最後にこれまでのゴミデータを一掃します。
Bash
fastboot -w
fastboot reboot
おわりに
これで、長いMicrosoftロゴのアニメーションの後に、見慣れた純正Androidの初期設定画面が立ち上がりました。
もし念を入れたい場合は、復旧後に純正のリカバリーモードから adb sideload を使って、大元の公式OTA ZIPを丸ごとクリーンインストールし直すと完璧です。 他機種ベースのTWRPの挙動に騙されず、「一時起動（fastboot boot）が動くなら本体は死んでいない」と信じて深掘りしたのが勝因でした。同じエラーに悩まされている方の参考になれば幸いです。
