我需要一些方法来监视桌面应用程序并在它死亡时重新启动它.
最初我假设最好的方法是从Windows服务监视/重启进程,直到我发现Vista Windows服务不应该与桌面交互
我已经看到了几个处理这个问题的问题,但是我看到的每一个答案都涉及到某种被微软劝阻的黑客攻击,可能会在未来的操作系统更新中停止工作.
因此,Windows服务可能不再是一个选项.我可能只是创建一个不同的桌面/控制台应用程序来做到这一点,但这种方式失败了.
在您看来,哪种方式最优雅？
编辑:这既不是恶意软件也不是病毒.需要监控的应用程序是一个可以在嵌入式系统上运行的媒体播放器,即使我试图涵盖所有可能的崩溃情况,我也不会冒着因意外错误而崩溃的风险(不会发生) .这个看门狗只是一个安全措施,万一其他一切都出错了.此外,由于播放器将显示第三方Flash内容,因此增加的优势将是监视资源使用情况,并重新启动播放器,如果说,一些蹩脚的Flash电影开始泄漏内存.
编辑2:我忘了提到,我想要监视/重启的应用程序完全不需要在LocalSystem帐户上运行,也不需要任何管理权限.实际上,我更喜欢它使用当前记录的用户凭据运行.
我试图找出User超组中是否存在特定对象，以便跟踪那些离开的人。
为此，我getChatMember为每个调用Bot API方法User并检查其状态是否为Left或Kicked。但是，我注意到（最近？）我遇到USER_ID_INVALID了许多有效用户的错误，这些用户要么在超组中，要么在过去，然后又离开了。我还确认了那些帐户仍在 Telegram 上处于活动状态。
这是我发送的HTTP请求：
POST https://api.telegram.org/botXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXX/getChatMember HTTP/1.1
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
Content-Length: 46
Host: api.telegram.org
{"chat_id":-0000000000000,"user_id":000000000}
这是我得到的回应：
HTTP/1.1 400 Bad Request
Server: nginx/1.12.2
Date: Fri, 20 Apr 2018 04:17:32 GMT
Content-Type: application/json
Content-Length: 74
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
{"ok":false,"error_code":400,"description":"Bad Request: USER_ID_INVALID"}
无论从哪种角度看，它对我来说都是一个完全有效的要求。而且我还没有找到引发此错误的用户之间的共同模式。
我在这里想念什么？
编辑：正如@sean所指出的那样，让其中一个用户向机器人发送消息会秘密地为该特定用户修复错误。但是我绝对可以确定该用户以前见过，因为这就是我获取其用户ID的方式。是什么原因导致漫游器“忘记”了他，我又如何防止这种情况将来发生？