故小里先交代一下背景：我是在Win11上装eNSP做HCIP实验的。拓扑里就一台AR1路由器、一台交换机、两台PC，结果双击AR1，eNSP直接弹出一个英文报错框：启动设备AR1失败，错误代码40。第一次遇到这问题的时候，我第一反应是VirtualBox没装好，于是卸载重装VirtualBox，重装eNSP，甚至把老电脑里的Win10系统镜像都翻出来准备重装系统，折腾了一晚上。第二天恢复理智，查了系统信息和VBS状态才反应过来——根本不是eNSP的问题，是Win11的默认安全策略把事情搞复杂了。
这篇文章就把这个问题的完整解决思路写清楚：Win11下eNSP启动AR1报错40，为什么和VBS有关、怎么判断VBS是不是罪魁祸首、如何正确关闭VBS，以及关完之后还不行的话该往哪个方向排查。适合被eNSP折磨的网工、备考HCIA/HCIP的实验党、还有刚换Win11电脑准备做模拟实验的朋友，照着做基本能少走弯路。
1. 先还原现场：AR1报错40到底是个什么现象
1.1 eNSP的设备究竟是什么
很多人一上来就找“错误代码40是啥意思”，但我觉得先搞清楚eNSP的工作原理更重要。
eNSP里的AR1，不是像记事本一样双击就打开一个程序的，它是一个虚拟机。eNSP设备仓库里存放着华为官方做好的设备镜像，AR1路由器通常对应一个虚拟磁盘文件，启动时由eNSP调用VirtualBox把镜像加载起来，然后你才能在拓扑图上看到设备状态从白色变成绿色。
这里有个关键点：eNSP本身不负责虚拟化，它是通过VirtualBox来干活的。所以eNSP的报错，很多时候不是eNSP自己出错，而是底层VirtualBox启动虚拟机失败后把失败结果回传给了eNSP。错误代码40在多数情况下，对应的就是“VirtualBox无法正常打开这个虚拟设备”。我在好几个案例里看到的都是这个情况。
也就是说，AR1报40，别急着怀疑华为镜像坏了，先怀疑你的虚拟化环境出了岔子。Win11和Win10最大的差异之一，就是Win11把VBS这类安全机制默认打开了，而VirtualBox的老版本在VBS面前经常趴窝。
1.2 报错40的典型表现与常见原因对照
报错40的现场，不同人遇到的不太一样，我把常见的表现整理成了下面这个表，方便你对照自己的情况。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 双击设备后1-2秒立即报40 | VirtualBox版本不对或服务异常 | 先看VirtualBox能否单独启动其他虚拟机 |
| 设备图标转了几圈才报40 | 虚拟化资源被系统占用的可能性大 | 查VBS状态、Hyper-V是否启用 |
| 只要AR1报40，交换机正常 | AR1镜像文件损坏或路径不对 | 去devices目录看镜像是否存在 |
| 关掉VBS后仍然报40 | 可能是Hyper-V残留或CPU虚拟化开关被关 | 查Windows功能列表和BIOS设置 |
这个对照表不是绝对精确，但能给你一个大方向。我个人经验里，九成以上的“AR1单独报40”都和系统虚拟化堆栈有关，其中VBS是Win11上最容易被忽略的坎。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 根因分析：VBS为什么成了eNSP的“死对头”
2.1 VBS到底是什么，Win11为什么默认开
先理解一下VBS。VBS全称是Virtualization-Based Security，基于虚拟化的安全。它的思路是：借用CPU的虚拟化能力，在系统里单独划出一块隔离的内存区域，用来守护一些高价值的安全数据，比如凭据、内核代码完整性校验等。
Win11默认开启VBS，不是因为微软闲着没事干，而是为了让内核隔离、内存完整性等功能开箱即用。内存完整性（也叫HVCI，Hypervisor强制执行的代码完整性）就是靠VBS构建的隔离环境来校验驱动和内核模块有没有被篡改。听起来很安全，但对跑虚拟机的软件来说，这就是灾难。
原因在于：VBS要跑起来，底层必须有一个hypervisor（虚拟机监控程序），Windows的hypervisor就是Hyper-V那一套。哪怕你在“启用或关闭Windows功能”里根本没勾选Hyper-V，VBS也会把它需要的hypervisor加载到系统里。一旦Windows的hypervisor在运行，它就接管了CPU的硬件虚拟化能力，比如Intel的VT-x或AMD的SVM。
2.2 VBS与VirtualBox的内在冲突
VirtualBox这类虚拟机软件，它的工作方式是自己直接接管CPU的虚拟化指令。老版本的VirtualBox，尤其是5.x和6.0版本，设计上默认假设“整个系统只有我一个hypervisor”，它不会主动去和Windows的Hyper-V hypervisor协商共享VT-x。
所以当VBS把Windows hypervisor拉起来之后，VirtualBox再去要虚拟化资源，要么拿不到，要么只能在极低效的模式下运行。更直接的表现就是：虚拟机启动失败，eNSP收到错误码，弹窗报40。
这里要特别提醒：eNSP官方版本自带的VirtualBox，版本通常比较老。我见过不少Win10下正常、后来升级到Win11就开始报40的机器，区别就在于Win11把VBS默认打开，而Win10默认没有打开。所以很多人以为是eNSP升级了不兼容，其实是系统的虚拟化环境变了。
2.3 判断VBS是否正在运行
在动手关闭VBS之前，必须先确认VBS是不是真的处于运行状态。有些人的机器上VBS是“已启用但未运行”，这时候eNSP可能不受影响；有些人是“正在运行”，那就是核心原因。
判断方法非常简单：按Win+R，输入msinfo32，回车，打开系统信息。在“系统摘要”里往下找“基于虚拟化的安全”这一项。
| 状态显示 | 含义 |
|---|---|
| 未启用 | VBS没开，报40的原因不在这 |
| 已启用但未运行 | VBS策略存在但hypervisor没加载，暂时不影响，但可能某次更新后突然生效 |
| 正在运行 | VBS完全激活，VirtualBox很容易被卡死 |
| 已启用（存在固件中的虚拟机监控程序支持） | VBS依赖固件虚拟化，但还没完全运行，同样需要处理 |
如果显示“正在运行”，那这篇文章的后面部分就是你要的。如果显示“未启用”，先别急着关VBS，跳到第4章继续排查别的位置。
3. 动手关闭VBS：三套方法按需取
3.1 动手前先确认VBS确实在运行
在关VBS之前，我建议你先用systeminfo命令再看一眼，防止msinfo32在某些精简版系统上显示不全。以管理员身份打开PowerShell或命令提示符，输入：
bash复制systeminfo | findstr /i "虚拟化"
输出里通常会有“Hyper-V 要求”或者“虚拟化”相关字样。如果看到“检测到虚拟机监控程序。将不显示Hyper-V 所需的功能”，那说明Windows hypervisor已经在运行。如果看到“已在固件中启用虚拟化”之类的信息，说明CPU虚拟化是打开的，但hypervisor未必在跑。
记录一下当前状态，然后开始操作。无论是用图形界面还是命令行，关闭VBS之后都需要重启才能生效，先把没保存的实验清掉，别开着拓扑就重启，不然还要重敲一遍配置。
3.2 方法一：Windows安全中心关闭内存完整性
最简单的方法，就是通过Windows安全中心关闭“内存完整性”。路径如下：
打开“设置”，进入“隐私和安全性”，再进“Windows 安全中心”，点击“设备安全性”。在“内核隔离”区域，点击“内核隔离详细信息”，把“内存完整性”开关关掉。
这个开关控制的就是HVCI，也就是内核隔离的核心功能。关掉之后，Windows会提示你重启，重启以后VBS通常会被大幅降级，hypervisor也不一定会继续加载。这个方法最快，但对某些版本的系统来说，只关内存完整性不一定能彻底关闭VBS，因为Device Guard和Credential Guard可能还依赖VBS。所以如果重启完发现msinfo32里仍显示“正在运行”，就要用下面两个方法。
3.3 方法二：组策略禁用基于虚拟化的安全
如果你的系统是专业版、企业版或教育版，可以用组策略来彻底关掉VBS。
按Win+R输入gpedit.msc，回车，打开本地组策略编辑器。定位到：
“计算机配置 -> 管理模板 -> 系统 -> Device Guard”
右侧有一项叫“打开基于虚拟化的安全性”。双击打开，把它设为“已禁用”，确定。这里注意不要选“未配置”，未配置不等于关闭，系统可能仍然默认开启VBS。
然后到“计算机配置 -> 管理模板 -> 系统 -> Device Guard -> 基于虚拟化的安全”子节点下，把“已配置为将基于虚拟化的安全设置为在 BIOS 锁定时受到保护”这类策略也禁用掉。不同Win11版本的策略项名称略有差异，你看到的可能是“允许基于虚拟化的安全平台安全功能”或者别的，统统一律设为“已禁用”。
改完组策略之后，还不够，因为hypervisor是否加载，不由组策略单独决定，还要看启动配置项。继续看方法三。
3.4 方法三：命令行彻底关掉hypervisorlaunchtype
这个方法才是真正的核心。以管理员身份打开PowerShell或命令提示符，输入：
bash复制bcdedit /set hypervisorlaunchtype off
正常情况下会提示“操作成功完成”。这条命令的作用是把Windows hypervisor的启动类型设置为关闭，也就是系统下次启动不再加载Hyper-V的hypervisor。这个命令的效果比重装VirtualBox还直接，因为不管VBS策略存不存在，hypervisor不加载，VirtualBox就能正常接管VT-x了。
执行完这条命令后建议再补两条注册表命令，把VBS相关的策略彻底关掉：
bash复制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
第一条把VBS总开关置为0，第二条把HVCI场景开关置为0。这两条命令在部分企业版系统上可能会提示“系统策略禁止此操作”，那说明你的电脑是公司统一管理的，不能擅自关闭，这种情况下你要去找网管申请白名单，而不是硬改。
改完重启系统。重启后再次打开msinfo32，查看“基于虚拟化的安全”，如果显示“未启用”，说明VBS已经彻底关闭了。这时候再启动eNSP，双击AR1，正常情况下一分钟左右设备就能变绿。
3.5 验证AR1能否正常点亮
设备点亮之后，进去看版本信息或者直接敲display version验证一下。如果AR1能正常进命令行，说明VBS这条路已经趟平了。如果仍然报40，别急着崩溃，多半是还有别的虚拟化组件在捣乱，进入第4章继续排。
4. 关了VBS还是40？继续排查的7个位置
4.1 VirtualBox版本匹配检查
eNSP对VirtualBox的版本非常敏感。官方配套的VirtualBox一般是特定版本，你手动装一个最新版VirtualBox，反而可能不被eNSP识别。
我见过最多的坑是：用户装了eNSP之后，VirtualBox提示升级，用户手一抖点了升级，结果eNSP里所有设备全部报错。VirtualBox 6.0之后对Hyper-V的兼容策略变化很大，有时候升级到6.1或7.0，在打补丁的机器上能跑，但换一台机器就崩。
正确的做法是：打开eNSP安装目录下的doc或帮助文档，确认它要求的VirtualBox版本。如果发现版本不匹配，卸载VirtualBox，安装eNSP配套版本。卸载VirtualBox时记得保留虚拟机镜像，尤其是C:\Users\用户名\VirtualBox VMs目录下的eNSP设备文件，不然重装后全部设备都要重新导入，那才叫崩溃。
4.2 BIOS里CPU虚拟化开关检查
VBS关了，hypervisor也关了，但CPU虚拟化如果本来就是关闭状态，VirtualBox照样起不来。这个其实是最底层的开关。
不同品牌电脑的BIOS位置不一样，但关键词是固定的。Intel平台找“Intel Virtualization Technology”或者“VT-x”，AMD平台找“SVM Mode”。这两项必须设置为Enabled，否则虚拟机一律起不来。Win10时代也有很多报错40的案例，最后发现是BIOS里VT-x没开，跟Win11没关系。
怎么快速判断CPU虚拟化是否开启？打开任务管理器，切到“性能”页，点“CPU”，右下角可以看到“虚拟化：已启用”。如果显示“已启用”，说明BIOS层面没问题。如果显示“未启用”，那就是BIOS设置问题，跟VBS无关了。
4.3 残留的Hyper-V家底
这是一个非常容易踩的坑。有些人以前装过Docker Desktop，或者用过Windows Sandbox，后来又卸载了，表面上看Hyper-V功能已经没了，但Windows hypervisor的启动项可能还残留着。
处理方法：打开“启用或关闭Windows功能”，把下面这些条目全部取消勾选：
- Hyper-V
- 虚拟机监控程序平台
- Windows 虚拟机监控程序平台
- Windows 沙盒
- 适用于Linux的Windows子系统
注意“适用于Linux的Windows子系统”也会依赖Hyper-V，如果你平时用WSL，关掉之后WSL就用不了了。我自己的建议是：专门做eNSP实验的电脑，尽量别同时用WSL2，两者的虚拟化需求在Win11下很难共存。
修改完Windows功能之后重启，再用bcdedit查看一下：
bash复制bcdedit /enum | findstr hypervisorlaunchtype
如果看到的还是Auto或More，再用一次bcdedit /set hypervisorlaunchtype off，然后再重启。
4.4 eNSP安装姿势与文件权限
VBS和Hyper-V都排完了，接下来要怀疑的是eNSP本身的安装完整性。很多人的eNSP是从网盘下载的绿色解压版，或者安装时没以管理员身份运行，这在Win11下很致命，因为Win11对Program Files目录的写入权限控制比Win10严格得多。
正确操作：右键eNSP安装包，选择“以管理员身份运行”。安装路径尽量默认，不要装到中文路径或者带空格的目录。安装过程中如果杀毒软件弹出拦截提示，要允许eNSP和VirtualBox的相关进程运行，尤其是vboxsvc和VirtualBox.exe，被拦截的话AR1导入虚拟机时很容易失败。
另外检查一下eNSP设备镜像目录，默认在安装目录的devices\AR下面，看看有没有AR1相关的镜像文件，以及文件大小是不是正常。有时候电脑空间不足，镜像文件没写全，也会导致启动失败。
4.5 其他设备完整性问题速查
AR1能起来了，不代表eNSP里所有设备都能起来。我把后续可能遇到的问题也放进排查表，方便你对号入座。
| 问题 | 现象 | 快速处理 |
|---|---|---|
| 交换机启动失败 | 设备一直在“###”状态 | 检查内存是否充足，降低同时启动设备数 |
| USG6000V启动卡在井号 | 防火墙设备一直初始化 | 多数是内存不足，给防火墙分配更多内存 |
| 路由器启动后接口全down | 拓扑连线不生效 | 重启云设备和路由器，刷新设备状态 |
| AR镜像被安全软件隔离 | 设备直接报镜像不存在 | 在杀毒软件里恢复被隔离文件，加白名单 |
| 启动后CPU占用率极高 | 整机卡顿，设备启动极慢 | 关掉Win11后台动画，关闭Defender实时保护或拖慢的监控项 |
4.6 清理旧的设备缓存文件
还有一个容易被忽略的点：eNSP会在用户目录下生成设备缓存。如果你反复尝试启动失败，某些临时文件可能已经写坏了。
清理方法很简单：完全退出eNSP和VirtualBox，然后删除C:\Users\用户名\.eNSP目录里除配置文件之外的历史记录，或者直接重命名这个目录让eNSP重新生成。我不建议手动删整个目录，因为里面可能保存了你的实验记录和自定义的设备配置。如果你不介意清空重来，那倒是可以整个删掉。
清理完重启eNSP，重新创建一个空白拓扑，只添加一台AR1，再次尝试启动。这一步能排除掉eNSP软件内部缓存损坏的问题。
4.7 检查Windows更新带来的反向干扰
Win11的月度安全更新偶尔会重新启用一些没被彻底关闭的安全功能。我就遇到过一次：关完VBS，eNSP好了一个星期，某天Windows自动更新之后又报40了。一查，发现组策略里Device Guard又变成了“未配置”，hypervisorlaunchtype自动回到了Auto。
对付这种反复，我建议把第3章里用到的命令固化成一个检查习惯：每次系统更新完之后，跑一次msinfo32看VBS状态，如果又被拉起来，就直接再执行一次bcdedit /set hypervisorlaunchtype off。
5. 我的实操心得与后续建议
5.1 关闭VBS会不会让系统变弱
很多人在关VBS之前会问我：这玩意儿关了会不会被病毒打出屎？从实际角度说，关闭VBS确实会让内核隔离和内存完整性不再生效，Windows面对驱动级恶意代码时的防御会弱一些。但如果你这台电脑就是拿来跑模拟器、做实验的，不装乱七八糟的软件，不挂着网盘下载来的破解工具，风险完全是可控的。
真正要注意的是：不要为了关闭VBS去网上下载那些所谓的“一键优化脚本”，尤其是某些以.vbs文件形式传播的脚本。我看到很多人在论坛里问“pycharm激活.vbs没有权限运行怎么办”，这类脚本本身就带敏感操作，Win11阻止它运行，恰恰是安全机制在起作用。宁可手动改设置，也别去手动调脚本权限绕过系统拦截。
5.2 实验环境要“轻装上阵”
这个算是我多年踩坑踩出来的原则。跑eNSP的电脑，内存最好在16GB以上，启动设备时尽量不要把拓扑里所有设备全选后一次性启动。AR1路由器默认可能只分配256MB内存，遇到大型实验，比如要跑BGP路由控制或OSPF多区域互访，设备数量一多，内存不够就会报一堆莫名其妙的错。
另外，VirtualBox的全局设置里，把“加速”选项卡下的“启用VT-x/AMD-V”和“嵌套分页”都勾上，能明显提升AR1的启动速度和稳定性。这些选项在VirtualBox的主界面里，菜单路径是“管理 -> 全局设定 -> 常规 -> 默认虚拟机文件夹”，加速选项则在新版本里通常在“设置 -> 系统 -> 加速”里。
5.3 遇到别急着重装系统
Win11重装系统这个操作，很多时候解决不了eNSP报40的问题。因为报错的根源是虚拟化堆栈，不是系统文件丢失。我见过群里有人重装了三次系统，每次装完都信心满满，结果装好eNSP一启动AR1，还是40。后来我让他跑了bcdedit /enum一看，hypervisorlaunchtype还是Auto，等于重装了白装。
所以正确的顺序是先诊断，后处理。诊断三步走：先看msinfo32里VBS状态，再看Windows功能里有没有Hyper-V残留，最后查bcdedit的启动项。这三步只要两步有异常，果断按第3章的方法关掉重启，基本能搞定。
我个人在实际操作中的体会是：Win11和eNSP这对组合，只要解决了虚拟化资源抢占的问题，剩下的问题都好说。以这个“无脑重装系统”的方式处理，既浪费时间，也不一定能找到真正的病根。希望这篇记录能帮同样被AR1报错40挡在实验门外的人，省下一个晚上。