在进行FreeConsole（）调用之后，Stdout的状态是什么？ [英] What is the state of Stdout after a FreeConsole() call is made?

问题描述

这是对""调用FreeConsole后的控制台错误"的解决方案的后续行动。来自C＃general论坛（他们不会让我包含直接链接）其中stdout必须"重新附加"在发生FreeConsole / AllocConsole后，控制台为
。

为了节省正在运行的进程数，我们的应用程序通过在进程后立即调用FreeConsole来关闭额外的conhost.exe进程启动我们的子进程。在大多数情况下，这一直很好，没有任何副作用，直到最近
，我们发现一些输出写入stdout（通过fprintf（stdout，...）和Fortran Print *，调用）偶尔会结束在我们的进程打开的其他文件的正文中 - 我会发布示例代码但经过一周的测试后，我们有
无法在除生产环境之外的任何地方重现这一点，甚至在那里它只发生了一些我们能够识别的是stdout输出正被写入文件中的大致位于我们当前位于被损坏文件中的位置（有问题的文件）。

是一个ISAM数据库表）。

我很好奇的是，是否有人之前已经看过这个，并且可以提供一些有关正在发生的事情的见解，特别是当调用FreeConsole时stdout会发生什么。  目前我们正在根据一个想法进行操作，可能stdout注定
输出正在某个缓冲区中累积，最终必须从缓冲区中刷新，运行时只是将其转储到最后访问的文件中，但是即使这个想法对我来说似乎有点过于牵强。

我们在Windows Server 2012 R2服务器上看到了问题并且代码是使用Visual Studio 2012编译的。 / p>

此时，我们将不胜感激任何见解/想法/建议。 在此先感谢。

解决方案

2016年11月4日下午5:17，JohnR1251写道：

我很好奇的是，是否有人以前见过这个，并且可以提供一些有关正在发生的事情的见解，特别是当调用FreeConsole时stdout会发生什么。

我的猜测就是这个。 stdout不知道FreeConsole被调用，挂起（现在无效）控制台句柄并继续写入它;它的所有WriteFile调用都失败了。直到，也就是说，内核恰好重复使用现在未使用的数值
作为不相关的文件句柄 - 然后那些WriteFile调用再次开始成功。

This is sort of a follow up to the solution for "Console error after FreeConsole is called" from the C# general forum here (they wont let me include a direct link) where stdout had to be "re-attached" to the console after a FreeConsole/AllocConsole occurs.

To save on the number of processes running, our application closes the extra conhost.exe processes down by calling FreeConsole soon after process startup for our child processes. For the most part this has worked fine with no side effects until recently where we have discovered that some output being written to stdout (via fprintf(stdout,...) and Fortran Print *, calls) has occasionally wound up in the bodies of other files our process has opened - I would post sample code but after a week of testing we have not been able to reproduce this in anything but the production environments, and even there it has only happened a few times.

What we have been able to identify is that the stdout output is being written into the file at roughly the location that we are currently positioned in the file being corrupted (the file in question is an ISAM database table).

What I am curious about is whether anyone has seen this before and can provide some insight into what is happening, especially what happens to stdout when FreeConsole is called.  At the moment we are operating under an idea that maybe the stdout destined output is being accumulated in a buffer somewhere that eventually has to be flushed out of the buffer and the runtime is just dumping it in the last accessed file, but even this idea seems a bit too farfetched to me.

For what it is worth we are seeing the problem on a Windows Server 2012 R2 server and the code is compiled with Visual Studio 2012.

Any insight/ideas/suggestions will be appreciated at this point.  Thanks in advance.

解决方案

On 11/4/2016 5:17 PM, JohnR1251 wrote:

What I am curious about is whether anyone has seen this before and can provide some insight into what is happening, especially what happens to stdout when FreeConsole is called.

My guess would be this. stdout doesn't know that FreeConsole was called, hangs onto the (now invalid) console handle and keeps writing to it; all its WriteFile calls fail. Until, that is, the kernel just happens to reuse the now-unused numerical value for an unrelated file handle - then those WriteFile calls start succeeding again.

这篇关于在进行FreeConsole（）调用之后，Stdout的状态是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！