各位大佬好，我最近在做Windows桌面应用的UI自动化，用的是基于Java的图像识别框架（类似Sikuli），碰到了一个和锁屏解锁强相关的间歇性问题，卡了好几天了，想请大家帮忙分析下根因。

我的自动化执行流程 #

整个脚本的执行步骤如下，其中前几步一直很稳定：

1. 启动并操作初始桌面应用（比如记事本）

   open("notepad.exe")
   window("[CLASS:Notepad]")
   sendKeys("Preparing to lock...")
   sleep(2000)
   

2. 执行锁屏命令：Rundll32.exe user32.dll,LockWorkStation，之后系统会自动解锁会话以继续脚本
3. 等待8秒后，启动目标Java Swing应用

   def jarPath = downloadFileOnAgent("path/to/some/SwingApp.jar")
   open("java -jar ${jarPath}")
   

4. 尝试用图像识别定位Swing应用内的第一个UI元素并操作

遇到的核心问题 #

脚本的失败率大概在3-5%，但只要去掉锁屏解锁的步骤，失败率直接降到0%，这说明问题完全和锁屏解锁后的会话状态挂钩：

• 失败固定发生在步骤4：尝试定位Swing应用内第一个图像元素时，图像搜索超时（已配置10秒等待），抛出NoSuchElementException
• 日志确认：失败案例中Swing应用进程已正常启动，自动化工具也能找到它的主窗口句柄，就是内部元素搜不到
• 失败运行的清理阶段，还会收到初始应用（比如记事本）“未响应”的警告，这在无锁屏的正常运行中完全不会出现

我已经做的排查 #

1. 确认锁屏解锁后Swing应用确实启动成功，主窗口句柄可被识别
2. 验证无锁屏步骤时，整个脚本100%稳定
3. 从日志看，失败时的图像搜索已经等待了足够长的时间（10秒），排除了等待时间不足的问题

想请教下，Windows会话在锁屏解锁后，可能会出现哪些影响UI自动化（尤其是图像识别）的状态变化？为什么会导致Swing应用窗口能被找到，但内部元素无法被图像识别到呢？

内容来源于stack exchange