Winapi 枚举服务上的窗口句柄（从服务创建）以确定其标题

我有一个服务需要运行一个应用程序（我们称之为X），该应用程序在tern中使用Excel自动化

在自动化Excel时，应用程序X通常会让Excel显示一个对话框。对话框显示的内容和原因并不重要，不幸的是，这超出了我的控制范围

我只是希望能够在Excel中关闭该对话框

当代码不是作为服务运行时，这当然很容易做到。问题是，在枚举窗口以确定对话框是否启动时，任何win32窗口调用都会返回0作为句柄。我理解为什么这是因为服务是独立运行的，并且预期结果为0

该服务也不可能在启用交互式桌面的本地系统下运行

我希望在Excel进程的线程上使用GetThreadDesktop，然后打开该桌面来枚举这些窗口，但是api在从服务运行时也返回0

关于这一点有很多问题，但是大多数问题都是关于希望显示来自服务的对话框以进行用户交互。我不想那样做。只需找到并关闭一个对话框

有人发现有一个聪明的解决方法可以枚举窗口并返回标题吗

注:

• 应用程序X超出了我的控制范围
• 我知道在非交互式环境中不支持办公自动化
• 无论如何，我都不会尝试与登录用户的桌面进行交互

---

我能想到一些变通办法——我从来没有尝试过，我也不能确定它们是否真的有效

从该服务创建您自己的桌面。使用CreateProcess运行应用程序X，并使其使用新创建的桌面。你可能会觉得有用

创建一个小的可执行文件来处理对话框。创建将运行可执行文件的任务（在任务计划程序中）。让任务存储Excel运行时使用的凭据，以便可以访问该桌面。然后，让服务通过运行任务。以这种方式运行时，小型可执行文件将不会在系统上下文中执行，而是在已定义用户的上下文中执行

安装，它将允许您在Excel的进程中运行。从那里，你就知道该怎么做了。我怀疑这在您的场景中是否会起作用，这只是一种轻微的黑客行为，但您可以尝试一下

这很难看，但可能有用：创建一个小的可执行文件，在“真实”桌面上作为常规的exe运行。让该可执行文件与X交互——两者都在同一个桌面上，应该没有问题。最困难的部分是让您的服务与可执行文件交互。这可以通过非常原始的方式完成，例如文件或套接字。例如，让他们监视某个文件夹，并在文件中传递命令和信息。这显然既不健壮也不优雅，但在某些情况下可能就足够了

再说一次，我不确定这些方法是否有效。你试图绕过的障碍是有设计的

---

哦，我很同情你，不得不处理办公室自动化。。。花了太多的时间试图解决自动化Word的奇怪问题

我过去曾尝试过这一点，并得出结论，从一项服务中实现成功的办公自动化实际上是不可能的。

谢谢-不幸的是，我需要找到某种解决方法。如果您找到了，请告诉我。我们得出的结论是，Excel必须从交互式桌面自动运行。您是否会怀疑这是因为Windows服务不打算与用户交互？上次我使用Excel时，它与用户的交互非常好；经过多次原型设计后，我认为我不会在MS堵塞的安全漏洞周围找到好的。@僵化的权限，好的，MS do office不是为在服务器/服务环境中实现自动化而设计的。。。我已经添加了第四个选项，这在我看来很难看，但可能是最后的选择。使用常规应用程序。大多数编写Windows服务的人都做得不对。这个问题就是一个很好的例子。