简介：这份资源面向需要安装并稳定运行 CAD 与南方测绘 CASS11 的专业技术人员及地理信息从业者，聚焦解决首次启动时弹出的“请不要在虚拟机中运行此程序”警告。内容按排查思路整理出五条路径：卸载虚拟机软件、关闭 Windows「内存完整性」内核隔离、取消相关 Windows 功能、用管理员命令关闭 hypervisor 启动项，以及在 BIOS 中禁用虚拟化技术，并提示先装 CAD、破解需借用 CASS10 的机器码工具等前置要点。压缩包仅 1.87MB，内含 1 个 pdf 文档，以图文步骤与命令代码为主，可直接对照操作；作者也提醒修改系统设置前备份数据，不同主板与系统版本需灵活调整。目前已有 4558 人学习，适合遭遇兼容性提示、希望少走弯路并补全排错思路的初中级用户参考。
1. 报错不是电脑坏了：CASS11 那句「请不要在虚拟机中运行」到底在读什么
装完 CAD2016，再装 CASS11，双击桌面图标，屏幕上只有一句话：请不要在虚拟机中运行此程序。不少人的第一反应是去查自己是不是开了远程桌面，其实跟这个没关系。CASS11 这类带加密授权的测绘成图软件，启动瞬间会执行一条 CPUID 指令，读 ECX 寄存器的第 31 位——这一位叫 hypervisor present bit，只要当前系统跑在任意 hypervisor 之上，它就置 1。麻烦在于，Windows 10 之后默认启用的内存完整性、内核隔离、Hyper-V，全都会让这一位置 1，实体机因此被误判成虚拟机，CAD 和 CASS 的安装本身没有任何问题。这篇笔记把安装顺序、五种关闭检测手法、机器码工具的版本坑，以及我自己翻车过的几个点按顺序拆开，做地理信息系统和测绘成图的同行照着走，大概率一次跑通。
2. 装对顺序比装对版本更重要：CAD 与 CASS11 的依赖链怎么理
很多人把精力全花在找「哪个版本的 CASS11 能装」，忽略了更前置的问题：CASS 从来不是独立程序，它是长在 AutoCAD 进程里的一层壳。顺序装反、或者 CAD 装完没初始化就直接上 CASS，后面会遇到一堆看起来像授权问题的怪现象。
2.1 CASS11 为什么必须长在 CAD 上
CASS 的运行时结构大致是三块：一块 ARX 模块，由 acad.exe 在启动时加载；一套菜单和工具栏定义文件，注册到 CAD 的 CUIx 体系里；一堆符号库、样板图、编码表，放在 Support 搜索路径下。这三块没有一块是独立跑的，全部依附于宿主 CAD 的进程环境和注册表配置。
所以安装程序在写入文件之前，做的第一件事是去注册表里找 AutoCAD 的产品分支，确认宿主存在、版本在白名单里，然后才决定往哪个目录铺文件、往哪个 Support 路径注册。这一步如果找不到宿主，安装程序往往不会硬报错，而是写一个空路径或者默认路径进去，装完看着是成功的，一启动就各种找不到模块。
提示：CAD 装完不要急着装 CASS，先手动启动一次 CAD，让它把 HKCU 下的用户配置目录、%APPDATA%\Autodesk 下的漫游文件全部生成出来。CASS 的安装程序要读这些配置，缺了就得靠猜。
这套依赖关系决定了一件事：CAD 装错版本或者装残了，CASS 装十遍也没用。所以预检要放在动手之前，而不是报错之后。
2.2 装机前的环境预检
预检这一步我一般会跑一个脚本，把后面可能踩坑的五个指标一次性打出来，省得来回翻设置面板。下表是我习惯检查的项，对应的判定标准也一并列了。
| 检查项 | 判定标准 | 不满足时的后果 |
|---|---|---|
| 系统版本与内部版本号 | Win10 1809 及以上 / Win11 | 老版本缺 API，CAD 装不上 |
| .NET Framework | 4.5 及以上 | CAD2016 安装程序直接退出 |
| HypervisorPresent | 期望 False | True 就会触发虚拟机检测 |
| 内存完整性 HVCI | 期望 0（关闭） | 开启时 CPUID 的 hypervisor 位为 1 |
| 第三方虚拟机驱动 | 无 vmx86 / VBoxDrv 等服务 | 同样会被识别成虚拟环境 |
对应的 PowerShell 预检脚本如下，普通权限即可跑，只有第 4 项读功能列表时建议用管理员窗口。
# 装机前一次性打印 5 个关键环境指标，管理员权限运行更稳妥 # 1. 系统版本与内部版本号，用于判断 CAD2016 是否受支持 Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber # 2. 当前是否运行在 hypervisor 之上；True 就会被 CASS11 判定为虚拟机 (Get-CimInstance Win32_ComputerSystem).HypervisorPresent # 3. 内存完整性（HVCI）开关，0 或读不到都算关闭，1 表示已开启 Get-ItemProperty ` "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" ` -Name Enabled -ErrorAction SilentlyContinue # 4. Hyper-V、虚拟机平台、虚拟机监控程序平台三个功能的状态 Get-WindowsOptionalFeature -Online ` -FeatureName Microsoft-Hyper-V-All, VirtualMachinePlatform, HypervisorPlatform | Select-Object FeatureName, State # 5. 是否残留第三方虚拟机驱动服务 Get-Service | Where-Object { $_.Name -match 'vmx86|VBoxSDS|VBoxDrv|vmware' } | Select-Object Name, Status脚本里第 2 行是最关键的判据，HypervisorPresent读的是Win32_ComputerSystem的对应属性，值直接来自系统对 CPUID 的解释结果，跟你装没装 VMware 是两回事。第 3 行读的注册表键在部分精简版系统上可能不存在，读不到时-ErrorAction SilentlyContinue会静默跳过，此时按「已关闭」处理即可。第 4 行的三个功能名要写全，Microsoft-Hyper-V-All是总包，后两个是独立组件，只关总包有时会漏掉虚拟机监控程序平台。
跑完之后如果第 2 项是 True，不要急着装 CASS，先去第 3 章处理掉，否则装完必然弹窗。
2.3 装完 CAD 之后的三件确认动作
CAD 装完到 CASS 开装之间，有三件事值得花两分钟确认。这三件事不出问题，后面九成的「装完打不开」都能提前规避。
# 装完 CAD2016、装 CASS11 之前的三项确认 # 1. 主程序是否存在，版本号是否落在 20.1.x（2016 对应的注册表分支是 R20.1） $acadExe = "C:\Program Files\Autodesk\AutoCAD 2016\acad.exe" (Get-Item $acadExe).VersionInfo.ProductVersion # 2. 注册表里是否已写入 CAD 的产品分支，CASS 安装程序靠它定位宿主 Get-ChildItem "HKLM:\SOFTWARE\Autodesk\AutoCAD" | ForEach-Object { $_.PSChildName } # 3. 用户配置目录与 Support 搜索路径是否已生成（需先手动启动过一次 CAD） Test-Path "$env:APPDATA\Autodesk\AutoCAD 2016\R20.1\chs\Support"第 1 项的返回值形如20.1.x，只要主版本号是 20.1 就说明 CAD2016 装的是正身，不是被替换过的精简版。第 2 项正常会列出R20.1这样的分支名，如果输出为空，说明 CAD 的安装信息没写进 HKLM，CASS 安装程序会找不到宿主。第 3 项的chs是简体中文语言代码，装的是英文版 CAD 就换成enu；这一项返回 False，八成是 CAD 装完没启动过，手动开一次再退出就好。
注意：三项里任何一项不对，都不要继续装 CASS11。先修 CAD，再回来。反过来做的结果就是装完发现菜单加载不出来，还要整个卸载重来，时间全浪费在等待卸载进度条上。
顺序理顺之后，真正的硬骨头才浮出来：即使装得再干净，只要系统里 hypervisor 那位标志位还在，CASS11 照样弹窗。下一章把这五种手法的优先级和副作用讲清楚。
3. 五种关掉虚拟化检测的手法：从内存完整性到 BIOS 的优先级排序
网上的解决方案通常一上来就让人进 BIOS 关虚拟化，这是副作用最大、最难回头的一招。合理的顺序应该按「副作用从小到大」排：先动内存完整性，再动启动项，再关系统功能，最后才碰 BIOS 和第三方虚拟机软件。中间每一步都能撤回，不至于一上来就把开发环境搞崩。
3.1 CPUID 那一位：为什么五种手法都指向同一个开关
前面提到的 hypervisor present bit，本质是 CPU 的一条自我声明：我现在被某层虚拟化监控程序托管着。这条声明不区分你是在 VMware 里跑，还是在实体机上开了 Hyper-V——从 CPU 的视角看，两者没有区别，VC 层都在下面。
Windows 从 1607 版本开始默认启用基于虚拟化的安全（VBS），核心组件之一就是内存完整性 HVCI，它需要把内核放进一个轻量虚拟机里跑，于是 hypervisor 位被置 1。这就解释了为什么大量用户「什么都没装，照样弹窗」——弹窗跟用户装没装虚拟机软件无关，跟系统默认配置有关。
五种手法分别打在链路上的不同位置：内存完整性打在 VBS 的策略层，hypervisorlaunchtype打在引导加载层，Windows 功能开关打在组件安装层，BIOS 打在硬件虚拟化扩展层，卸载虚拟机软件则是清掉第三方驱动层。理解了这个分层，就知道为什么有时候关了一个不管用——你只关掉了其中一层，另一层还在把位置 1。
3.2 内存完整性：命中率最高、副作用最小的一层
Windows 安全中心里那个「内存完整性」开关，是我处理这类问题的第一选择。它关掉之后影响的只是内核代码完整性保护，日常办公、CAD 绘图、常规开发基本无感，重启一次就生效。
图形界面的路径是：打开 Windows 安全中心 → 设备安全性 → 内核隔离详细信息 → 把「内存完整性」的开关拨到关闭 → 按提示重启。这条路径在大部分机器上能走通，但如果你习惯脚本化，用命令行更省事：
:: 管理员 CMD 执行。作用等同于安全中心里的内存完整性开关 :: /v 指定值名，/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，部分系统上内存完整性关了但 VBS 还挂着 reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 0 /f :: 改完必须重启，不重启不生效，这一步没有捷径 shutdown /r /t 0第一条命令写的是 HVCI 的场景开关，Enabled置 0 后，系统在下次启动时不再加载 HVCI 策略。第二条是 VBS 的总开关，之所以一并处理，是因为某些主板固件会把 VBS 配置锁在 UEFI 变量里，图形界面上的开关看似关了，重启又被拉回来——这种情况下命令行改注册表能多争取一次机会，但也不是万能的，如果重启后又被还原，说明是固件锁，得进 BIOS 关掉「基于虚拟化的安全性」相关项。第三条shutdown /r /t 0就是立即重启，/t 0是零秒延迟，别在没存盘的时候跑。
提示：改完重启后跑一次
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent，返回 False 才算这一层真的关掉了。返回 True 就别往下走，先解决这一层。
3.3 hypervisorlaunchtype 与「启用或关闭 Windows 功能」里的三个勾
内存完整性关掉还弹窗的情况我遇到过几次，多数是系统里还留着完整版的 Hyper-V。这时动的是引导加载配置，让 Windows 在启动时压根不加载 hypervisor。
:: 管理员 CMD 执行。关闭引导阶段的 hypervisor 加载 bcdedit /set hypervisorlaunchtype off :: 需要恢复时（比如要重新用 WSL2 或容器）改回来 :: bcdedit /set hypervisorlaunchtype auto :: 查看当前设置，确认是否已写入 bcdedit /enum "{current}" | findstr /i hypervisorlaunchtypebcdedit改的是启动配置数据库，/set后面跟的是配置项名，off表示引导阶段不加载。这条命令的副作用比内存完整性大得多：关掉之后 WSL2、Docker Desktop、Windows 沙盒、部分安卓模拟器全部起不来，因为它们都依赖 hypervisor。所以我在改之前会先把当前值记下来，出问题能立刻回滚。
图形界面那条路走的是组件卸载，路径是控制面板 → 程序和功能 → 启用或关闭 Windows 功能，需要取消勾选的三项是：Hyper-V、虚拟机平台、Windows 虚拟机监控程序平台。三项要全取消，只取消 Hyper-V 是常见误操作——虚拟机监控程序平台是独立组件，Hyper-V 关掉它照样能把 hypervisor 位撑起来。
习惯命令行的话，用 DISM 一次处理完更干净：
:: 管理员 CMD 执行，逐个禁用三个与虚拟化相关的 Windows 功能 :: /norestart 表示先不重启，三条跑完再手动重启一次，避免中途反复重启 dism /online /disable-feature /featurename:Microsoft-Hyper-V-All /norestart dism /online /disable-feature /featurename:VirtualMachinePlatform /norestart dism /online /disable-feature /featurename:HypervisorPlatform /norestart :: 三条执行完毕后统一重启 shutdown /r /t 0/featurename后面必须写组件全名，写简称会报「功能名称未知」。/norestart的作用是抑制每条命令执行后的自动重启，不加的话第一条跑完就重启，后面两条还得等系统起来再跑，来回折腾。三条都成功之后统一重启一次即可。
3.4 BIOS 虚拟化开关与第三方虚拟机驱动
前面三层都处理完还弹窗，才轮到 BIOS。开机按 Del 或 F2 进设置，找Intel Virtualization Technology、VT-x、SVM Mode、AMD-V这类字样，通常在 Advanced 或 CPU Configuration 下面，设为 Disabled 保存退出。不同主板菜单结构差异很大，找不到就用主板型号加「VT-x 关闭」去搜，比自己翻快。
这一招的代价要说清楚：关掉硬件虚拟化扩展之后，所有依赖它的软件全部失效，包括但不限于各类模拟器、容器方案、部分安全软件的沙箱功能，而且以后想开回来还得再进一次 BIOS。所以除非前面三层都失败，我不建议动它。
第三方虚拟机软件是另一条线。装了 VMware Workstation 或 VirtualBox 的机器，即使服务没启动，驱动也静静地躺在系统里，某些检测逻辑会直接读驱动是否存在。稳妥的做法是卸载，实在不想卸载，至少把相关服务停掉并设为禁用：
# 以管理员身份运行 PowerShell # 停掉并禁用 VMware 的虚拟化驱动服务，Workstation 会因此打不开，二选一 Stop-Service -Name vmx86 -Force -ErrorAction SilentlyContinue Set-Service -Name vmx86 -StartupType Disabled -ErrorAction SilentlyContinue # VirtualBox 对应的服务名是 VBoxSDS，一并处理 Stop-Service -Name VBoxSDS -Force -ErrorAction SilentlyContinue Set-Service -Name VBoxSDS -StartupType Disabled -ErrorAction SilentlyContinue # 确认处理结果，Status 应为 Stopped，StartType 应为 Disabled Get-Service vmx86, VBoxSDS -ErrorAction SilentlyContinue | Select-Object Name, Status, StartType-ErrorAction SilentlyContinue是为了在服务不存在时不报红字，方便一条命令兼容多台机器。改完这些，如果还留着 Workstation 的图形界面，打开会提示驱动加载失败，属于正常现象，要用的时候把StartupType改回Automatic再启动服务即可。
3.5 安全中心一片空白时的补救
有一类机器的表现很迷惑：想按第 3.2 节去关内存完整性，结果 Windows 安全中心打开是一片白，什么都没有。这不是安全中心坏了，多半是SecurityHealthService这个服务被禁用了，常见于各种「系统优化」工具或精简版镜像。
补救办法是把它改回按需启动：
:: 管理员 CMD 执行。安全中心空白时，先把 SecurityHealthService 恢复成按需启动 :: Start=3 对应「手动（按需启动）」，系统需要时能把服务拉起来；4 是禁用，2 是自动 reg add "HKLM\SYSTEM\CurrentControlSet\Services\SecurityHealthService" /v "Start" /t REG_DWORD /d 3 /f :: 改完必须重启，重启后安全中心界面才会恢复正常 shutdown /r /t 0Start这个值的含义要记准：2 是自动，3 是手动（按需），4 是禁用。设 3 而不是 2，是因为安全中心本身不需要常驻，按需拉起就够，设成 2 会多占一点开机时间。改完重启，安全中心能正常打开，再回去走 3.2 节的图形界面路径关内存完整性。
4. 机器码与授权绑定：版本错配为什么会让注册码一直对不上
虚拟化检测解决之后，下一个卡点通常在授权环节。很多人在这里浪费的时间比装软件还多，因为失败现象不明显——不是报错，而是「填进去没反应」或者「提示无效」。
4.1 机器码到底是拿什么算出来的
机器码本质是一组硬件指纹的哈希。常见的取指纹字段包括主板 SMBIOS 里的 UUID、系统盘的卷序列号、网卡 MAC、CPU 型号与特性串，有的实现还会读 BIOS 日期和内存插槽信息。取完之后按固定顺序拼接、哈希、截断，得到一串人能抄下来的字符。
这就解释了两件事。第一，为什么在虚拟机里机器码会变——虚拟机的 SMBIOS UUID 是每次创建时随机生成的，网卡 MAC 也是虚拟的，指纹天然不稳定。第二，为什么换块硬盘、改个 SATA 模式、插拔网卡之后机器码也跟着变，因为参与哈希的字段被改动了。
对我们来说，实际含义是：取机器码这件事要在硬件状态稳定的时候做，取完之后到填注册码之间，别去动 BIOS 设置、别拆硬盘、别换网卡。
4.2 为什么 CASS10 目录里的工具配 CASS11 才好使
原始资料里有一条关键经验：CASS11 的授权环节需要用到「获取机器码工具.exe」，而这个工具要用 CASS10 版本里的那一份，而不是 CASS11 安装包自带的那一份。
我按这个思路复盘过，比较合理的解释是取指纹的字段集合和拼接顺序在两个版本之间做了调整。CASS11 自带的那份工具面向新系统重写了 SMBIOS 读取逻辑，在某些主板固件上取出来的字符串编码或长度跟授权端期望的不一致；而 CASS10 那一版字段更保守，只取最稳定的几项，反而对得上。这类版本错配不会给你任何提示，工具跑完照样吐一串码，只是这串码算出来的结果填进去无效。
所以操作上要形成一个固定习惯：把 CASS10 目录里的那份工具单独复制出来，放到一个纯英文路径下备用，别直接从 CASS11 安装目录里双击它。工具和它的依赖文件要放在一起，单独拎一个 exe 出来可能因为缺 DLL 起不来。
| 文件 | 来源 | 用途 | 注意事项 |
|---|---|---|---|
| 获取机器码工具.exe | CASS10 安装目录 | 生成硬件指纹字符串 | 必须与同目录依赖文件一起复制 |
| CASS11 安装包 | 主安装介质 | 装主体程序 | 装前确认 CAD 已就绪 |
| CAD2016 安装包 | 独立介质 | 宿主环境 | 先装、先启动一次 |
注意：工具所在路径不要带中文和空格。这类老工具大量使用 ANSI 路径处理，遇到中文目录会读不到自己的配置文件，表现出来的现象是双击没反应或者一闪而过。
4.3 权限、杀软与路径：三个让工具静默失败的细节
这三条是我踩过最多次的，都属于「看起来跑了，其实没跑成」的类型。
第一条是权限。读 SMBIOS 需要访问 WMI 和底层固件表，普通权限下部分字段读不到，工具会用默认值填充，算出来的码自然不对。所以「获取机器码工具.exe」一定要右键以管理员身份运行，右键菜单里没有这一项的话，用管理员 CMD 切到目录再执行。
第二条是杀软拦截。这类工具的行为特征（读硬件指纹、生成机器相关字符串）跟某些恶意软件高度相似，主流杀软静默拦截的概率不低。拦截的表现往往不是弹窗，而是 exe 被替换成 0 字节空壳，双击毫无反应。装之前先把工具目录加进白名单，或者临时关掉实时防护，做完再开回来。
第三条就是上面提过的路径问题，中文和空格都会翻车，长路径（超过 260 字符）同样会失败。
跑工具之前，我习惯先校验一下文件本身是不是完好的：
# 跑授权工具之前，先确认文件没被杀软替换成空壳 $tool = "D:\CASS_Tools\GetMachineCode\获取机器码工具.exe" # 1. 看大小和时间戳，正常应该是几百 KB 到几 MB，不是 0 Get-Item $tool | Select-Object Name, Length, LastWriteTime # 2. 记下哈希，方便日后对比是否被改动 Get-FileHash $tool -Algorithm SHA256 # 3. 用管理员权限直接起进程，避免右键菜单缺失导致权限不够 Start-Process -FilePath $tool -Verb RunAs第 1 步里Length为 0 就是被杀软清空了，直接重新解压一份出来。第 2 步的哈希值建议记在记事本里，下次再遇到「怎么突然不好使了」，一比就知道文件有没有被动过。第 3 步的-Verb RunAs是让 PowerShell 走 UAC 提权，比手动右键更可靠，尤其是在资源管理器右键菜单被第三方工具改过的机器上。
5. 避坑与排查：五条让 CASS11 反复翻车的真实记录
这一章按「现象 → 原因 → 解决」的格式记五条，都是我在不同机器上真实遇到过的，不是理论推演。遇到同类现象可以按顺序对号入座。
5.1 现象：设置全改完、也重启了，提示照样弹
原因：最常见的是 VBS 被固件锁住了。部分品牌机的 UEFI 里有一项「基于虚拟化的安全性」或「Device Guard」，优先级高于 Windows 侧的注册表开关，你在系统里关掉，重启时固件又把配置写回去。第二种可能是改了但没真正重启，用了「快速启动」的机器，关机再开机并不等于重启，配置没重新加载。
解决：先用(Get-CimInstance Win32_ComputerSystem).HypervisorPresent确认当前状态，返回 True 就说明没关掉。接着跑bcdedit /enum "{current}"看hypervisorlaunchtype是不是真的写成了 off。都对了还不行，进 BIOS 找虚拟化相关项，把 VT-x 或 SVM 关掉。另外养成习惯，改完配置一律用shutdown /r /t 0重启，不要用开始菜单里的「关机」再按电源键。
5.2 现象：Windows 安全中心打开一片空白，没法关内存完整性
原因：SecurityHealthService服务的启动类型被改成了禁用（值为 4），通常是系统优化工具或精简版镜像干的。服务不起，安全中心的界面自然渲染不出来。
解决：用管理员 CMD 跑 3.5 节那条reg add，把Start改回 3，重启。重启后如果还是空白，检查一下Windows Security Service相关的几个服务是不是也被禁了，同一个思路恢复成手动启动即可。修好之后再回到图形界面关内存完整性。
5.3 现象：CASS11 能打开了，但 WSL 和 Docker Desktop 全废了
原因：hypervisorlaunchtype off和禁用虚拟机平台，把 WSL2 和容器方案依赖的底层能力一起关掉了。这不是故障，是预期行为——它们和 CASS11 抢同一个 hypervisor 位。
解决：做双模式切换，别指望两边同时跑。写个 bat 放在桌面，需要哪边就切哪边，切完重启。
:: 双模式切换脚本，保存为 cass_mode.bat，右键以管理员身份运行 :: 用法：cass_mode.bat cass 切到 CASS 模式（关 hypervisor） :: cass_mode.bat dev 切到开发模式（开 hypervisor，供 WSL2 / Docker 用） @echo off if /i "%1"=="cass" ( echo 正在切换到 CASS 模式... bcdedit /set hypervisorlaunchtype off echo 切换完成，请重启计算机后运行 CASS11 ) else if /i "%1"=="dev" ( echo 正在切换到开发模式... bcdedit /set hypervisorlaunchtype auto echo 切换完成，请重启计算机后使用 WSL2 / Docker ) else ( echo 参数错误，请使用 cass 或 dev ) pause%1是第一个命令行参数，/i让字符串比较忽略大小写，@echo off关掉命令回显让输出干净。这个脚本只改引导配置，不碰 Windows 功能开关，所以开发模式切回来之后如果 WSL2 还起不来，再去「启用或关闭 Windows 功能」里把虚拟机平台勾上。两件事分开做，出问题好定位。
5.4 现象：CASS11 主界面出来了，但左侧菜单栏是灰的，命令敲了没反应
原因：CASS 的 ARX 模块没被 CAD 加载。要么是 CASS 安装目录没被加进 CAD 的受信任位置（TRUSTEDPATHS），要么是SECURELOAD系统变量设成了 1 或 2，CAD 出于安全策略拒绝加载非受信路径下的 ARX。
解决：在 CAD 命令行输入OPTIONS，进「文件」选项卡，找到「受信任的位置」，把 CASS 的安装目录整个加进去，重启 CAD。或者在 CAD 命令行直接改系统变量：
命令: SECURELOAD 输入 SECURELOAD 的新值 <1>: 0设成 0 表示不做路径校验，加载任何位置的 ARX 都不拦。这个设置只影响当前用户配置，不会扩散到系统层面。设完重启 CAD，再开 CASS 应该就能看到完整的菜单和工具栏。如果还是灰的，去 CASS 安装目录下确认*.arx文件在不在，有些杀软会把这类文件当可疑模块隔离掉，加白名单后重新安装一遍 CASS 最省事。
5.5 现象：同一台机器，两次取到的机器码不一样
原因：参与哈希的硬件字段在两次取码之间发生了变化。常见触发点包括：BIOS 里改了 SATA 控制器模式（AHCI 与 RAID 互切）、插拔或更换了系统盘、禁用或启用了有线网卡、更新 BIOS 固件。虚拟机的场景更明显，虚拟硬件本来就是动态生成的。
解决：取码和填码这两步之间，硬件状态保持一致。具体做法是：先确认没有待执行的 BIOS 更新、没有要拆装的硬件、网卡保持启用状态，然后再取码，取完立刻用，别隔几天。已经取过的码失效了，重新取一次即可，这个动作本身没有成本，成本在于反复排查到底哪里变了。
6. 改完之后怎么验：一套三分钟能跑完的自检动作
前面几章的所有操作，收敛到最后其实就三个判据。我现在的习惯是，不管改完哪一层，都固定跑一遍这套自检，三行输出全部符合预期才去双击 CASS11 的图标，否则继续排查，别抱着「试试看」的心态点开——点开一次弹一次，心态容易崩。
# 三分钟自检，管理员 PowerShell 窗口执行 # 1) hypervisor 是否还存在，期望 False (Get-CimInstance Win32_ComputerSystem).HypervisorPresent # 2) 引导配置里的加载策略，期望 off bcdedit /enum "{current}" | Select-String hypervisorlaunchtype # 3) 内存完整性开关，期望 0 或读不到 (Get-ItemProperty ` "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" ` -ErrorAction SilentlyContinue).Enabled三条输出对应三个层级，第一行是结论，后两行是原因。第一行返回 False 就可以直接开 CASS11 了，后两行只是帮你确认是哪一层起的作用，方便以后复现。如果第一行是 True 但第二、三行看起来都对，那基本就是 BIOS 固件锁，进 UEFI 处理。
除了命令行，还有一个图形化的确认方式：运行msinfo32，在「系统摘要」里找「基于虚拟化的安全性」这一行，显示「未启用」才算彻底干净。这个界面我一般会截图存档，因为同一台机器过几个月再出问题，能直接对比出是哪一项被系统更新改回去了。
最后说一个我自己的教训。刚接触这个问题那会儿，我图快，上来就进 BIOS 把 VT-x 关了，机器重启完 CASS11 确实能开，但同一天下午要跑一个需要硬件虚拟化的工具，又得进一次 BIOS 开回来，来回折腾两趟，还在 BIOS 里手滑改错了一项设置，最后只能清 CMOS 恢复。从那以后我每次处理这类弹窗，都强制按「内存完整性 → 引导配置 → Windows 功能 → BIOS」这个顺序走一遍，每一层改完立刻跑一次上面的三行自检，改到哪一层过了就停手，绝不跳步。
这套 CAD2016 与 CASS11 的安装介质和配套工具，我按安装顺序分好了目录，解压之后再动，别在压缩包里直接双击，路径上的坑能少踩一半。希望帮到你。
本文还有配套的精品资源，点击获取
