我在修复 Windows 10 引导加载程序时遇到了麻烦。我尝试启动 Windows 10 安装程序 USB 并在那里执行修复启动。我尝试了此处建议的解决方案：如何从 Windows 修复 Windows 10 启动加载程序。我也尝试了这里详述的修复方法：http://www.fixedbyvonnie.com/2013/12/how-to-repair-the-efi-bootloader-in-windows-8/。这两个方法都没有解决我的问题。
问题背后的历史是这样的：我最初将 Windows 8.1 安装在我的主启动 ssd 上。后来我重新分区并将 Arch Linux 安装在同一个驱动器上的第二个分区上。然后我在 Arch Linux 安装之上安装了 Windows 10。后来我删除了 Windows 8.1 分区并重新扩展，以便 Windows 10 成为驱动器上安装的唯一操作系统。（后来我添加了第二个 ssd，上面有 Antergos Linux。）这一系列安装似乎将 Arch gummiboot 引导加载程序留在了驱动器上，但如果我直接启动驱动器，它总是直接将我转储到 Windows 引导加载程序，所以我甚至没有意识到 Linux gummiboot 加载程序仍然存在。
我一直在尝试让 GPU 直通设置正常工作 [https://www.reddit.com/r/pcmasterrace/comments/3lno0t/gpu_passthrough_revisited_an_updated_guide_on_how/] 我无法让 Windows 在虚拟机中运行，并确定这似乎是由于引导加载程序造成的。我尝试了各种方法来修复此问题（如上所述），但都不起作用。因此，我查看了安装 Windows 10 的 ssd，发现仍然有一个 ext4 分区（旁边是 fat32 分区，Windows 的 UEFI 引导加载程序就在这里）。我删除了 ext4 分区并在 fat32 分区上设置了“启动”标志。执行此操作后，现在不仅无法在 VM 中运行 Windows，而且我不再能够直接启动 Windows。现在我在启动时收到“PROCESS1_INITIALIZATION_FAILED”错误。
我进入 fat32 分区，发现还有一个 gummiboot 目录。我尝试删除它，但没有任何效果。然后我删除了 fat32 分区中的所有文件，并重新尝试了第一段中的解决方案。仍然没有任何效果。不过，当我进入主板 BIOS 时，我现在有 6 个不同的（全部不起作用的）Windows Bootloader 条目。
除了完全重新安装 Windows 10 之外，还有其他方法可以解决此问题吗？而且，如果我必须重新安装 Windows 10，是否有任何方法可以保存实际安装 Windows 10 的当前分区（而不是 EFI/boot 分区）并将其转储到新安装的顶部？（以及如何从 BIOS 中删除所有 Windows 10 引导加载程序条目？）
答案1
假设 Windows 安装到 GPT 磁盘。
要在 UEFI 固件上成功启动 Windows 10（也包括 Windows 8.1/8/7），您需要 GPT 样式磁盘上恰好有 3 个分区：
EFI 系统分区（通常为 100 MB - 500 MB）
Microsoft 保留分区（正好 128 MB）
Windows 分区（64 位 Windows 至少 20 GB）
最终您将拥有一个单独的“恢复”分区。
必须存在上述的前三个分区，否则 Windows 无法启动。
修复 BCD + 引导加载程序 + 引导管理器并在 NVRAM 中写入引导项的命令是启动盘-
bcdboot N:\Windows /s Z:
其中 N：是 Windows 分区，Z：是 EFI 系统分区。（稍后您必须使用 ReAgentC.exe 命令单独修复恢复加载程序。）
您还可以使用启动引导程序来自恢复环境的命令来修复启动（并不总是成功，但也修复恢复加载器）。
不用说你必须使用 EFI 启动来启动 Windows 安装/恢复媒体 (USB/DVD)。
UEFI 启动不使用 MBR 和分区启动记录进行启动，但使用以下命令重写 MBR（应该是 GPT 磁盘上的保护性 MBR）可能会有所帮助启动项命令，以防 MBR 被 Linux 安装篡改。Windows 不喜欢 GPT 磁盘上的“混合”MBR 格式。
参考：在 UEFI 和 BIOS 上修复 Windows BCD
希望这可以帮助。