Windows 11 关闭 VBS 与内存完整性：原理、注册表与排查指南

1. 先搞清楚“基于虚拟化的安全性”到底在管什么

很多人是先在msinfo32里看到那一行“基于虚拟化的安全性：正在运行”，然后开始到处找怎么关。也有人是反过来的——先发现某个老驱动装不上、某款游戏帧数不对劲、某个虚拟机软件启动就报冲突，顺着排查才摸到 VBS 这条线。不管是哪条路径进来的，动手之前先把概念掰开，能省掉后面一大半来回折腾的时间。

基于虚拟化的安全性，英文写作 Virtualization-Based Security，圈内一般简称VBS。它不是某一个具体的安全功能，而是一个“底座”。做法是用 CPU 的硬件虚拟化能力（Intel 平台叫 VT-x，AMD 平台叫 SVM）在正常的 Windows 系统底下再拉起一层很薄的虚拟化环境，然后把几项敏感的安全机制塞进这层环境里跑。这样即使主系统被攻破，攻击者也够不到那层里保存的东西——思路有点像在自家院子里单独修一间带独立门锁的保险房，重要东西不放客厅。

这层底座之上跑的东西主要有几个：HVCI（Hypervisor-enforced Code Integrity，也就是 Windows 安全中心里那个“内存完整性”）、Credential Guard（凭据保护）、System Guard Secure Launch，以及内核模式硬件强制堆栈保护。它们各自管的事不一样，但共用同一套虚拟化底座。所以你会看到一个很常见的现象：关掉“内存完整性”之后，msinfo32里那一行可能从“正在运行”变成“正在运行，但未启用所有安全属性”，而不是直接跳到“未启用”。这不是没关掉，而是底座还在、上面的租客少了一个。

为什么 Windows 11 默认就给打开？主要是两个背景：一是近几年的攻击手法越来越多地转向内核层和凭据窃取，传统的杀软拦不住；二是新装机的硬件普遍支持，微软索性把它设成出厂推荐配置。尤其从 22H2 之后，不少 OEM 预装机型和全新安装的镜像默认就把内存完整性打开，后续版本对易受攻击驱动的黑名单检查也更严——这块直接影响的就是那些签名老旧、本身有漏洞的驱动。

所以真正要判断的是：你要关的是整个 VBS 底座，还是只需要关掉上面的某一块（比如内存完整性）？这两个目标对应的操作完全不同，代价也差得很远。我在后面第 3 节会给两条不同的路径，你按自己的实际需求选，别一上来就拿最猛的那套命令往上招呼。

2. 关之前先算两笔账：能得到什么，会失去什么

2.1 性能账：纸面收益和实测收益的差距

网上流传最广的说法是“关掉 VBS 游戏帧数暴涨”，这话得拆开看。VBS 启用时，CPU 要在主系统和安全环境之间做上下文切换，加上 HVCI 对内核代码的实时校验，确实存在额外开销。但这个开销的大小极度依赖具体负载：跑分软件里那套纯 CPU 密集型测试，差异往往在个位数百分比；而某些对延迟敏感的老游戏、或者加载了大量第三方驱动的场景，体感差距会更明显一些。

我自己在几台机器上做过对比（同一台机器、同一套驱动、同一版本系统，只切换 VBS 状态，每项跑三轮取中位数），大致印象是这样的：

这里必须说清楚一点：表格里那些“提升”是我自己环境下的观测，不代表所有机器都这样。不同 CPU 代际、不同主板固件、不同驱动组合，差异可以大到让人怀疑人生。如果你只是听说“关了能提速”就想动手，我建议先花十分钟做一次 AB 对比：记下当前状态下的帧数或跑分，关掉之后再测一遍，数据不会骗人。很多时候你会发现，真正拖慢你的其实是后台更新、电源计划、或者是某个一直在扫盘的杀软实时监控。

2.2 代价清单：哪些东西会跟着受影响

关 VBS 不是关一个开关那么简单，它牵着一串功能。下面这些是我实际遇到过会受影响的：

• 内存完整性（HVCI）：这是最直接的一项。关掉之后，内核里那些试图执行未签名或签名有问题的代码，拦截力度会下降。对普通用户来说未必有感知，但对经常装来源不明驱动的机器，风险是实打实增加的。
• 凭据保护（Credential Guard）：主要在企业环境用，用来隔离域凭据。家用场景基本不涉及，关掉影响不大。
• 部分企业合规要求：有些单位的终端合规基线里明确要求 VBS 处于运行状态，你私自关掉可能在资产核查时被标红。这个得提前问清楚。
• 驱动拦截策略：VBS 打开时，系统对易受攻击驱动的阻止列表生效更彻底。关掉之后，某些老驱动能装上了——这既是好处也是坏处，好处是兼容性上来了，坏处是那些驱动本身确实有洞。
• 虚拟化相关软件的冲突：这条容易被忽略。VBS 占用了底层虚拟化能力，某些第三方虚拟化软件（虚拟机、模拟器）在和它抢资源时会报错或性能骤降。关掉 VBS 常常能让这些软件恢复正常，但如果你同时还需要用 Windows 自带的虚拟机平台或者 WSL2，那就得仔细权衡，别一脚踩空。

注意：关掉 VBS 之后，如果 BIOS 里的 VT-x / SVM 还开着，WSL2 和 Windows 沙盒这类依赖“虚拟机平台”的功能通常仍能正常工作。真正会让它们废掉的是在 BIOS 里直接把 CPU 虚拟化关掉，或者把“虚拟机平台”这个可选功能卸载。这两件事的动作和后果完全不同，别混为一谈。

2.3 什么情况下确实值得关

我不主张无脑关，但以下几种情况我认为关掉是合理选择：

第一种是老硬件配新系统。CPU 本身支持虚拟化，但内存只有 8GB，VBS 那层环境又要占一部分，日常使用已经开始卡顿，这时候关掉换来的是实打实的可用性提升。

第二种是专业软件兼容性。某些行业软件（尤其是带加密狗、老式内核驱动、特殊采集卡驱动的）在 HVCI 开启时直接装不上或蓝屏，厂商又短期不更新驱动，那只能从系统侧让路。

第三种是虚拟机密集使用者。如果你不依赖 Windows 自带的虚拟机平台，而是常年用第三方虚拟机做实验环境，且明确感受到资源冲突，关掉 VBS 能减少一层占用。

第四种是明确知道自己要什么的折腾党。愿意承担风险、能自己判断来源、不把机器当生产工具，那随便折腾没问题。

反过来说，如果你机器上存着工作资料、财务数据、或者你是那种“看到弹窗就点允许”的使用习惯，我诚恳建议留着它。这点性能不值得拿数据安全去换。

3. 三条路径把“正在运行”改成“未启用”

3.1 图形界面路线：适合绝大多数人，先从最小改动开始

如果你只想关掉内存完整性这一块（这是最常见的诉求），最省事的做法是走 Windows 安全中心：

1. 打开“Windows 安全中心”，左侧选设备安全性。
2. 找到内核隔离，点进去。
3. 把内存完整性的开关拨到关。
4. 系统会提示重启，重启后生效。

这是改动面最小的一条路。关完之后去msinfo32看，那一行大概率会变成“正在运行，但未启用所有安全属性”。很多人到这一步就以为失败，其实不是——底座还在，只是 HVCI 这个租客搬走了。对绝大多数游戏和驱动兼容性问题来说，这一步已经足够解决。

如果你的目标是彻底关掉整个 VBS 底座，图形界面里还有个地方要处理：

1. Win + R输入gpedit.msc（家庭版默认没有这个，见下面的注意事项）。
2. 依次展开计算机配置 → 管理模板 → 系统 → Device Guard。
3. 找到打开基于虚拟化的安全，双击，设为已禁用。
4. 确定后重启。

注意：Windows 11 家庭中文版默认不带组策略编辑器，强行安装的方法五花八门、稳定性参差。家庭版用户直接跳过这一步，用下面 3.2 的注册表路线，效果一样，还少装一个东西。

另外还有一条路径在“启用或关闭 Windows 功能”里：把Hyper-V、Windows 虚拟机监控程序平台、虚拟机平台这几个勾去掉。但我要提醒一句，这三个是 WSL2、沙盒、以及部分安卓子系统的命根子，去掉之后这些功能会直接罢工。除非你确实不用它们，否则别碰。很多人为了关 VBS 顺手把“虚拟机平台”也取消了，结果第二天发现 WSL2 起不来，又回来找原因，这就属于自己给自己挖坑。

3.2 注册表与命令行路线：更彻底，但要认清每条命令的作用范围

图形界面处理不了的情况（比如被策略锁了、家庭版没组策略、或者你想批量处理），就得走注册表。以下所有操作都需要管理员权限，改之前建议先导出一份注册表备份，出问题能回滚。

先看 VBS 主开关的位置：

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard] "EnableVirtualizationBasedSecurity"=dword:00000000 "RequirePlatformSecurityFeatures"=dword:00000001

EnableVirtualizationBasedSecurity设为 0 表示不启用 VBS。RequirePlatformSecurityFeatures里，1 代表仅要求安全启动，3 代表安全启动加 DMA 保护，这个值在关闭状态下影响不大，保持默认即可。

接着是 HVCI 这一块，它藏在子键里：

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity] "Enabled"=dword:00000000 "Locked"=dword:00000000

Enabled是 0 关、1 开。重点在Locked这个值：如果它是 1，说明这一项被 UEFI 层面锁定了，你在系统里改注册表它也不认。要解锁，得先回到 Windows 安全中心把内存完整性开关关掉并重启，让系统自己把Locked复位成 0，之后注册表的修改才会真正生效。这是很多人“改了没用”的根本原因。

凭据保护在另一个位置：

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA] "LsaCfgFlags"=dword:00000000

家用机器基本可以忽略这项，企业机器改之前务必确认合规要求。

命令行侧，用 PowerShell 读状态比改更方便，改的话推荐用reg add：

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

改完必须重启，不重启一切读数都是旧的。

这里要重点说一个被滥用的命令：bcdedit /set hypervisorlaunchtype off。很多教程把它当成“关闭 VBS 的终极手段”，但它关掉的是整个虚拟机监控程序的启动。后果是 VBS 确实不运行了，同时 WSL2、Windows 沙盒、以及所有依赖 Hyper-V 的东西一起停摆。如果你只是想让msinfo32那一行变成“未启用”，用上面的注册表方案就够了，没必要动引导配置。真要动，改回来也简单，把off换成auto再重启即可，但中间这段时间你的虚拟化相关功能是瘫的。

3.3 多系统与离线环境的处理：DISM 挂载的正确姿势

如果你是在做系统镜像定制、批量部署，或者机器上有多套系统需要统一处理，在线改注册表就不合适了，得用 DISM 挂载映像离线修改。

基本流程是先查看映像信息，确认要改的索引，然后挂载：

dism /Get-WimInfo /WimFile:D:\sources\install.wim dism /Mount-Wim /WimFile:D:\sources\install.wim /Index:1 /MountDir:C:\Mount

挂载成功后，用reg load把离线系统的注册表配置单元加载进来：

reg load HKLM\OFFLINE C:\Mount\Windows\System32\config\SYSTEM reg add "HKLM\OFFLINE\ControlSet001\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f reg unload HKLM\OFFLINE

这里有个坑：离线系统里的键路径是ControlSet001而不是CurrentControlSet，因为CurrentControlSet是个运行时链接。写错路径的话命令会“成功”，但实际什么都没改。改完记得先reg unload卸载配置单元，再dism /Unmount-Wim /MountDir:C:\Mount /Commit提交，顺序反了会报占用。

如果是已经部署好的多系统机器（比如双系统），想改另一个系统的设置，思路一样，挂载那个系统的分区，加载它的 SYSTEM 配置单元，改完卸载。但要注意那个系统如果开了快速启动，注册表可能处于休眠状态的锁定中，得先在那个系统里完全关机（不是睡眠、不是快速启动），再操作。

4. 改完怎么确认：读数的方法和每种读数的含义

4.1 msinfo32 的几行字，含义差别很大

Win + R输入msinfo32，在“系统摘要”里找这几行。常见的显示有这么几种：

• 正在运行：VBS 底座和至少一项安全服务都在跑。这是出厂默认状态。
• 正在运行，但未启用所有安全属性：底座还在，但某些服务（通常是 HVCI）被关了。这时候如果你在 BIOS 里把虚拟化关掉，它会变成未启用，但代价是别的虚拟化功能一起没了。
• 未启用：底座没起来，这是我们要的结果。通常意味着 VBS 主开关被关，或者 CPU 虚拟化在固件层被禁用。

除此之外，同一页面往下翻还能看到“已检测到虚拟机监控程序”之类的条目。这个条目和 VBS 状态是相关的，但不等价：有些第三方虚拟化软件运行时会占用这块，导致它显示“是”。所以别只盯着这一行下结论，要结合起来看。

4.2 用 PowerShell 读准确数值，比看文字描述靠谱

想看精确状态，用这条命令：

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

返回的三个字段里，VirtualizationBasedSecurityStatus是最关键的：

另外两个字段SecurityServicesConfigured和SecurityServicesRunning是数组，里面每个数字代表一项服务：

比较典型的对比是这样的：关闭前VirtualizationBasedSecurityStatus是 2，SecurityServicesRunning里能看到 2（甚至 1、2 都有）；关闭 HVCI 之后，如果 VBS 底座还在，状态可能仍是 2，但SecurityServicesRunning里的 2 消失了。如果你把主开关也关了，重启后状态才会变成 0。这就是为什么我一直强调要先明确目标再操作，否则你看到的数值变化会让你误判。

4.3 双向核对，避免被缓存骗了

有一点必须提醒：这三个字段在某些系统上存在刷新延迟，尤其是刚重启完立刻查询，偶尔会读到旧值。我的习惯是重启后等两三分钟再查，并且用两条不同路径交叉验证——一条是 PowerShell 的 CIM 查询，另一条是注册表：

reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled

如果注册表显示 0，但 CIM 里状态还是 2，那多半是某项服务被策略强制拉起，或者Locked值还锁着。这种情况就得回到第 5 节去排查了。另外systeminfo命令的最后几行也会列出 Hyper-V 的各项要求是否满足，如果那几行显示“已检测到虚拟机监控程序”，说明底层还跑着东西，和 VBS 状态互相印证着看更准。

5. 关了又自己“复活”的排查实录

5.1 最常见的几个元凶

这是被问得最多的问题：明明关了，重启一看又变成“正在运行”。按我的排查经验，概率从高到低大概是这几个：

第一，Locked没复位。内存完整性的 UEFI 锁定是独立于普通注册表开关的。如果你之前是通过策略批量开启过，或者 OEM 出厂就用策略锁了，那Locked会是 1。这时候你得先关闭它的策略来源（组策略或本地策略），重启让Locked变成 0，注册表才改得动。直接硬改注册表是无效的，改完了系统还会按锁定值恢复回去。

第二，组策略优先级压过注册表。域环境里这条最常见，本地改了，登录后域策略一刷新，全被打回。排查方法是gpresult /h C:\gp.html导出结果，搜索 Device Guard 相关的条目，看看到底是哪条策略在起作用，以及它的来源是本地还是域。找到源头去改，比在终端反复折腾有效得多。

第三，OEM 预装的管理工具。一些品牌的整机自带系统管理软件，会在启动时把安全配置恢复成出厂状态，其中就包括 VBS 相关项。这种最隐蔽，因为你在系统设置里找不到任何痕迹。判断方法是干净启动（msconfig里禁用所有非微软服务）后观察是否还会恢复，如果干净启动下不恢复，那就是某个第三方服务干的，逐个启用来定位。

第四，Windows 更新后的重置。大版本更新（比如从 21H2 升到更高版本）有时候会把安全默认值重新应用一遍。这个没法完全避免，只能更新后复查一次。热词里提到的那些版本号，其实反映的就是大家对不同版本行为差异的困惑——同样一个开关，在不同版本上的默认策略和恢复行为确实可能不一样，别拿老教程直接套新系统。

5.2 排查顺序表

遇到反复复活，按这个顺序走，能少走弯路：

第 6 条听起来很蠢，但我确实踩过。多系统或者经历过异常关机的机器上，注册表里可能同时存在ControlSet001和ControlSet002，CurrentControlSet指向哪个是动态决定的。如果你改的是非活动的那个，重启后系统切到另一个，你的修改自然就“消失”了。确认方法是查HKLM\SYSTEM\Select下的Current值，它告诉你当前用的是哪个 ControlSet。

5.3 一个容易被忽略的细节

还有一类情况是“看着复活，其实没复活”。有些安全软件或者硬件检测工具，会读缓存里的旧状态来显示，导致界面上一直是“正在运行”。这时候以 PowerShell 的 CIM 查询结果为准，别信第三方工具的面板。我自己就遇到过一个外设管理软件，界面一直显示内存完整性开着，实际上早就关了，白白多折腾了半小时。

实操心得：每次改完这类底层安全配置，我的固定动作是——重启、等三分钟、跑一遍 CIM 查询、再跑一遍bcdedit /enum {current}看引导项有没有被动过。四步下来基本能确认状态，省得后面反复怀疑。

6. 和这件事经常一起出现的几个坑

6.1 WSL2 报“未启用虚拟化”，和 VBS 不是一回事

这是热词里出现频率很高的一条，值得单独说清楚。WSL2 报“因为此计算机上未启用虚拟化”，原因是虚拟机平台或底层虚拟化能力不可用，跟 VBS 开没开是两码事。具体分几种情况：

如果 BIOS 里 VT-x / SVM 被关了，那 WSL2、第三方虚拟机、VBS 一起报废，这是最彻底的，得进固件打开。

如果是“虚拟机平台”这个可选功能没勾上，那 WSL2 起不来，但 VBS 可能照样运行，因为 VBS 依赖的是更底层的虚拟化扩展，不完全依赖那个可选功能包。

还有一种情况是bcdedit里hypervisorlaunchtype被设成了off——这通常是为了关 VBS 而顺手改的，结果把 WSL2 也一起干掉了。改回来：

bcdedit /set hypervisorlaunchtype auto

然后重启。这个命令和 3.2 节里说的对应关系要记住：关 VBS 用注册表，别动引导项。动引导项是杀敌一千自损八百的做法。

顺便说一句，如果你既想关 VBS 又想保 WSL2，注册表方案是可行的，因为 WSL2 走的是虚拟机平台那条路，和 VBS 的底层环境可以共存，只要别把“虚拟机平台”这个功能勾掉就行。这个组合我在好几台机器上验证过，是能跑通的。

6.2 第三方虚拟机和 Hyper-V 的共处问题

用 VMware 或 VirtualBox 做实验环境的人，经常遇到性能骤降或启动报错。根因是 Hyper-V 一旦启用，就会占据 CPU 的虚拟化根模式，第三方虚拟机只能退到兼容模式运行，效率自然打折。这时候关掉 VBS 通常能让情况好转，但如果机器上还开着“虚拟机平台”功能，冲突依然存在。真正想彻底让第三方虚拟机跑满性能，得把 Hyper-V、虚拟机监控程序平台、虚拟机平台这几个功能全部取消勾选，代价就是 WSL2 和沙盒一起不能用。

这就是一个典型的取舍问题，没有两全方案。我的建议是按主力用途定：日常开发用 WSL2 多，就留着；主要用第三方虚拟机做渗透测试或系统实验，就关掉全家桶。别在两者之间反复横跳，每次切换都要重启，时间成本划不来。

6.3 几个常见误区

顺带澄清几个经常被混淆的说法：

“关掉防火墙能提升性能”——这是另一个话题，而且防火墙对性能的影响在现代硬件上基本可以忽略，关掉它换来的是实打实的暴露风险，不划算。

“Windows 11 家庭版没法治”——恰恰相反，家庭版因为没有组策略编辑器，反而少了一条策略来源，用注册表改往往更直接。真正的麻烦在域环境，不在家庭版。

“关了 VBS 就一定能装老驱动”——不一定。驱动装不上还可能是因为驱动的签名证书过期、或者被易受攻击驱动列表单独拦截，VBS 只是其中一环。遇到这类问题，先看具体报错代码，别急着归因到 VBS 上。

最后说我个人的做法：生产主力机上我留着内存完整性，只在一台专门用来跑老游戏和做兼容性测试的机器上关掉，而且关之前导出过注册表备份、做过一次完整系统镜像。这样即使后面想恢复，reg import一下、或者直接还原镜像就行，不用重新摸一遍路。折腾系统底层设置这件事，留条后路比省那点时间重要得多。