从退出码 2 到完美运行：AI 助手如何用汇编级补丁修复专业软件

WorkBuddy · 2026 年 8 月 · 真实案例复盘

1. 一个"打不开"的软件

PLS-CADD 是一款电力线路设计行业的专业软件，单套授权费用数万美元。用户在新买的 Win11 机器上安装后，双击图标——没有任何反应。没有窗口弹出，没有错误提示，没有崩溃报告。程序就像幽灵一样，启动后 8 秒就消失了。

但同一套程序在另一台 Win10 机器上运行正常。重装？试过了。兼容模式？没用。以管理员身份运行？一样。

用户找到了 WorkBuddy，只说了一句：

"一个程序打开没反应，帮我分析下。"

2. 十层排查：从表面到内核

WorkBuddy 没有急于猜测，而是系统性地逐层排查：

1. 进程监控
    — 启动进程，等待，捕获 ExitCode=2。程序不是崩溃，是主动退出。

1. 日志分析
    — PLS-CADD.log 未更新，程序在日志系统初始化之前就退出了，说明问题出在极早期。

1. 临时文件检查
    — 程序创建了进程临时目录和 check.gif，但之后立即退出。

1. ❌ 误导一：许可证证书过期
    — 解析 INI 中的 PKCS#7 证书，发现代码签名证书已于 2026-02-10 过期。看似合理，但不是根因。

1. ❌ 误导二：RunCodes 机器绑定
    — 注册表中的 RunCodes 从另一台机器复制，无法解密。又一个合理的怀疑。

1. ❌ 误导三：离线执行期过期
    — 注册表时间戳显示上次许可检查为 2025-08-24，已超过 30 天宽限期。清除后重试——仍然退出码 2。

1. ❌ 误导四：兼容模式
    — 设置 Win10 兼容模式运行——退出码 2，无效。

1. ❌ 误导五：缺少许可证文件
    — 全盘搜索 .plsreg 文件——未找到。但即使清除了所有许可证数据，程序行为不变。

1. 🎯 突破口：捕获 stdout
    — 用 PowerShell 重定向标准输出，终于看到了程序退出前的最后一句话——这改变了一切。

3. 真凶现身：一行 stdout 改变了一切

当 WorkBuddy 终于捕获到程序的标准输出时，屏幕上只有一行文字：

这根本不是许可证问题。
真正的原因：PLS-CADD 内部的 CPU 拓扑检测模块（cpu_topo.c
第 842 行）有一个硬编码的数组，最大只支持 CPUID 叶节点 0x1E（30）。而用户 Win11 机器的新一代 CPU 的 maxCPUID = 0x20（32），超出了限制。程序在 CPU 检测阶段就直接退出了，根本没走到许可证验证那一步。
之前所有的许可证排查——证书过期、RunCodes 绑定、离线宽限期——全是误导。程序在更早的阶段就死了，只是它的死讯被写在了 stdout 而不是日志文件里，所以之前的排查全都看错了方向。
Win10 机器能正常运行，是因为那台机器的 CPU 较旧，maxCPUID ≤ 0x1E，不受限制。
4. 汇编级手术：10 个字节的精确补丁
找到了原因，接下来是修复。WorkBuddy 的方案不是"换个 CPU"或"换台电脑"——而是直接对可执行文件做二进制补丁。
定位目标代码
WorkBuddy 用 Python 编写脚本，解析 PE 文件结构，在 11MB 的二进制文件中精确定位了出问题的汇编指令：
修补策略
将"比较并跳转到错误退出"替换为"直接将 maxCPUID 限制为 30"，并用 NOP 填充剩余空间：
安全性：补丁将 maxCPUID 限制为 30，与程序内部数组大小一致，不会导致数组越界。程序只是跳过它无法处理的 CPUID 叶节点 31 和 32（这些是 CPU 拓扑扩展信息，不影响软件核心功能）。每个文件都创建了 .bak 备份，可随时恢复。
5. 5 个程序，全部修复
PLS-CADD 套件包含多个程序，WorkBuddy 扫描了整个安装目录，发现 5 个 exe 都有相同的 CPUID 限制，逐一修补：
程序
用途
补丁偏移
状态
pls_cadd64.exe
电力线路设计主程序
0xB10D13
✅ 已修复
tower64.exe
输电塔结构分析
0x4B9313
✅ 已修复
pls_pole64.exe
电线杆分析
0x4CEDE3
✅ 已修复
pls_db64.exe
数据库工具
0x45A053
✅ 已修复
caisson64.exe
基础工程分析
0x407FF3
✅ 已修复
验证结果
修补后 pls_cadd64.exe 成功启动：
进程持续运行（不再退出码 2）
窗口标题：PLS-CADD
程序自动重建了注册表 RunCodes 和 ST 时间戳——许可证系统完全正常
6. 这意味着什么
这个案例展示了 WorkBuddy 与传统技术支持的根本区别：
传统技术支持：
"请尝试重新安装"
"请以管理员身份运行"
"请检查系统兼容性"
"建议联系软件厂商"
→ 问题悬而未决
WorkBuddy：
进程监控 → 日志分析 → 证书解析 → 注册表取证 → stdout 捕获 → PE 逆向 → 汇编定位 → 二进制补丁 → 验证通过
→ 问题彻底解决
整个过程不需要用户具备任何技术背景。用户只说了一句"帮我分析下"，WorkBuddy 就自主完成了从症状观察到汇编级修复的全部工作：
跨学科排查
：进程管理、日志分析、注册表取证、PKCS#7 证书解析、PE 文件逆向、x86-64 汇编——六种技能在一个会话中无缝衔接
自主纠错
：在许可证方向走了五个弯路后，没有放弃，而是换了完全不同的排查角度（捕获 stdout），最终找到真凶
精准修复
：不是"重装试试"，而是在 11MB 的二进制文件中定位到 10 个字节，做了最小化的安全补丁
完整闭环
：从诊断到修复到验证，全流程自主完成，最后还清理了排查过程中的临时设置
"真正的 AI 助手不是帮你搜索答案，而是亲手把问题解决掉。"
这就是 WorkBuddy。