虚拟机死循环重启修复指南：从关闭自动重启到系统恢复

1. 先给这个故障划个范围：什么情况算虚拟机死循环重启

虚拟机死循环重启，是我这几年被问得频率最高的虚拟机故障之一。症状往往特别唬人：虚机一开机，Windows 那个转圈图标刚出来，屏幕就一黑又自动重启；或者卡在“正在准备自动修复”，来回绕圈；更诡异的是在 Ubuntu 虚拟机里，界面刚要进桌面，系统又重新启动。很多人第一反应就是“虚拟机废了，重装吧”，但实际上绝大多数循环重启是能救回来的，而且不需要重装系统。

我习惯把“虚拟机死循环重启”先分清楚，因为不同场景的修复思路差别非常大，混在一起处理最容易走弯路。

1.1 几种循环的表象和“循环点”不一样

第一类：Windows 虚拟机开机后转圈，然后蓝屏一闪而过，马上重启，如此反复，永远进不去桌面。有的朋友形容“蓝屏连一个字都看不清”，这多半是 Windows 的“系统失败自动重启”机制在起作用。

第二类：虚拟机卡在“正在准备自动修复”或者“正在诊断你的电脑”，然后重启一遍又回到这个界面，周而复始。Windows 把引导记录损坏、更新补丁冲突、系统文件损坏这些问题，一律先丢给自动修复机制，修不好就循环，非常经典，Windows 11 的自动修复死循环尤其多。

第三类：虚拟机系统本身没问题，但虚拟机软件层面在异常。比如 VirtualBox 打开虚拟机时报“启动设备 R3 失败，错误代码 43”，或者 VMware 启动后宿主机直接蓝屏，这种问题的根源不在客户机系统里，而在宿主机的虚拟化环境上。

先把这个范围划清楚很重要，因为处理方式完全不同。第一类和第二类，要修的不是虚拟机软件，而是虚拟机里的 Windows 系统，所以得启动到恢复环境去动手术。第三类，改虚拟机设置、升级 VirtualBox、检查宿主机 BIOS 里的虚拟化开关就行，跟客户机系统没关系。

我列个表格，方便排查的时候对号入座：

所以接手的每个案例，第一步一定是确认“循环点”在哪里，而不是上来就给系统重装。记住一句口诀：先看循环点，再谈修系统。

1.2 先排除宿主机问题，再专心修客户机

第三类里最常见的，就是 VirtualBox 或者 VMware 提示虚拟机启动失败。VirtualBox 的“启动设备 R3 失败，错误代码 43”我处理过不少回，十有八九是下面这几个原因：宿主机 BIOS 里虚拟化功能没开；安装了 Hyper-V 或者 Windows 沙盒导致 VirtualBox 和虚拟化层抢占资源；还有安全软件把虚拟化驱动给拦截了。

这种“死循环”和客户机系统没什么关系，正确做法是重启进宿主机 BIOS，打开 Intel VT-x 或 AMD SVM。在 VirtualBox 里还要到“设置→系统→加速”页，确认“启用 VT-x/AMD-V”已经勾选。如果同时开了 Hyper-V，那就二选一，想用 VirtualBox 就把 Hyper-V 功能关掉，因为 Hyper-V 会把 CPU 的虚拟化扩展占住，VirtualBox 拿不到资源，直接就报错。

把宿主机因素排完之后，剩下才是客户机系统内部的问题，也就是我今天重点展开的内容。这个顺序别搞反了，否则在虚拟机里重装十遍系统都没用。

2. 为什么会死循环：Windows 的默认策略是“帮倒忙”的元凶

很多朋友第一反应是“虚拟机坏了”，其实不是。虚拟机文件一般没那么容易坏，真正常见的原因反而是 Windows 自己给自己设计的两套“自我保护”机制：故障后自动重启，以及自动修复。

2.1 “系统失败自动重新启动”把蓝屏代码吞了

Windows 默认在出现蓝屏（内核崩溃）之后，会自动重新启动。这个设计的本意是好的：服务器或者工作站的系统崩溃之后，如果没人盯着，能自动恢复上线。但对虚拟机来说，这个默认策略会带来一个特别麻烦的问题——蓝屏信息一闪而过，你根本看不到错误代码，也没法判断到底是驱动问题、磁盘问题还是内存问题，然后它又重启、又蓝屏，变成了死循环。

这就是“你的设备遇到问题，需要重启”那个界面的由来。用户只能看到白色提示文字，看不到屏幕底部那一串十六进制错误代码，比如 0x7B、0xC000021A，而这些恰恰是排查的关键。虚拟机里的 Windows 不像物理机，你可以拔电再看慢动作。因为它在虚拟环境里，重启速度更快，你更抓不住蓝屏信息，所以必须先关掉自动重启，让它稳稳停在蓝屏界面上，问题才看得见。

2.2 “正在准备自动修复”是另一套循环逻辑

如果引导记录、BCD 配置或者关键驱动出了问题，Windows 会在下次启动时进入 WinRE（Windows 恢复环境），自动诊断并尝试修复。这套机制本身是应急用的，没问题，但只要它没法真正修复问题，每次重启完它又被拉进“正在准备自动修复”，就会形成第二个死循环。

Windows 11 的自动修复死循环特别出名，因为新版系统默认开启了“自动修复”，而且修复逻辑有时候比较笨，很多场景下只是检测一下发现系统仍是坏的，然后又重启，再检测，再重启。要是你看到“自动修复”字样的循环，优先要怀疑引导记录损坏、最近的系统更新补丁没有正确安装，或者注册表配置单元加载异常。

2.3 还有两种容易被忽视的“虚拟层”因素

第一是 VMware Tools 或者 VirtualBox 增强功能。虚拟化增强包如果和客户机内核版本严重不匹配，可能在系统启动时触发驱动崩溃，导致虚拟机重启循环。尤其是给 VMware 虚拟机做快照恢复之后，增强功能状态和新内核对不上，这个问题更容易冒出来。

第二是启动介质顺序。有些虚拟机 BIOS 里配置了“从网络启动”或“从光驱启动”，如果硬盘启动失败，它会自动再走一遍网络启动，网络启动失败又回到硬盘，看起来也像重启循环。这种循环的界面和系统蓝屏不太一样，通常是黑屏、启动菜单反复闪。处理方式是在虚拟机设置里把硬盘启动顺序提到最前面，或者直接开机时进固件改启动顺序。

这三类原因放在同一个标题下，经常把新手搞得晕头转向，所以先把结论放这儿：想破局，先从操作系统的“自动重启”下手，因为它是最容易解锁、也是能让你看清真相的那一把钥匙。

3. “一招”破局：从恢复环境里关掉自动重启和自动修复

现在到标题里说的“这一招”。这一招不是说只敲一条命令就万事大吉，而是说它足够通用、足够快，能先把死循环打破，让你获得一个可以正常排查的状态。核心思路是：虚拟机反复重启没关系，我们强制它进 Windows 恢复环境，然后在命令行里直接把“自动重启”“自动修复”这两个机制干掉，让系统老老实实把错误摆出来。

3.1 怎么把虚拟机引导进恢复环境

在虚拟机里进 WinRE，有三条路可以走。

第一条，如果你能偶然看到桌面甚至锁屏界面，按住 Shift 不放，同时点电源菜单里的“重启”，系统会进入一个蓝色高级选项菜单，选“疑难解答→高级选项→命令提示符”就行。

第二条，如果你连桌面都进不去，就换个思路：把 Windows 安装光盘 ISO 挂到虚拟机的光驱里，比如 VMware 的“虚拟机→设置→CD/DVD→使用 ISO 映像文件”，然后重启虚拟机，在提示“按任意键从 CD 引导”时按回车，进入安装界面后点左下角“修复计算机”，接着走“疑难解答→高级选项→命令提示符”。

第三条，最实用但很多人不太注意的：在虚拟机固件阶段下手。VMware Workstation 里，可以在虚拟机开机时迅速按 F2 进 BIOS，把光驱或 U 盘启动放到最前面；也可以直接在菜单“虚拟机→电源→打开电源时进入固件”强制进固件。手速不好没关系，我们可以在 VMX 配置文件里加一句bios.bootDelay = "5000"，让虚拟机开机前停 5 秒，这样就有足够时间按键了。VirtualBox 类似，开机时按 Esc 可以弹出启动设备菜单。

进了命令提示符之后，一切好说。

3.2 使用 bcdedit 切断“自动修复”循环

在恢复环境的命令行里，先输入下面的命令：

bcdedit /enum

这条会列出当前 BCD 配置，你会在输出里看到类似identifier {default}或identifier {current}的字样。正常情况下，默认启动项就是{default}。

然后执行两个操作：

bcdedit /set {default} recoveryenabled No bcdedit /set {default} safeboot minimal

第一条，关掉开机时的自动修复入口，让 Windows 不再反复进入“正在准备自动修复”那个循环。第二条，让系统下一次启动直接进入安全模式。为什么要设安全模式？因为安全模式里不加载第三方驱动、服务也精简，大部分造成蓝屏循环的驱动压根不会运行，系统有很大概率能稳住，给你一个抢救窗口。

重启之后，系统会强行进入安全模式。如果安全模式能进，先备份关键数据，再排查。确认修复完成之后，记得把安全模式标记删掉，否则系统会一直停留在安全模式：

bcdedit /deletevalue {default} safeboot

3.3 蓝屏循环就改注册表里的 CrashControl

bcdedit 主要解决的是“自动修复循环”，但如果循环是“蓝屏一闪马上重启”，那要关的是 Windows 的系统崩溃自动重启开关。这个开关存在注册表里：

HKLM\SYSTEM\CurrentControlSet\Control\CrashControl

因为它对应的是 SYSTEM 注册表配置单元，就放在硬盘的系统分区里，所以就算系统进不去，我们也能在恢复环境里离线加载注册表来修改。操作步骤如下：

在命令提示符里，先加载系统分区上的 SYSTEM 配置单元：

reg load HKLM\OFFLINE C:\Windows\System32\config\SYSTEM

注意，恢复环境里的盘符不一定和系统里一样。如果不确定，用dir C:\Windows或者干脆diskpart先确认一下。加载完之后，查询到底是哪个 ControlSet 被启用：

reg query HKLM\OFFLINE\Select

输出里会有一个Current REG_DWORD 0x1之类的值，说明当前生效的是 ControlSet001。然后我们直接改对应键值：

reg add "HKLM\OFFLINE\ControlSet001\Control\CrashControl" /v AutoReboot /t REG_DWORD /d 0 /f

最后卸载配置单元，让注册表写回磁盘：

reg unload HKLM\OFFLINE

重启之后，下次蓝屏就不会自动重启了，会老老实实停在蓝屏界面，底部错误代码一清二楚。到这里，“死循环重启”这个最烦的问题就被打破了，剩下的工作是拿着错误代码去修真正的病根。

3.4 安全模式里的第一优先级不是修东西

很多人一进安全模式就急着重装驱动、跑修复工具，我建议先别急。安全模式能进，说明系统内核是活的。第一件事是把有价值的数据先复制到另一块虚拟磁盘或者共享文件夹里。死循环的重灾区往往就是系统盘，修的过程中可能出现二次损坏，先备份永远是第一优先级。

数据备份完，再根据蓝屏代码做系统级修复。如果你只是用 bcdedit 进了安全模式，修完记得删掉 safeboot 标志，别让虚拟机永远卡在安全模式里运行。

4. 拿到错误码之后，Windows 虚拟机的系统级修复

关闭自动重启只是“止血”。接下来得找到病根，否则下次启动可能又崩回去。这一节按常见程度，把真正要修的几类问题列出来，并给出可在恢复环境里直接执行的命令。

4.1 读懂蓝屏错误码：三个高频代码

蓝屏界面底部那串十六进制代码，是系统的“病历单”。我把虚拟机和物理机里最常遇到的三类先列一下：

看到 0x7B 和 0xED，先从磁盘入手。在 VMware 里检查虚拟磁盘是否还有空间、VMDK 文件是否完整；VirtualBox 里检查 SATA/IDE 控制器配置是不是被动过。如果磁盘文件没坏，就考虑是不是缺了引导所需的存储驱动，这时候进安全模式装一下 VMware Tools 或者 VirtualBox 增强功能，再重启看结果。

如果是 0xC000021A，重点怀疑系统文件损坏。走下面的离线修复流程。

4.2 引导记录损坏的修复命令组合

如果是自动修复循环，十有八九是 BCD 引导数据坏了。想让系统重新生成可用的 BCD，可以在恢复环境里依次执行：

bootrec /fixmbr bootrec /fixboot bootrec /scanos bootrec /rebuildbcd

/fixmbr重建主引导记录，/fixboot修复启动扇区，/scanos扫描系统盘上安装的 Windows，/rebuildbcd把找到的系统重新写进 BCD。有些情况下/rebuildbcd会提示找不到设备，那就先重启进 BIOS 确认硬盘启动项在第一位，再回来执行。

需要说明的是，对 UEFI 引导的虚拟机，/fixmbr基本没用，重点是bootrec /fixboot和rebuildbcd。VMware 默认生成的虚拟机很多是 UEFI 模式，别照搬 MBR 时代的旧教程。如果你不确定虚拟机是什么引导方式，进恢复环境后执行diskpart，再list disk，看有没有 ESP 分区就清楚了。

4.3 DISM 和 SFC：离线修复系统文件和更新补丁

进安全模式之后，如果系统文件完整性有问题，最顺手的是这两个命令。在安全模式命令行或者恢复环境命令行里都能跑，只是离线的话要额外带上盘符参数。

在线安全模式（或者正常桌面）里：

sfc /scannow dism /online /cleanup-image /restorehealth

在恢复环境命令行里，假设系统盘是 C 盘，写成：

sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows dism /image:C:\ /cleanup-image /restorehealth

DISM 这个命令对“系统更新装一半导致启动死循环”特别有效。很多 VMware 虚拟机死循环重启，就是在宿主机断电或者误快照回滚之后，Windows 更新事务没提交完整，留下一个半成品状态。DISM 能把这个状态修好，或者让系统跳过坏更新。

如果明确是某个更新导致的，可以用：

dism /image:C:\ /get-packages

查看安装过的补丁列表，找到可疑的补丁名，然后用：

dism /image:C:\ /remove-package /packagename:Package_for_xxx

把那个补丁卸掉。这个操作在恢复环境里跑，比在安全模式下点点“卸载更新”靠谱得多。

4.4 救不动的最后一招：快照回滚

如果上面的命令全部无效，或者你根本没时间慢慢修，那就用快照。前提是你之前拍过快照，这也是我特别想强调的一点：装完系统没拍快照，出问题就只能靠重装；装完系统拍了快照，出问题就是一分钟回滚。

VMware Workstation 在“虚拟机→快照→拍摄快照”里操作。VirtualBox 在“控制→生成备份”里操作。回滚前务必先想清楚：快照时间点和当前状态的差距。如果中间有重要数据且没同步出去，回滚会丢数据。

对生产虚拟机来说，别把快照当备份用，快照文件也会越滚越大、越滚越脆。正确姿势是快照加上定期导出 OVF 或者备份 VMDK，双保险。

5. Linux 虚拟机的重启循环：GRUB 救援、systemd 和磁盘空间

Windows 虚拟机循环重启的处理思路已经完整展开。但虚拟机里跑 Linux 的朋友同样会撞上循环，而且症状画风更野：Ubuntu 开机后黑屏，或者系统日志哗哗地刷，然后不断重启。这部分讲一下 Linux 虚拟机死循环的排查路径。

5.1 进 GRUB 改启动参数，进救援模式

Linux 系统多数情况下不是“无脑重启”，而是反复进“救援模式”或者“emergency mode”，也有显示管理器崩溃导致回到登录界面的循环。要打破循环，最有效的手段是进 GRUB 菜单，给启动项加上systemd.unit=rescue.target参数。

具体操作是这样的：虚拟机开机时，在 GRUB 菜单出现前狂按 Shift（BIOS 引导）或 Esc（UEFI 引导），看到菜单后选中当前内核那一行，按e进入编辑模式，找到以linux开头的行，在末尾追加：

systemd.unit=rescue.target

然后按Ctrl+X或F10启动，系统会进入救援模式而不是正常启动。救援模式下不启动图形界面和大部分服务，即使有坏的驱动或者满盘，也能给你一个可用的 shell。

如果 GRUB 菜单一闪而过根本抓不到，别忘了用上面说的 VMware bootDelay 参数，给虚拟机开机加几秒延迟，这样就能从容进菜单了。

5.2 磁盘空间满、fstab 写错，是两大循环元凶

进到救援模式之后，第一优先不是看日志，是先看磁盘空间：

df -h

Linux 虚拟机的死循环里，磁盘空间满占的比例非常高。当/分区 100% 满时，systemd 启动时连/var/log里的日志都写不进去，各种服务反复起、反复崩，最后表现为系统像死循环一样不断重启或者卡死。这种情况清理空间即可，通常删掉/var/log/journal里过期的日志就能缓上来：

journalctl --vacuum-size=100M

第二常见的是/etc/fstab写错。很多人给虚拟机加了一块虚拟磁盘后，照着网上教程往 fstab 里加了挂载项，结果磁盘 UUID 对不上，开机时系统挂载失败，默认进入 emergency mode。虽然系统没重启，但界面看过去一直报错，让人误以为系统坏了。处理方式是在提示输入 root 密码后，用编辑器把错的那一行注释掉，或者改成正确的 UUID。改完执行mount -a验证。

5.3 systemd 服务 Restart=always 造成的“假循环”

还有一个坑值得单独说：很多服务单元里写了Restart=always，服务一退出就自动重启。如果某个服务因为依赖缺失一直退出，systemd 就会不停拉起它，日志里全是“start request repeated too quickly”，整个系统看起来就像开机后一直在转圈。表面上看是死循环，其实只是单个服务在闹。

这种情况可以从 rescue.target 里把默认目标切回多用户模式测试：

systemctl set-default multi-user.target systemctl start multi-user.target

然后观察是哪个服务刷屏，再用systemctl disable 服务名把它先停掉，修好依赖后重新启用即可。这个思路比直接重装系统省事太多。

6. 平时多做三件事，虚拟机重启循环能少掉九成

最后说说预防，这部分性价比其实比任何修复命令都高。我自己管虚拟机的原则很简单：在没出问题的时候，花五分钟防住未来五小时的折腾。

6.1 装机后先关 Windows 自动重启

Windows 虚拟机装完系统、装完 VMware Tools 或 VirtualBox 增强功能后，马上到“此电脑右键→属性→高级系统设置→启动和故障恢复→设置”，把“系统失败”下面的“自动重新启动”的勾选去掉，再把“将事件写入系统日志”勾上。这样以后哪怕是真蓝屏，它也会停下来让你看清代码，而不是直接转圈重启，把故障原因盖住。

这一步做完，就等于把标题里那个“死循环重启”的一大半问题提前掐掉了。

6.2 给 VMware 设置启动延时，给 GRUB 留入口

平时就在 VMX 配置文件里加这行，方便以后进 BIOS 和 GRUB：

bios.bootDelay = "5000"

加了之后虚拟机会在开机时黑屏停顿几秒。你别嫌烦，真到需要按 F2 进固件、按 Esc 进 GRUB 的时候，这点延迟就是救命时间。VMware Workstation 也可以直接在“虚拟机设置→选项→高级”里调启动延时，不同版本位置略有差别，VMX 参数更通用一些。

如果不想手动改文件，虚拟机面板里的“打开电源时进入固件”功能也可以随时用，它就相当于替你按了 F2，不用赌手速。

6.3 快照该拍就拍，但别指望快照当备份

我给虚拟机做系统级变更前，习惯先拍一个快照，比如升级内核、装驱动、装大型软件之前，都拍一个“操作前状态”。一旦操作出问题，直接回滚，比任何修复工具都快。

但我必须强调一句大实话：快照不是备份。生产环境里我再怎么推荐快照，也不会用快照替代 VMDK 备份。因为快照依赖原盘文件，原盘坏了快照也就没了；而且长期不合并快照，虚拟机会越来越卡，重启时还可能出各种诡异问题。所以快照是“修复护身符”，真正的底裤还是导出备份。

我自己这些年处理虚拟机故障的经验，汇总下来就一句话：沉默的错误信息才是死循环最大的帮凶，一切修复的前提，都是先让错误“停下来”。靠关闭自动重启和自动修复进入一个稳定状态，再对症下药，九成以上的虚拟机重启循环都能在半小时内解决，根本不需要重装系统。