SendKeys VBScript方法的操作系统限制及升级后冻结问题咨询

嘿，我确实碰到过不少开发者在从Windows XP迁移到Windows Server 2012 R2这类较新系统时，遇到SendKeys脚本冻结的情况——这背后确实和SendKeys依赖的操作系统特性变化直接相关。

核心原因分析 #

SendKeys是一个依赖系统桌面交互的老旧API，Windows XP之后的系统在会话管理、权限控制和窗口渲染上做了不少改动，直接导致了兼容性问题：

• 会话0隔离机制：Windows Server 2008及以后（包括2012 R2）默认启用会话0隔离，服务进程和用户交互进程被分隔在不同会话中。如果你的Cimplicity脚本是作为服务运行，或者在会话0中执行，SendKeys无法找到可交互的用户桌面，就会陷入无限等待状态；而Windows XP没有这个隔离限制，所以之前能正常工作。
• UAC权限隔离：Server 2012 R2的UAC权限管控远严格于XP。如果脚本（比如wscript.exe）和Cimplicity进程的权限级别不一致（一个是管理员，一个是普通用户），SendKeys的按键发送请求会被系统拦截，进而导致脚本冻结。
• DWM窗口合成影响：Windows 7及以后系统使用桌面窗口管理器（DWM）进行窗口渲染，SendKeys依赖传统的GDI窗口消息机制，DWM的合成模式可能会干扰按键消息的传递逻辑，引发死锁或等待。

可行的解决方案 #

针对这些问题，你可以尝试以下几种方法：

• 调整会话与服务设置：如果Cimplicity是作为服务运行，修改服务的“登录”属性，选择一个有桌面交互权限的用户账户，并勾选“允许服务与桌面交互”；或者直接在用户登录会话中启动脚本，避免在会话0中执行。
• 统一权限级别：确保脚本和Cimplicity进程运行在相同的权限环境下——要么都用普通用户账户启动，要么都以管理员权限启动（但尽量优先使用普通用户，减少UAC干扰）。
• 替换SendKeys为更可靠的方法：
  • 尝试使用SendInput API替代SendKeys，这是Windows提供的更现代、更稳定的输入模拟接口，VBScript可以通过WSH调用Windows API实现（需要编写少量扩展代码）。
  • 优先使用Cimplicity 10的原生API：作为新版本的SCADA系统，Cimplicity 10大概率提供了控制界面标签切换的内置函数，完全不需要依赖模拟按键——建议查阅Cimplicity的SDK或官方文档，找到原生的标签切换方法，这才是最稳定的长期方案。
  • 借助第三方工具：比如用AutoHotkey编写按键模拟脚本，编译成可执行文件后由VBScript调用，AutoHotkey对新系统的兼容性比原生SendKeys好得多。
• 调试冻结状态：用Process Explorer查看脚本进程（wscript.exe或cscript.exe）的线程状态，确认是否卡在某个系统调用上，帮助定位具体是会话、权限还是窗口渲染导致的问题。

总的来说，SendKeys本身就是一个脆弱的工具，依赖太多系统环境变量，跨版本迁移时很容易出问题。优先用原生系统或应用API替代，才是避免这类问题的最佳途径。

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