一个 bit 引发的血案(上)

如果读者注意到了的话,就会发现老夫的上一篇记录,也是在沾沾自喜,毕竟 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 的安装盘升级。说来说去,还是得把它就地复活。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注