Install4j升级时卸载阶段阻塞/崩溃问题排查求助

• 进程残留与资源锁定：主动终止主进程后，可能存在未被清理的子进程（比如Spring Boot应用启动的内嵌容器子进程、后台守护进程），或旧版本文件被系统服务、第三方进程占用（如日志文件、临时缓存文件）。此外，升级流程中当前安装程序自身可能正在占用旧版本的部分文件，导致卸载时无法释放。
• 卸载上下文冲突：单独卸载时旧版本卸载程序是独立进程，无外部资源竞争；但升级场景下，卸载动作是由新版本安装程序触发的，二者可能共享系统资源（如注册表项、临时目录），引发锁冲突导致UI阻塞或崩溃。
• 自定义资源的清理盲区：旧版本的自定义资源（cmd脚本、Spring Boot应用）运行后可能生成了未纳入卸载范围的内容，比如注册的系统服务、新增的配置文件、后台启动的定时任务等，这些内容在卸载时因无法清理导致流程挂起。
• 版本间卸载逻辑兼容性问题：部分早期版本的卸载程序存在逻辑缺陷（如错误处理缺失、资源释放不彻底），而新版本的升级流程未针对这些旧逻辑做适配，导致调用旧卸载程序时直接崩溃；成功升级的版本可能恰好与旧卸载逻辑兼容。
• 资源复制时机错误：如果升级流程在卸载旧版本前就将新版本的自定义资源复制到目标目录，可能覆盖旧版本卸载程序依赖的关键文件（如卸载脚本、配置项），导致旧卸载程序无法正常执行。

• 对比卸载日志细节：收集成功与失败版本的完整卸载日志，重点排查日志中是否存在文件删除失败、进程终止超时、注册表访问错误等记录，对比不同版本卸载动作的执行顺序、资源释放步骤差异。
• 实时监控进程与资源：使用进程监控工具（如Process Explorer）在升级时跟踪旧版本进程、安装程序进程的句柄占用情况，定位卸载时被锁定的文件或注册表项，确认是否存在未终止的子进程。
• 分步模拟升级流程：先手动执行旧版本卸载，再运行新版本安装，验证是否能正常完成；再模拟升级时的上下文（如相同的工作目录、环境变量、权限）运行旧卸载程序，排查是否因上下文差异导致问题。
• 对比不同版本的卸载逻辑：提取各版本的卸载脚本、程序文件，对比其清理步骤、错误处理机制、资源释放逻辑的差异，重点关注早期版本是否存在特殊的依赖项或未公开的清理流程。
• 隔离卸载资源测试：在升级前先备份旧版本的卸载依赖资源（如卸载cmd脚本、必要的dll文件），将其复制到临时目录后再触发卸载，验证是否因新版本覆盖旧资源导致卸载失败。

内容的提问来源于stack exchange，提问作者Horea