做GIS软件部署这些年，我对ArcMap安装包里的License Manager有一种条件反射般的警惕。进度条走到“注册组件”附近突然弹出一个对话框，标题写“错误1935”，下方往往跟着一串十六进制代码——这是许可服务安装失败的典型信号。License Manager装不上，哪怕后面ArcMap主程序装好了，也找不到可用许可，项目工期直接就崩了。
这篇文章不是给你罗列网上那些“关杀毒、管理员运行”的套话，而是把我实际处理这类故障时最稳定的一套排查顺序完整讲一遍：先理解1935错误到底发生在哪个环节，再判断系统环境的问题出在哪儿，最后按成功率从高到低逐层执行修复。正在被这个错误卡住的运维同学，或者准备在新电脑上部署ArcGIS环境的朋友，跟着走一遍基本能少熬一个晚上。
1. 1935错误的真面目：许可服务到底卡在哪一步
1.1 安装脚本的双重身份：InstallScript与MSI组件
ArcMap配套的License Manager安装包并不是一个纯MSI文件。它的安装过程分两段：第一段是InstallShield的InstallScript脚本，负责释放文件、写注册表、创建系统服务；第二段在注册运行库时把控制权交给Windows Installer。1935错误码的官方解释是“安装程序集组件时出错”，翻译过来就是：Windows Installer在把几十个所有程序共用的DLL嵌入到系统共享目录（WinSxS）的时候失败了。
可以用一个生活类比来理解：WinSxS目录就像小区公共配电房，新住户要接入电表，但配电房之前被某些装修队弄得乱七八糟，新住户就不能正常接入。1935就是跳闸报警灯，问题根源往往不在“新住户”身上，而在配电房——也就是系统的共享运行库环境。
1.2 我见过的高频诱因，按出现频率排序
先给一张经验表，让你心里有个底，修复前可以对照自己的机器情况判断大概率的嫌疑点：
| 诱因 | 出现频率 | 典型表现 |
|---|---|---|
| 旧版Microsoft Visual C++运行库损坏或缺失 | 最高 | 错误详情附带“系统错误14001”或找不到vc80/vc90模块 |
| Windows Installer服务损坏或第三方安全软件拦截 | 高 | 重试偶尔成功，重启后必现 |
| .NET Framework版本异常或功能未启用 | 中等 | 错误出现在注册.NET程序集阶段 |
| 旧许可组件卸载不干净，注册表残留 | 中等 | 之前装过其他版本Licensing组件 |
| 非管理员权限安装 | 中等 | 同一安装包换管理员账号就成功 |
| 临时目录权限异常或磁盘空间不足 | 低 | 错误出现在解压阶段 |
这张表不是凭空列的，大部分现场故障最后都落在第一行。ArcGIS许可服务是典型的原生C++应用，安装时要在WinSxS里注册共享运行库，一旦系统里存在半损坏的旧版本，或者安全软件盯着写入动作不放，就会在“Win32程序集”注册阶段报告1935。
1.3 先看弹窗里的“系统错误”字段，能省一半排查时间
很多人在1935弹窗里只看到红叉就赶紧点了关闭，其实弹窗里的错误文本非常有价值。我经手过的机器上，常见这种格式：
Error 1935. An error occurred during the installation of assembly component {组件GUID}. HRESULT: 0x800736B1.0x800736B1转成十进制就是14001，这个数字代表“side-by-side configuration is incorrect”，也就是程序集并行配置错误，基本直指VC++运行库损坏。再往下看还可能遇到这些常见系统错误码：
- 14001（0x800736B1）：程序集并行配置错误，最常对应VC++库损伤。
- 16389（0x80070005）：访问被拒绝，通常是权限不足或安全软件干预。
- 2（0x80070002）：找不到指定文件，可能是临时目录被清理不完整或运行库缺失。
处理这类问题有个原则：弹窗里出现的错误码越具体，修复方向就越明确。你花三十秒读一下错误详情，比盲试任何“一键修复”工具都靠谱。
2. 动手前的环境判读：五分钟确认问题方向
2.1 事件日志里的MsiInstaller记录，比报错框更诚实
打开事件查看器，筛选来源为MsiInstaller的日志，时间对应到安装失败那一刻。重点看11707和1022这两种事件ID，它们通常会带着“Product: ArcGIS License Manager”和一条“Command line”信息，直接告诉我是哪个组件注册失败。这是定位问题的第一手资料，比反复点重试有效得多。
具体操作路径：
- Win+R输入
eventvwr回车。 - 左侧导航到Windows日志 -> 应用程序。
- 右侧点击“筛选当前日志”，事件来源勾选MsiInstaller。
- 按时间找到安装失败窗口的记录，双击复制完整错误文本。
如果你发现事件日志里连续几条都是同一个组件的热错误，基本就可以确认问题出在运行库注册环节，而不是安装包本身损坏。如果事件日志压根不写任何MsiInstaller记录，那要回头检查安装包是不是被安全软件拦截在释放阶段了。
2.2 Windows Installer服务的健壮性检查
打开服务管理器（services.msc），确认Windows Installer的状态。正常情况它是“已启动”，或者至少可以手动启动。如果服务标为“手动”但启动时报“找不到指定文件”，说明系统文件损伤，这时候可以考虑重注册Windows Installer服务：
打开管理员CMD，依次执行：
msiexec /unregister msiexec /regserver net start msiserver提示：执行完三条命令后，回服务管理器验证状态，能正常起来再继续。安全软件如果拦住了msiexec的进程行为，注册动作会执行到一半被“踩刹车”，所以重注册之前最好先把第三方安全软件的服务完全退出，别只关托盘图标。
2.3 运行库与.NET清单梳理：缺什么、坏什么、装什么
在控制面板的“程序和功能”里，直接查看所有“Microsoft Visual C++ 20xx Redistributable”条目。ArcMap的许可服务在不同版本依赖不同的运行库：较早版本（如10.2）依赖VC++ 2005/2008，后续版本基本依赖2013和2015-2022。建议x64和x86版本都装上，别觉得64位系统只装x64就行——很多许可服务进程是32位，需要的是x86运行库。
.NET部分也不能忽略。Win+R输入optionalfeatures，确认“.NET Framework 3.5（包括 .NET 2.0 和 3.0）”是否勾选启用。部分ArcGIS 10.x的安装步骤要求.NET 3.5存在，企业内网环境尤其常见默认镜像没勾选这个功能的情况。缺失的话，安装接近完成时容易出现1935或类似错误。
3. 修复实操流水线：按成功率从低到高逐层执行
3.1 零成本试错：完全退出安全软件并用管理员身份安装
这一步没成本，先排除人为因素。注意“完全退出”不是点托盘右上角的X，许多安全软件退出界面后核心服务和驱动仍在运行。打开任务管理器，确认安全软件相关进程都消失了，再把安装包复制到本地磁盘根目录，右键“以管理员身份运行”。
有个实际案例供参考：现场一台机器从U盘里直接双击安装包，反复失败；把安装包拷贝到C盘根目录后一次成功。原因是U盘的文件系统或目录权限影响了组件注册。这一步虽然简单，但能做到的人不多，值得先试。
3.2 清理临时目录和Installer缓存，别手滑删错
安装过程中，InstallScript会往系统临时目录释放中间文件，如果%temp%目录权限异常或空间不足，组件注册也会失败。清理方法：
- 打开
%temp%和C:\Windows\Temp，删掉能删的内容。 - 遇到“文件被占用”提示时，打开资源监视器查看是哪个进程锁定了文件，结束进程后再删。
- 运行磁盘清理工具，勾选“临时文件”和“临时Windows安装文件”进行清理。
特别提醒：C:\Windows\Installer目录不要手动清理。这里存放的是所有MSI安装数据库和补丁缓存，乱删之后很多软件会出出现无法卸载、修复、升级的问题。这个目录的清理工作应该交给磁盘清理和系统工具，而不是手贱去翻。
3.3 重装VC++运行库：整个修复流程中的关键一步
把VC++运行库单独安装一遍，用来判断问题归属：
- 到微软官方下载页面，下载
vc_redist.x86.exe和vc_redist.x64.exe，版本选2015-2022最新版。 - 先装x86，再装x64，全程管理员身份。
- 重点观察：单独安装库时如果复现1935，说明不是ArcMap安装包的问题，而是系统组件底层损伤。此时先执行系统修复：
dism /online /cleanup-image /restorehealth重启后执行：
sfc /scannow- 如果单独装库正常，再回装License Manager。
- 回装仍报错的话，把现有所有VC++库统一升级到微软支持的版本，而不是只补缺失那个，再次安装。
为什么要这样拆开判断？License Manager安装过程中会调用VC++库注册，单独装库能成功，至少证明系统基本组件是可写的；回装仍然失败，往往是安装包内嵌的旧库版本和系统里已有库存在冲突。这时候统一升级现有版本通常能解决。
另外别去下载第三方“运行库合集”，这类整合版在注册表信息上经常不完整，装上之后反而可能引出一堆新错误。运行库这东西，官方原版才是底线。
3.4 检查.NET环境与注册表残留
如果运行库层面没问题，接着看.NET。系统镜像缺少.NET 3.5的，用管理员CMD执行：
dism /online /enable-feature /featurename:NetFx3 /all执行完重启，再继续安装。
注册表残留方面，Win+R输入regedit，检查这些位置：
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ESRIHKEY_LOCAL_MACHINE\SOFTWARE\ESRI
如果之前卸载过旧版本许可组件，这里可能残留不完整的子键。右键导出备份后，再删除不完整子键。注意：不要直接删整个ESRI主键，里面包含ArcMap桌面的许可引用，网上很多教程让“直接删ESRI键”，真照做会让你连主程序一起废掉。
3.5 微软官方安装疑难解答工具与系统还原点兜底
走到这一步还没解决，就用微软官方的“程序安装和卸载疑难解答工具”。这个工具会重置Windows Installer状态、清理临时文件、修复某些常见注册表问题，运行后重启电脑再安装。它有时候会有奇效，但局限在于不会帮你把缺失的运行库补回来。所以运行前最好先确认3.3的内容已经做完了。
如果你的系统有明确的还原点，而且安装失败之前环境还相对干净，回滚到那个还原点，先装运行库，再装License Manager，速度往往比继续原地排查快得多。前提是还原点要真的存在，而不是系统设置里“显示”一个但还原失败。
4. 装成功只是开始：许可服务的运行态验证
4.1 服务状态、进程与默认端口检查
安装完成后进入服务管理器，找到许可服务（不同版本显示为ArcGIS License Manager或License Manager Service），确认启动类型是自动、状态是运行中。然后命令行检查端口：
netstat -aon | findstr 27000正常应该看到LISTENING状态，对应的PID在任务管理器里能定位到许可服务主进程。如果服务显示“已启动”但端口没有监听，大概率是许可文件路径有问题。打开许可管理界面，确认许可文件路径指向你保存的那个.lic文件。这里有个实际经验：路径中不要出现中文和括号目录，个别环境会出现服务后台找不到文件、前台却不报错的诡异情况，检查路径能省去大量误判。
4.2 本机连接测试与防火墙规则
在ArcMap主程序里打开可用性设置，应能看到localhost节点以及批准的许可类型。如果连接测试失败，按这个顺序排查：
- 防火墙有没有放行许可服务程序，或允许27000端口TCP入站。
- hosts文件中localhost解析是否正常。IPv6优先环境下，可以把
127.0.0.1 localhost手动放在hosts文件最前面，避免解析到::1。 - 如果机器是虚拟机或者做过硬件克隆，授权绑定的特征值会变化，需要重新申请许可文件。
给一条防火墙命令行规则（管理员CMD）：
netsh advfirewall firewall add rule name="ArcGIS License TCP 27000" dir=in action=allow protocol=TCP localport=27000不习惯用命令行的话，可以在“高级安全Windows Defender防火墙 -> 入站规则 -> 新建规则 -> 端口”里做同样配置。这两件事做完，本机连接基本就顺了。
4.3 安装完成的现场固化
安装成功不是终点，建议顺手固化现场状态：
- 创建新的系统还原点，命名成“After Lic Manager Install”，方便后续回滚。
- 备份许可文件到非系统盘，顺手记录绑定信息。
- 记录当前VC++运行库和.NET版本的状态，方便Windows更新后做对比。
为什么值得固化？许可服务对运行库环境敏感，Windows大版本更新可能调整WinSxS里的共享组件，一旦后续更新把某个旧库替换掉，服务可能静默起不来。有还原点和许可文件备份，恢复时间可以从半天缩短到半小时。
5. 从1935说开去：同族许可安装错误的通用排查逻辑
5.1 错误码家族：不要一条道走到黑
1935并不是唯一的安装类错误。许可服务安装时还可能遇到这些兄弟错误码：
| 错误码 | 典型时机 | 主要修复方向 |
|---|---|---|
| 1935 | 注册Win32程序集阶段 | 检查VC++运行库、WinSxS、Windows Installer |
| 1920 | 服务启动失败 | 检查服务账户权限、依赖服务 |
| 1923 | 服务安装失败 | 检查旧服务残留、端口占用、安全软件阻止 |
| 1706 | 找不到安装源 | 检查安装包完整性、盘符变化 |
| 1603 | 安装期间致命错误 | 查看临时日志、管理员运行、升级Windows Installer |
这组错误的核心逻辑是一样的：问题通常不在安装包本身，而在Windows系统组件和权限环境。排查顺序固定为：事件日志定位组件 -> 检查运行库 -> 复位安装服务 -> 清理残留 -> 重装。不需要看到错误码就焦虑，家族解法大同小异。
5.2 环境“干净”才是一劳永逸：部署阶段的预防思维
从大量现场经验来看，1935高发的机器都有共同特点：长期不更新、装过各种绿色软件和运行库整合包、安全软件策略激进，或者使用过非正规系统镜像。想从源头降低发生率，建议把运行库和.NET纳入基础镜像，每次装机打好底子再装ArcGIS。
批量部署环境还有一个实操经验：先用一台干净机器验证完整安装顺序，再制作系统镜像，而不是让每台机器都踩一遍坑。做过镜像恢复的机器尤其要注意，Sysprep或克隆后的系统，运行库注册状态可能不完整，装什么大型软件都可能翻车。
5.3 最后的兜底方案：保留文件的重装系统
最后说一个不算优雅但非常有效的兜底方案。如果问题机器已经重度使用多年，各种修复手段都试过仍然失败，直接用“重置此电脑 -> 保留我的文件”恢复系统。恢复完成进入桌面后，第一件事装VC++运行库和.NET 3.5，然后装License Manager，最后装ArcMap主程序。
这个顺序我在多台顽固环境机器上实测有效，原因是重装后的系统没有旧组件残留和安全软件干扰。代价是第三方软件需要重装，但用户的数据文件都能保住。真到了这一步，别再纠结是不是某个特定驱动的问题了，恢复系统往往比继续排查快得多。
我在实际处理1935错误时的体会有两条。第一条：永远先确认运行库，不要第一轮就去动注册表，删除ESRI键值只会让局面更复杂。第二条：安装完成后别急着跑，花三十秒确认许可服务端口和防火墙规则，能避免后续一连串连接问题。这两个动作做扎实，License Manager的1935基本就彻底翻篇了。希望这篇经验能帮你少折腾一个晚上，如果是在某个特定版本上碰到的顽固案例，欢迎在评论区聊聊你的排查过程。
