控制台winevents的正确用法是什么？

Question

在this question的许多机器上“部署”解决方案时，我注意到一些单核机器的结果很糟糕（例如，解决方案在intel原子上失败了。）

这里发生的是以下内容。我调用SetWinEventHook(...)来获取控制台更改的回调。由于上下文通知，事件处理与控制台上的进一步更改之间没有同步，因此虽然多核机器运行良好（不完美顺便说一句），但单核机器却搞不清楚。

所以我继续打开In-Context通知，因为根据msdn这应该是同步的。在c＃中，这就像要求Infinite Improbability Drive一样，所以我在C中创建了一个简单的dll，可以完成脏工作，并从c＃与dll对话。到目前为止一切都很好。

事实证明，回调发生在conhost.exe中，而不是拥有控制台的进程。现在这提出了一个问题，因为在回调中我无法找到在conhost.exe上下文中访问控制台输出缓冲区的方法。或者更确切地说，我似乎无法找到获得它的方法。这是可用的：处理控制台窗口，处理控制台应用程序和conhost.exe的id以及管道控制台应用程序的管道。

这就是我试着做的事情：

1. 使用GetStdHandle(...)会导致无效句柄（在conhost.exe的上下文中有意义）
2. 使用CreateFile("CONOUT$"...)，dito
3. 使用管道从输出缓冲区读取控制台应用程序，导致死锁。我怀疑用于防止写入时的读取的锁定机制，这是有道理的。
4. 复制输出缓冲区句柄并通过管道传递它。没有快乐，因为控制台句柄不能复制到外部进程。
5. 将conhost.exe进程附加到它正在服务的控制台进程的控制台，然后执行CreateFile操作。好的，这是我最喜欢的一个，但它也不起作用AttachConsole(...)块，类似于3。

有人对下一步尝试有什么想法吗？我的c / c ++ / winapi技能最好是中级，所以很有可能我忽略了一些东西。好的显而易见的是将整个事情抛到一边，只是轮询输出缓冲区的变化，但我认为这是最后的选择。我假设MS足够聪明，以确保In Context或Out of Context事件实际上是可用的，因此我必须遗漏一些东西。