billccn

这里面有几个问题，你要把它分别弄清：
0 、找到真正 C 盘的 UUID ，这是你正确修复的基础，因为你 Win to go 的盘也做过 C 盘，所以有些设置里可能混淆了。Win 系统用 mountvol 命令不加参数可以看到各个盘的 UUID 。
1 、注册表里的盘符只需要把 C 盘的修好，其他可以导出 reg 文件以后删除，等进入系统以后再重建。C 盘对应的二进制信息里面就有 UUID ，但是因为 endianess ，部分字段的字节顺序和 mountvol 看到的是反的。
2 、我猜导致你问题的是 KB5034441 更新，它需要扩容 Recovery 分区，但是错误的操作了内置硬盘而不是你的优盘。我有个印象是 recovery 分区不对的话即使不需要 recovery 也无法正常启动，你可以尝试从 BCD 里把 recovery 信息暂时删掉。
3 、其实 BCD 重建比修起来更方便，把 EFI 系统分区挂载以后把里面的 EFI 文件夹改名（或者备份到其他地方)，然后用这里面的命令： https://www.tiger2doudou.com/doku.php/windows:os:reinstall_efi_partion_via_bcd_command 。注意 PE 系统里的盘符是无所谓的，BCD 里面记录的都是 UUID ，重建好以后用 bcdedit /enum /raw 命令可以确认系统盘的 UUID 是正确的。

可以进系统以后你可以参照 KB5028997 重建 recovery 分区。

我觉得要重点提出 1 楼说的“这中间有可能从有竞争变为无竞争（ volatile ）”，我觉了楼主可能犯了并发编程里一个常见是思维错误就是我“刚刚” 判断了一个条件，后面就不用判断了。

当你看到这些国产 app 安装包小则几百兆，大则直奔 3A 休闲游戏的时候，你就知道里面屎山堆得多高，出这些 bug 都不奇怪。

要知道 Windows 98 的安装盘也就 700MB ，里面还带了几千个设备的驱动,虽然 98 经常蓝屏，但是人家好歹是有优化的。

压缩空气效果好，一定要在屋外弄，最好带上 n95 和护目镜。这个气体很冷的，吹一下换一个地方，否则会有冷凝水。

除非全密封的氦气盘，盘体本身不要碰压缩空气，拿拧很干的布擦擦除电路板的几面是可以的。

吸尘器我试过效果不好，因为嘴太大了，压力不够。

@paopjian 这个问题到现在还有啊，比如嵌入式系统 32 位的已经很高级了，用 8 位机的也大有人在，很多机器连整数除法都做不了，这也是 C/C++最大的客户群。

@cnbatch 我发出来才看见你的，我觉得你说的“int 必须比 short 宽，long 必须比 int 宽”虽然让部分初学者可以更清楚的了解这些类型的区别，但是与系统编程语言的定位不符合。比如说我记得早期的 64 位机就有完全不支持 16 位长度的指令集，这样 short 也必须是至少 32 位，那么 int 就得 64 位，long 不能 128 位吧？

这个问题的本质是 C/C++定位是系统编程语言，数字类型的是为了方便在不同指令集之间移植来设计的，比如说：

* 所有类型都只有最小宽度而没有绝对宽度，因为不是所有指令集都有操作各种宽度的指令
* int 就是在那个平台寻址范围内做下标比较合适的长度
* short 就是可能比 int 节省空间，但是至少有 16 位； long 就是至少有 32 位

当然我也觉得理想是美好的，现实是骨感的，这些语言出现不久互联网就爆发了，有了跨机型交换数据的需求，导致这些依平台而变的类型不好用。

理论上说交换格式可以和内存里的数据类型分离，比如内存里的 struct 用 int, long 等类型，交换时翻译到到固定长度的 char[]（这样还解决了 endianness ），但显然没有几个人这么勤快。

当然我觉得 long long 出现时，这个情况已经很明显了，应该直接定义 int64 而不是新增一个关键字。

@Sodacooky 我觉最好还是不要拿 C++的 auto 来比，因为写模板的时候很多中间值你都无法知道它类型是什么，如果不用 auto 就得声明一个新的类型参数，但有的时候又不能改变 API ，导致模板函数套模板函数，编译越来越慢。

Java 的 var 这个就是可有可无，因为类型永远是清楚的。

另外我觉得在 PR 里读到 var 很多的 Java 有点像读找不到实例的 C++模板，你只能靠变量名猜这代码是在干啥，至于对不对是完全无法确定。