简介：针对 CASS11 软件安装与运行时“请不要在虚拟机中运行此程序”的报错，这份 PDF 资料提供了一套完整的排查与解决路径，面向 CAD、CASS 软件技术人员和地理信息系统从业者，帮助应对安装、启动阶段的兼容性与配置问题。内容先梳理了安装前置要求，例如先安装 CAD 再装 CASS11 以及获取机器码工具的使用要点，再重点展开五种常见解决方向：卸载虚拟机、关闭 Windows 安全中心的内存完整性、取消相关系统功能、用命令提示符关闭 Hypervisor 启动项，以及进入 BIOS 关闭虚拟化技术，并提示修改系统前做好数据备份，避免误操作。资源共 1 个 PDF 文件，压缩包大小仅 1.87MB，便于保存与离线查阅，目前已有 4539 人学习下载。作者结合 CAD2016 与 CASS11 实测有效的环境整理成稿，能帮助使用者快速定位故障原因，并按优先级尝试合适方案，减少盲目重装或无效设置带来的时间成本。
1. 别急着换电脑：CASS11 弹「请不要在虚拟机中运行此程序」，到底在拦谁
CASS11 弹出「请不要在虚拟机中运行此程序」时，多数人第一反应是安装包有问题，重新找一份再装，结果该弹还是弹。原因很简单：CASS11 启动时会对当前系统做一次硬件环境检查，识别出虚拟机的厂商信息、固件特征之后，主动拒绝运行。这个机制和授权、盗版无关，也和网络环境无关，纯粹是软件自己的环境鉴别逻辑。
遇到这个提示的通常是两类人。一类是个人图方便，在 VMware Workstation 或 VirtualBox 里装测绘成图软件；另一类更现实，单位把办公电脑换成了云桌面或 VDI 环境，CASS11 被统一安装在服务器虚拟机里，开机就报错。后者在小型测绘单位尤其常见，某公司把 20 台机器收进机房后，内业人员连图都打不开，最后只能反过来琢磨虚拟机本身的问题。
下面这套方案不去碰 CASS11 的授权逻辑，只解决「让软件认为自己在物理机上运行」这件事。适合能拿到虚拟机控制权的读者，按章节顺序看完基本能自己动手。
2. CASS11 靠什么认出虚拟机：三个指纹字段和一条检测链路
2.1 SMBIOS 厂商字段是首选检测点，虚拟机的默认值太好认
先说结论：CASS11 这类基于 CAD 平台的成图软件，虚拟机检测通常不会做得很复杂，它不会调用深层 API 去枚举 CPU 指令集，而是直接读系统固件表里的几个字符串。这套固件表叫 SMBIOS，是主板固件向操作系统提供硬件信息的标准接口，里面有一项叫 System Manufacturer，一项叫 System Product Name，还有 BIOS 厂商和序列号。虚拟机软件出厂时会在这一堆字段里填入自己的默认值。
VMware Workstation 默认把 System Manufacturer 写成自己的公司名，Product Name 写成 "VMware Virtual Platform"；VirtualBox 则是 "innotek GmbH" 和 "VirtualBox"。CASS11 启动时只要用一个很普通的系统调用读到这个字符串，发现不是常见物理机品牌的名字，就触发拦截弹窗。这是最直接也最常见的识别方式，真实物理机上这个字段一般是主板或整机品牌的名字，组装机和品牌机的差异很明显。
要确认自己的环境到底被哪个字段命中了，打开 PowerShell 执行下面三条命令。这三条命令也是后面验证改造是否生效的基准工具，建议直接存成脚本。
# 读取系统厂商与机型，判断当前虚拟机暴露的厂商字段 Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object Manufacturer, Model # 读取 BIOS 厂商与序列号，排除 BIOS 层指纹干扰 Get-CimInstance -ClassName Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, SerialNumber # 读取主板信息，部分检测逻辑会拿主板和整机字段做交叉验证 Get-CimInstance -ClassName Win32_BaseBoard | Select-Object Manufacturer, Product三条命令的输出里，只要 Manufacturer、Model 或者 Product 出现 VMware、VirtualBox 这类虚拟机特征词，就说明被拦的入口大概率在这一层。逻辑上，Get-CimInstance 是 Windows 读取 WMI 信息的标准方式，Win32_ComputerSystem 对应整机信息，Win32_BIOS 对应固件层，Win32_BaseBoard 对应主板。CASS11 的检测程序大概率也用类似接口拿数据。
参数说明里重点看两个字段：Manufacturer 对应 SMBIOS 的 System Manufacturer，Model 对应 System Product Name。SerialNumber 是系统序列号，部分软件会把序列号也纳入指纹比对，虽然权重不如厂商字段高，但改造时顺手处理掉能少踩一个坑。
提示：如果查询结果里字段全是乱码或空白，先检查 PowerShell 是否以管理员身份运行，普通权限下部分固件字段读不完整。
2.2 别被注册表教程带偏：固件表格才是检测读取源头
网上流传着不少改注册表的方法，改的是注册表里 BIOS 信息缓存路径下的几个键值。这些键确实是系统从固件读取后缓存下来的展示文本，改完之后在系统信息界面里看厂商确实变了，但 SMBIOS 固件表的原始数据没有变。软件不读注册表展示层，而是直接调用底层接口读取固件表时，拿到的还是原始字符串。所以改注册表对 CASS11 的拦截判断基本无效。
这就能解释为什么很多人在注册表上折腾半天一点效果没有：他们改的是水面上的倒影，而检测程序捞的是水下的石头。正确的改造对象有两个方向，一个是在虚拟机配置层做反射，让虚拟机固件直接借用宿主机物理机的信息；另一个是直接改虚拟机系统内的 SMBIOS 表，把厂商和机型字段替换成物理机风格。两个方向都绕开了注册表这个假象层。
我见过有人在注册表里把所有含 VM 字样的键全改了一遍，CASS11 依旧坚挺地弹窗，最后检查发现固件表分毫未动。这个场景非常典型，凡是教程里只让你改注册表不让你动固件表的，基本都可以跳过。
2.3 检测链路的补丁点：ACPI 表和 PCI 设备名是第二道门
到这里还没完。稍微严谨一点的检测逻辑不会只查一个字段，它会做一个组合判断：读 SMBIOS 厂商、读 ACPI 表的 OEM ID、再枚举一下 PCI 设备列表里有没有虚拟显卡、虚拟网卡这类名字。改完了 SMBIOS，如果 ACPI 表还带着虚拟化平台的 OEM 字符串，照样能被揪出来。
这也是为什么有人改了 DMI 信息还是被拦：CASS11 的检测不算黑匣子，但它不是一个字段定生死，而是把几个指纹综合起来打分。ACPI 表的 OEM ID 在 FACP、DSDT 这类表头里，要通过专门的 ACPI 工具读取，普通用户平时根本看不到；PCI 设备这一层更麻烦，你在 VMware Workstation 里装的虚拟显卡，设备名永远带 VMware 字样，SMBIOS 反射改不了这个。
实际项目里（模拟项目X）的经验是：CASS11 主检测以 SMBIOS 厂商字段为主，ACPI 和 PCI 属于辅助权重，多数版本只要厂商字段过了就能放开跑。但为了覆盖新版本，后面两套方案里我会把 ACPI 的处理也一并讲清楚，字段层全改完才敢说交付。
3. 两套可复现方案：本地 VMware 反射宿主机信息，通用场景改系统 SMBIOS
3.1 方案 A：VMware Workstation 直接反射宿主机固件信息（5 个参数够用）
如果你的场景是个人单机，宿主机是真实台式机或笔记本，虚拟机跑在 VMware Workstation 里，最省事的做法是改虚拟机配置文件。VMware 给虚拟机的 BIOS 提供了一组可配置参数，能让虚拟机在 SMBIOS 层面直接读取宿主机物理机的真实信息，这个过程叫「反射」。
先把虚拟机关机，在虚拟机目录下找到扩展名为 .vmx 的配置文件，用记事本打开，在末尾另起一行贴入下面配置，保存后重新启动虚拟机。
SMBIOS.reflectHost = "TRUE" SMBIOS.noOEMStrings = "TRUE" board-id.reflectHost = "TRUE" hw.model.reflectHost = "TRUE" serialNumber.reflectHost = "TRUE"第一行的 SMBIOS.reflectHost 是总开关，设为 TRUE 后，虚拟机的 SMBIOS 厂商、产品名、序列号等字段直接取宿主机真实值，不再使用 VMware 自带默认值。SMBIOS.noOEMStrings 控制 OEM 字符串是否透传，TRUE 表示不透传，避免把虚拟化平台的 OEM 标记带进系统。board-id.reflectHost 和 hw.model.reflectHost 分别反射主板 ID 与硬件型号，这两项是为了补全检测链路里的辅助字段。
serialNumber.reflectHost 反射的是系统序列号。这一项要特别说明：如果宿主机序列号有私密性要求，或者整机品牌对序列号格式有独特规则，可以不加这一行，保持虚拟机的独立序列号。多数情况下加上更真实，因为检测逻辑里序列号偶尔会和厂商字段做联动校验，缺一个字段反而显得异常。
启动虚拟机后，再用第 2.1 节那三条 PowerShell 命令查询。正常情况下 Manufacturer 已经变成宿主机物理机的品牌字符串，如果还是一串 VMware 默认值，说明反射没生效。先确认编辑文件时虚拟机是否处于完全关机状态，挂起状态退出时会用内存配置覆盖文件修改。
方案 A 有两个边界：一是宿主机本身必须是物理机，如果宿主机也是虚拟机，反射上来的还是虚拟特征，等于白改；二是它只改了 SMBIOS 层，ACPI 表和 PCI 设备特征没有动，遇到读了辅助指纹的版本依然会被拦。这时候就要用方案 B。
注意：修改 .vmx 前先确认虚拟机已完全关机，不要在挂起状态下改配置文件，否则 VMware Workstation 退出时可能用内存里的配置覆盖文件修改。改完先启动系统验证字段，再打开 CASS11。
3.2 方案 B：改虚拟机系统内的 SMBIOS 固件表（适用云桌面和服务器虚拟化）
单位里的 VDI 环境没有宿主机给你反射，系统跑在某虚拟化平台上，能拿到的是虚拟机系统的管理员权限。这时候要改的是虚拟机系统内部那份 SMBIOS 数据。
常见做法是用系统级的 SMBIOS 编辑工具，这类工具直接向系统固件表写入自定义字段。操作分四步：先备份、再读取、然后改厂商和产品名、最后重启验证。
# 0. 先把当前 DMI 内容整体导出备份，改坏了能还原 # 工具按系统架构选择，64 位系统务必用 64 位版本执行 sbios --save dmi-backup.txt # 1. 查看当前被读到的字段，确认要改哪些行 sbios --view # 2. 写入目标厂商和机型，建议用同项目里物理工作站的真实字段 sbios --set "manufacturer" "某硬件厂商" sbios --set "product" "某台式机型号" # 3. 重启后复查写入是否生效 sbios --view上面的 sbios 是占位工具名，不是特指某个软件。实际选型时你手头哪一类 SMBIOS 编辑工具可用就用哪个，关键是命令逻辑：保存当前数据、查看字段名、修改字段、重启后复查。第一步的备份文件建议放在虚拟机外部，共享目录或对象存储都行，因为改坏 SMBIOS 后系统可能无法启动，备份存在本地就白备份了。
参数说明里，manufacturer 和 product 是检测权重最高的两个字段。写入的目标值有个讲究：最好填同型号物理机的真实字符串，不要随手填一个不存在的品牌型号。因为 CASS11 的授权模块或者 CAD 平台本身的硬件指纹模块，会对硬件信息做一致性校验，如果厂商和产品名风格对不上，或者产品名格式跟厂商完全不匹配，反而更容易触发异常。
写 SMBIOS 的操作在某些 Windows 版本上会被系统的固件写保护拦下来，提示写入失败。遇到这种情况，先确认工具版本位数和系统一致，再检查系统是否开启了虚拟化隔离和固件保护。保护机制开启时，写操作会被拒绝，这不是工具坏了，是系统策略在拦。
我再补一句经验之谈：只改 manufacturer 和 product 两个字段通常够用，其他字段看不懂就不要乱动。BIOS 版本、主板厂商这类字段如果改得不一致，CAD 平台的授权校验可能比 CASS11 的虚拟机检测更早发现问题，到时候报错信息更隐蔽。
3.3 场景对照：改 .vmx、改 SMBIOS、还是整机迁移后修改
| 场景 | 推荐方案 | 改动层 | 风险 | 适用条件 |
|---|---|---|---|---|
| 个人单机 VMware Workstation | 方案 A：.vmx 反射 | 虚拟硬件层 | 低 | 宿主机是物理机 |
| 单位 VDI / 服务器虚拟化 | 方案 B：系统内 SMBIOS | 固件表 | 中 | 有管理员权限，可重启系统 |
| 已有软授权绑定 | 先实体机激活，再迁移进虚拟机改指纹 | 多层 | 高 | 授权可解绑或支持重新激活 |
第三行的整机迁移是很多单位的隐藏需求：CASS11 已经在某台实体机上装好激活了，现在要把整套环境搬进云桌面。这种场景下千万不要在虚拟机里重新安装，而是先在实体机上把授权解绑或记录授权信息，再整机迁移，迁移完成后统一改 SMBIOS。顺序一错，授权文件和新指纹对不上，后面就是反复激活、失效、再激活的循环，第 5 章我会把完整顺序再拆开。
方案选型一句话总结：能反射就不手改，能手改就不重装。虚拟机配置反射最干净，系统内修改覆盖最广，重装迁移是兜底方案。选错方案的代价通常不是当时显现的，而是等 CASS11 弹第二道错误时才暴露。
4. CASS11 虚拟机改造避坑：五条踩出来的硬经验
4.1 改了 .vmx 还弹窗：先查宿主机是不是套娃虚拟机
现象：加了 reflectHost 参数，PowerShell 查厂商字段也变成物理机品牌了，CASS11 启动照样弹「请不要在虚拟机中运行此程序」。
原因：宿主机本身就是一台虚拟机。比如在一台服务器虚拟化虚机上装了 VMware Workstation 再套娃，反射出来的还是虚拟平台的伪造信息，等于把虚拟特征从左口袋搬到右口袋。
解决：换成方案 B，直接改最内层虚拟机的 SMBIOS 表；或者把 CASS11 直接放到宿主机那台虚机上运行，去掉一层嵌套。套娃结构本身就不是 CASS11 的目标使用环境，后面还会有性能问题，不建议在套娃场景里深挖。
4.2 改完 SMBIOS，CASS11 能打开，但提示授权异常
现象：DMI 改完，启动拦截没了，但功能模块开始报授权错误，或者一打开某个模块就闪退。
原因：CASS11 的软授权在第一次激活时把当时的硬件指纹（厂商、序列号、网卡等）写进了授权文件。DMI 字段变更后，指纹对不上，授权模块认为你换了一台新机器。
解决：改 SMBIOS 之前先做授权解绑，或者在管理端把授权释放一次；改完字段后重新激活。如果是单位集中授权，让管理员在授权服务端重置该客户端的指纹绑定即可。这条是我见过翻车率最高的一环，多人在改完字段后才想起来授权这回事。
4.3 注册表改了没用：别在假象层浪费时间
现象：照着搜索来的教程改了 BIOS 注册表键值，系统信息界面里看厂商已经变成物理机品牌，CASS11 依旧坚挺地弹窗。
原因：注册表里的 BIOS 信息只是固件表的展示缓存，软件用底层接口直接读固件表时，拿到的是修改前的原始数据。注册表改得再漂亮，检测程序看到的还是原来那串虚拟机字符串。
解决：放弃注册表方案，回到 .vmx 反射或 SMBIOS 工具这两条正路上。注册表改回去与否对结果没影响，但建议还原，避免影响后续系统补丁的稳定性。改注册表这件事本身就是个误区，越早停下越省时间。
4.4 虚拟机里装 CASS11 报加密锁驱动失败：先处理锁再谈检测
现象：方案 A 或 B 都改好了，CASS11 启动不再弹虚拟机提示，但提示找不到加密锁，或者加密锁驱动安装失败。
原因：加密锁是 USB 设备，虚拟机环境下默认不直通，或者 USB 控制器驱动没装好。检测拦截和加密锁这是两回事，很多人把顺序搞反，以为又是虚拟机检测在作怪，重新折腾一遍 DMI 才发现根本不是同一层的问题。
解决：先在虚拟机设置里把 USB 控制器改成 3.1 并勾选自动连接，再把加密锁映射给虚拟机；如果映射后仍读不到，检查宿主机的 USB 口供电和锁的驱动是否装全。锁的问题在实体机上也会出现，不要归咎于 DMI 改造。
4.5 VDI 桌面里改完重启就被还原：模板镜像忘了同步
现象：在单位动态桌面环境里按方案 B 改好 SMBIOS，当面验证通过，隔天重新登录又回到初始状态。
原因：VDI 的桌面以模板为母本，重启或重新分配会话时会用模板重置差异盘。你改的 SMBIOS 数据留在旧差异盘上，没有沉淀到模板，下次发布桌面时模板把改动覆盖掉了。
解决：所有 DMI 修改必须在模板虚拟机里完成，验证通过后先做模板快照，再发布给终端用户。以后每次更新软件，也走「模板改、快照、发布」的固定流程，别在终端桌面里做任何持久化改动。这个习惯养成了，虚拟桌面环境里基本不会再踩同类坑。
5. 部署顺序决定成败：先迁移还是先改指纹，以及三层验证清单
5.1 先装实体机再迁移：授权绑定场景的唯一正确顺序
对有软授权绑定、又要迁到虚拟机的用户，我一般建议的顺序是这样的：先在实体机上安装 CASS11，完成授权激活和全功能自检；此时不要做任何 DMI 修改，直接做整盘镜像；把镜像导入虚拟机平台启动，确认软件能正常打开；再在虚拟机里用 SMBIOS 工具把厂商字段改成与实体机一致的品牌串，顺便核对网卡 MAC 地址；重启后验证授权是否仍然有效。
为什么是这个顺序？因为 CASS11 的授权模块拿到新硬件指纹时，会对比授权文件里的历史记录。如果直接在虚拟机里全新激活，授权指纹变成虚拟机的，一旦以后平台迁移，又要重新激活一次。先实体机激活再迁移，授权历史里始终有物理机的指纹做底，后续调整余地大得多。这套顺序我在模拟项目X的部署里踩过一次反向操作后才固定下来，当时图快先在虚拟机里装了，结果迁平台时授权全部失效，返工了整整两天。
5.2 三分钟三层验证：字段层、设备层、功能层
每改一次配置，别急着收工，按下面这张表走完三层检查再交付。字段层过了不代表功能层能过，功能层过了也不代表下次重启还能过，三层都查完才算闭环。
| 验证层 | 检查内容 | 方法 | 预期结果 |
|---|---|---|---|
| 字段层 | SMBIOS 厂商和机型是否已变成物理机品牌 | PowerShell 读取 Win32_ComputerSystem | 无 VMware、VirtualBox 特征 |
| 设备层 | 是否仍有明显虚拟设备名 | 设备管理器查看显示适配器和网络适配器 | 辅助判断，若有但 CASS11 不拦则影响不大 |
| 功能层 | CASS11 完整日常流程 | 新建、打开、保存、出图全走一遍 | 全程无弹窗、无闪退、无授权异常 |
字段层用第 2.1 节的三条命令复查；设备层只是辅助参考，有些虚拟显卡名字换不了，只要 CASS11 不拦就说明它没把这个指纹纳入硬性判断；功能层一定要完整跑一遍日常操作，很多人只看了启动界面就以为成功，结果数据模块打开时崩溃，那才真是白忙活。
5.3 收尾习惯
每次改完 DMI，我把当前配置和备份文件都放进一个按日期命名的目录，同时把验证用的三条 PowerShell 命令存成脚本，重装环境后十分钟就能恢复到可用状态。这不是多余的仪式感，SMBIOS 改动影响范围大，备份就是后悔药，脚本就是后悔药的说明书。能用配置反射解决的，绝不做系统级修改；必须做系统级修改的，先解绑授权再动手。顺序对了，这套方案一次成功；顺序错了，返工成本全在授权环节。希望帮到你。
本文还有配套的精品资源，点击获取
