如果读者注意到了的话，就会发现老夫的上一篇记录，也是在沾沾自喜，毕竟 Windows 自己安装更新屡屡失败，老夫亲自出手，就把问题消弭了。然而世事无常，波诡云谲，喜悦并未持续很久，噩厄来临。事后回顾，显然上一次的问题本应引起怀疑和关注，然而终究还是没能得到重视并防患于未然。

要说微软那也是真勤快，更新完毕的系统运行起来也不知道有没有到一天，就又有了新的更新，眼看着它下载完毕，要求重启。人家这么小小的一个愿望，满足一下不过分吧？再说了，如果我这个时候不让它重启，鬼知道下回它自己个会在什么你意想不到的时候重启。这一重启，粗大事了！老夫直接得到这样一张死脸：

连续重启了好几次，纹丝没动。要说不慌，那是假的，原本还计划更新完成后再开干满足 Google Play 商店要求的活儿呢，截止日期就在本月底。这个屏幕的出现可以说是干净利索，绝不打喯儿，在一定程度上说明了，这是处于系统引导的相当早期。错误码和错误信息能看明白，但是这些信息不够啊，什么的校验和错了呢？更多的信息，都成方块了。既然如此，恐怕是连汉字字库的加载还没有完成，难道 BCD 相关的东西出错了？

用 PE 盘引导，跑到系统分区的 \Boot 目录下，用 bootice 打开 BCD 文件一看，嗬，还真有可能，里面的条目关联的硬盘设备都成了未知的了，赶紧改了过来。重启，照旧。后来一想，不对，BCD 文件搞错了，不是 C:\Boot 下这一份在起作用，应该是 ESP 分区里的才是有效的。可到 EFI\Microsoft\Boot 下查看 BCD 文件，里面的设备等信息完全没错。这样的话，引导过程显然应该已经交到了系统分区里的 \Windows\System32\winload.efi 手里了，那出错的时候，究竟是到了哪一步了呢？

用错误码 0xc0000221 以及相关的错误信息搜索出来的案例，跟遇到的真实情况有一个巨大的差别，那就是别人在遇到 0xc0000221 时，上面多出来一行信息，其中会清晰指出是哪个文件的校验和有问题，如这样（网图，非常相似，不过它的 Info 部分反而是其它语言，导致显示异常）：

看到类似这样的图之后，尽管已经想到我所看到的方块儿想必跟上图中的英文是意思一样的，但还是顺手去 BCD 文件里把语言从 zh-CN 改成了 en-US，谁知道下回蹦出什么可能有帮助的信息来呢。既然目前已经知道引导流程已经到了操作系统，那何不使用 Windows 10 的安装介质引导来修复一下？说干就干。把给兜少看片用的一个 U 盘征用了，使用微软官方的媒体创建工具下载并创建了一个 Windows 10 的安装盘。用之启动后后，选择修复计算机，它装模作样转一会儿圈，然后显示“无法修复”。无法修复的原因是什么？老夫陷入沉思。会不会跟本机是 Grub2 主导的多重引导有关，而 Windows 安装盘不认可除它自己独占引导以外的方式？顺着这个思路，再次把 bootice 运行起来，找到常年吃灰的、之前备份的 Windows 10 独占安装后的磁盘前 63 个扇区就恢复到了磁盘上。再重启，咦，怎么还是 Grub2？糟了，想歪了，MBR 根本就不适用，现在可是 UEFI 引导方式啊！（其实中间还行差踏错一步，那就是误把 Windows 10 的 MBR 写入到了用以引导的 PE U 盘上了。幸好，一，写入前做了备份；二、Windows 10 的 MBR 显然也可以正常把 PE 引导起来；把备份了的 MBR 写回 U 盘后留意了一下，bootice 将之识别为 FbInst 的 MBR）好在——再一次好在——也有备份，忙不迭恢复回去。这一个回合的折腾，折腾了个寂寞。

修复是没戏了，要不原地用安装盘升级/重装一下？似乎记忆里这样安装后，原来的用户数据、程序等都不受影响的。真到操作到那一步，看到了也意识到了，对哦，保留用户程序和数据是需要在原系统已经启动的情况下直接运行 setup.exe 才可以的，而用安装介质进行的安装是不可以的。这一下，顺便把我的另一个想法也浇灭了：用 Windows 11 的安装盘升级。说来说去，还是得把它就地复活。