我可以向Windows上的应用程序发送ctrl-C(SIGINT)吗？

Question

我可以向Windows上的应用程序发送ctrl-C(SIGINT)吗？我(在过去)编写了跨平台(windows/unix)应用程序，当从命令行启动时，这些应用程序处理用户类型的应用程序。克特-C以同样的方式组合(即干净地终止应用程序)。是否可以在Windows上发送克特-C/SIGINT/等效于来自另一个(不相关)进程的进程，请求它干净地终止(给它一个清理资源的机会等等)？

Answer 1

我最近找到的解决方案是SendSignal第三方应用。作者列出了源代码和可执行文件。我已经验证了它在64位窗口下工作(作为32位程序运行，杀死另一个32位程序)，但我还没有弄清楚如何将代码嵌入到windows程序(32位或64位)中。

它是如何运作的：

在深入了解调试器之后，我发现实际执行与ctrl中断等信号相关的行为的入口点是核32！ctrlRoutine。该函数与ThreadProc具有相同的原型，因此可以直接与CreateRemoteThread一起使用，而无需注入代码。然而，这不是一个出口的符号！它位于不同版本的Windows上不同的地址(甚至有不同的名称)。该怎么办？

这是我最后想出的解决办法。我为我的应用程序安装了一个控制台ctrl处理程序，然后为我的应用程序生成一个ctrl中断信号。当调用我的处理程序时，我会回顾堆栈的顶部，找出传递给内核32！BaseThreadStart的参数。我获取第一个Param，它是所需的线程开始地址，它是内核32！CtrlRoutine的地址。然后我从我的处理程序返回，表明我已经处理了信号，我的应用程序不应该被终止。回到主线程中，我将等待内核32！CtrlRoutine的地址被检索。一旦我得到了它，我就在目标进程中创建一个远程线程，并使用已发现的开始地址。这将导致对目标进程中的ctrl处理程序进行评估，就好像ctrl中断已被按下一样！

好的是，只有目标进程受到影响，任何进程(即使是加窗口的进程)都可以成为目标。一个缺点是我的小应用程序不能在批处理文件中使用，因为它会在发送ctrl中断事件时杀死它，以便发现kernel 32！ctrlRoutine的地址。

(在此之前)start如果在批处理文件中运行它。)

Answer 2

我想我在这个问题上有点晚了，但无论如何，我会写一些东西给任何有同样问题的人。这和我给出的答案是一样的这，这个问题。

我的问题是，我希望我的应用程序是一个GUI应用程序，但是执行的进程应该在没有任何交互控制台窗口的背景下运行。我认为当父进程是控制台进程时，这个解决方案也应该有效。但是，您可能必须移除“create_no_Window”标志。

我设法用GenerateConsoleCtrlEvent()使用包装程序。棘手之处在于，文档对于如何使用它以及其中的缺陷并不十分清楚。

我的解决方案是基于所描述的这里..但这并没有真正解释所有的细节和错误，所以下面是如何让它工作的细节。

创建一个新的助手应用程序“Helper.exe”。此应用程序将位于应用程序(父进程)和您希望关闭的子进程之间。它还将创建实际的子进程。必须有这个“中间人”进程，否则GenerateConsoleCtrlEvent()将失败。

使用某种IPC机制从父进程到助手进程进行通信，帮助进程应该关闭子进程。当帮助程序获得此事件时，它调用“GenerateConsoleCtrlEvent(CTRL_Break，0)”，该事件关闭自身和子进程。为此，我自己使用了一个事件对象，当父进程想要取消子进程时，它将完成该事件对象。

若要创建Helper.exe，请使用create_no_Window和create_new_process_group创建它。当创建子进程时，创建它时没有标志(0)，这意味着它将从其父进程派生控制台。如果不这样做，将导致它忽略事件。

非常重要的是，每一步都是这样做的。我一直在尝试各种不同的组合，但这种组合是唯一起作用的组合。您不能发送CTRL_C事件。它将返回成功，但将被忽略的过程。Ctrl_Break是唯一起作用的。这并不重要，因为它们最终都将调用ExitProcess()。

您也不能使用子进程id的进程组id调用GenerateConsoleCtrlEvent()，从而允许助手进程继续运行。这也会失败。

我花了一整天的时间想让这件事奏效。这个解决方案对我有效，但如果任何人有任何补充，请做。我在网上到处搜索，发现很多人都有类似的问题，但对这个问题没有明确的解决办法。GenerateConsoleCtrlEvent()的工作方式也有点奇怪，所以如果有人知道更多关于它的细节，请分享。