在修复 #Microshit #Windows 启动的问题，发现 #BCDEdit 生成的 GUID（例如
More: https://blog.gadflysu.com/post/windows-boot-options/
#boot #bcd
{be3d5682-d1e1-5c09-2198-8d864fef154d}）与原有的引导项的 GUID 竟然只有一位字符的差异。按照惯识，我认为标识符是随机字串，于是仅观察 GUID 的末尾几位字符来判别不同项；而事实上，Windows 通过复制生成的新引导项 GUID 是在原项 GUID 的基础上对其第一节字符串 (be3d5682) 进行递增（疑似），如对前例所指引导项复制所生成的新项 GUID 是 {be3d5686-d1e1-5c09-2198-8d864fef154d}。这导致我疑惑了半天到底哪里出了差错，怎么通过复制得到的新引导项的标识符和原来的一样——原来是我眼花。也许是我没见识。More: https://blog.gadflysu.com/post/windows-boot-options/
#boot #bcd
blog / gadflysu
Windows 启动引导选项 / blog / gadflysu
本文根据微软文档 Tools for Changing Boot Options for Driver Testing and Debugging 写成，由于该主题部分内容可能是由机器翻译，gadflysu 在其基础上主要对「Windows 启动选项」部分内容进行完善翻译，且有改动或删减。能力受限，若有不足还请见谅。 概述Windows 启动引导程序 (boot loader) 的体系结构包括： - gadflysu - blog / gadflysu
sudo cast
在修复 #Microshit #Windows 启动的问题，发现 #BCDEdit 生成的 GUID（例如 {be3d5682-d1e1-5c09-2198-8d864fef154d}）与原有的引导项的 GUID 竟然只有一位字符的差异。按照惯识，我认为标识符是随机字串，于是仅观察 GUID 的末尾几位字符来判别不同项；而事实上，Windows 通过复制生成的新引导项 GUID 是在原项 GUID 的基础上对其第一节字符串 (be3d5682) 进行递增（疑似），如对前例所指引导项复制所生成的新项 GUID…
为什么会出现问题需要修复呢？因为 #Microshit #Windows 不知道是如何设计的：对系统分区 (C:) 进行改动（包括调整大小、起始扇区位置等）会导致该系统引导项的
目前只知道可以将
#boot #bcd #bcdedit
device、osdevice 等值变成 unknown。之前听说过 Windows 对分区的识别并不使用 GUID，不知道是否与此有关。目前只知道可以将
device、osdevice 的值设定为 "partition=C:"、"partition=\Device\HarddiskVolume4" 这样的格式，而从 DiskGenius 看到的 \\?\Volume{fb1542f5-8d24-425c-ba1e-dd24a7583c7d} 这样的 GUID 路径则无从下手。我太菜了。#boot #bcd #bcdedit