我请求您耐心等待这个问题中缺少代码片段及其模糊性，但我完全不知道，我对错误的位置没有任何线索，而且我无法粘贴整个应用程序。
我有一个跨平台的应用程序，它通过普通的CAPI(fopen等)打开一个文件，在一致的时间内写入一些数据(首先将缓冲区传递给zlib以使其放气，但我认为这不相关)，最后刷新并关闭它
这在所有平台上都能很好地工作，除了在打开UAC的Windows OS x64上构建的64位版本。基本上，在这种精确的设置中，在打开文件和刷新文件之间，文件缓冲区似乎与我发送给stdout的内容交错，就好像对stdout的任何写入都使用了另一个文件的相同缓冲区一样。
需要注意的是，这不应该与任何文件系统虚拟化(VirtualStore机制)有关，正如我在%USERPROFILE%Saved Games中所写的那样。这个问题肯定与UAC有关，因为如果我关闭它，问题就不会发生。wine64也没有问题。
任何指针都是有价值的。编译器是g++4.7.0(从linux进行交叉编译)。
我找到了解决这个问题的方法。
第一个障碍是我用-mwindows编译了我的应用程序，这阻止了我的程序连接到父进程控制台。但切换到-mconsole并没有解决问题。即使有了这个更改，我发送到stdout的所有内容也没有发送到控制台。我没有在问题中说明这个问题，因为这不是什么大事，应用程序中有另一种控制台
我确信，整个问题是由于msvcrt中的一些错误(或一些记录非常差的行为变化)造成的。基本上，当我的应用程序启动时，stdout是一个有效的指针，但它并没有真正连接到父控制台。我必须做一个freopen( "CON", "wt", stdout );才能看到输出。此外，没有UAC的fileno(stdout)正确返回1，但在UAC打开的情况下，stdout仍然是一个有效的指针，但对fileno(stdout)的调用返回-1！我想知道stdout在第二种情况下到底指向哪里。
值得注意的是，当使用-mwindows进行编译时，fileno(stdout)返回3！我不知道POSIX标准是否要求stdout的文件描述符编号为1，但选择3至少是不寻常的。