Windows服务中如何检测当前活动桌面（OpenInputDesktop调用失效）

OpenInputDesktop在SYSTEM服务上下文调用失效是Windows Session 0隔离机制的正常表现：

• Vista及之后版本，所有SYSTEM权限服务默认运行在独立的Session 0，登录用户的交互式会话从Session 1开始分配，不同会话的窗口站、桌面对象、句柄表完全隔离，跨会话直接调用桌面操作API无法拿到有效句柄。
• 你最初靠识别活动桌面类型判断用户状态的思路方向没问题，但调用上下文、检测方式选错了，不需要自己轮询桌面状态。

1. 会话状态检测 #

放弃轮询桌面的实现，直接调用系统原生的会话通知接口：

• 服务启动后调用WTSRegisterSessionNotification，传入NOTIFY_FOR_ALL_SESSIONS标记，注册全会话状态通知，可直接收到精准的事件回调：
  • WTS_SESSION_LOGOFF：对应用户注销事件
  • WTS_SESSION_LOGON：对应用户登录完成、交互桌面就绪事件
    不需要自己判断当前桌面是Default、ScreenSaver还是Winlogon，系统通知的状态100%准确。

2. 交互应用启动 #

收到对应会话的WTS_SESSION_LOGON事件后，不要直接在服务线程里启动应用，按以下流程操作：

• 从事件参数中提取目标会话ID，调用WTSQueryUserToken获取该会话下用户的主访问令牌（该接口仅允许SYSTEM权限上下文调用，和你的服务运行权限匹配）
• 填充STARTUPINFO结构，将lpDesktop字段明确设为winsta0\default
• 调用CreateProcessAsUser，传入拿到的用户令牌、目标应用路径、填充好的启动信息，即可将应用正常启动到用户可见的交互桌面。

3. 业务逻辑落地 #

• 注销后重启逻辑：收到某会话的WTS_SESSION_LOGOFF事件时记录会话ID，后续收到同一会话的WTS_SESSION_LOGON事件时，按上述流程重新启动指定应用即可。
• 应用关闭后服务自停逻辑：CreateProcessAsUser成功启动应用后，会返回目标应用的进程句柄，服务内开独立工作线程调用WaitForSingleObject等待该句柄，一旦等待返回即代表应用已退出，直接调用SetServiceStatus将自身服务状态设为SERVICE_STOPPED，完成自停。

• 不要在Session 0的服务线程中直接操作其他会话的桌面、窗口相关API，所有跨会话交互必须通过用户令牌切换上下文完成。
• 启动交互应用时必须显式设置lpDesktop字段，否则进程会默认启动到Session 0的非交互桌面，用户看不到任何界面。
• 不要通过轮询进程快照的方式检测目标应用是否运行，直接持有启动时返回的进程句柄等待退出，稳定性和性能都远好于轮询。

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