VS刚刚构建了“xxx.exe不是有效的Win32应用程序”

Question

我已经在我的Windows-7-64 PC上成功地在visual studio 2015（使用IDE）中开发了WinAPI应用程序。我通常在发布模式下测试该程序。

然后我对我的源代码进行了一些编辑。程序编译和链接没有错误，但程序的行为并不像我预期的那样，所以我切换到调试模式并尝试构建和运行。再次VS编译和链接没有错误，但随后投诉

“无法启动程序'f:\dropbox\blah\x64\Debug\xxx.exe'。'f:\dropbox\blah\x64\Debug\xxx.exe'不是有效的Win32应用程序。”。

我觉得这很奇怪，所以我回到释放模式，再试一次——程序开始时很好。我做了一些编辑并重新构建了几次，但是后来VS声明

“无法启动程序'f:\dropbox\blah\x64\Release\xxx.exe'。'f:\dropbox\blah\x64\Release\xxx.exe'不是有效的Win32应用程序。”。

我尝试清理所有，重启VS，甚至重启我的电脑...

编辑：在阅读了类似的报告后，我尝试暂停dropbox同步。然后它似乎起了作用，但只有一两次，然后问题又出现了。然后我尝试关闭多处理器编译，这似乎让我的程序的发行版再次运行。从那以后，我跑了很多（50？）多次没有问题-但它仍然拒绝运行调试版本。

编辑：仅供参考，我的防病毒软件是Microsoft Security Essentials

EDIT：调用Dumpbin并传递my（非运行调试exe）会产生以下输出：

File Type: EXECUTABLE IMAGE

  Summary

        1000 .00cfg
    77BB8000 .data
        1000 .gfids
        4000 .idata
        4000 .pdata
       31000 .rdata
        4000 .reloc
        1000 .rsrc
       DD000 .text

编辑：刚刚尝试在通过dropbox链接的另一台计算机（windows-10-64）上编译构建运行，并且具有完全相同的症状，即在发布模式下运行，但不在调试模式下运行。

编辑：我为调试exe生成了映射文件。它太大了，无法在这里显示，但它从以下几行开始。。。

 Timestamp is 5811bed3 (Thu Oct 27 09:46:11 2016)

 Preferred load address is 0000000140000000

 Start         Length     Name                   Class
 0001:00000000 00002840H .text$di                CODE
 0001:00002840 000da860H .text$mn                CODE
 0001:000dd0a0 00001020H .text$mn$00             CODE
 0001:000de0c0 00001eb0H .text$x                 CODE
 0001:000dff70 0000104bH .text$yd                CODE
 0002:00000000 00000110H .CRT$XCA                DATA
 0002:00000110 00000110H .CRT$XCAA               DATA
 0002:00000220 00000110H .CRT$XCL                DATA
 0002:00000330 00000128H .CRT$XCU                DATA
 0002:00000458 00000110H .CRT$XCZ                DATA
 0002:00000568 00000110H .CRT$XIA                DATA
 0002:00000678 00000110H .CRT$XIAA               DATA
 0002:00000788 00000110H .CRT$XIAC               DATA
 0002:00000898 00000110H .CRT$XIZ                DATA
 0002:000009a8 00000110H .CRT$XPA                DATA
 0002:00000ab8 00000110H .CRT$XPZ                DATA
 0002:00000bc8 00000110H .CRT$XTA                DATA
 0002:00000cd8 00000118H .CRT$XTZ                DATA
 0002:00000df0 0002c960H .rdata                  DATA
 0002:0002d750 00000998H .rdata$r                DATA
 0002:0002e0e8 00000178H .rdata$zzzdbg           DATA
 0002:0002e260 00000110H .rtc$IAA                DATA
 0002:0002e370 00000188H .rtc$IMZ                DATA
 0002:0002e4f8 00000110H .rtc$IZZ                DATA
 0002:0002e608 00000110H .rtc$TAA                DATA
 0002:0002e718 00000188H .rtc$TMZ                DATA
 0002:0002e8a0 00000110H .rtc$TZZ                DATA
 0002:0002e9b0 00003b68H .xdata                  DATA
 0002:00032518 00000275H .xdata$x                DATA
 0002:0003278d 00000000H .edata                  DATA
 0003:00000000 000023e0H .data                   DATA
 0003:000023e0 00000580H .data$r                 DATA
 0003:00002960 77376001H .bss                    DATA
 0004:00000000 0000369cH .pdata                  DATA
 0005:00000000 00000ed0H .idata$5                DATA
 0005:00000ed0 000000c8H .idata$2                DATA
 0005:00000f98 00000018H .idata$3                DATA
 0005:00000fb0 00000ed0H .idata$4                DATA
 0005:00001e80 00001fc6H .idata$6                DATA
 0006:00000000 0000015eH .gfids$y                DATA
 0007:00000000 0000011bH .00cfg                  DATA
 0008:00000000 00000170H .rsrc$01                DATA
 0008:00000170 000002ccH .rsrc$02                DATA

  Address         Publics by Value              Rva+Base               Lib:Object

 0000:00000000       __guard_iat_table          0000000000000000     <absolute>
 0000:00000000       __guard_longjmp_count      0000000000000000     <absolute>
 0000:00000000       __guard_longjmp_table      0000000000000000     <absolute>
 0000:00000000       __guard_fids_count         0000000000000000     <absolute>
 0000:00000000       ___safe_se_handler_table   0000000000000000     <absolute>
 0000:00000000       ___safe_se_handler_count   0000000000000000     <absolute>
 0000:00000000       __guard_iat_count          0000000000000000     <absolute>
 0000:00000000       __guard_fids_table         0000000000000000     <absolute>
 0000:00000000       __dynamic_value_reloc_table 0000000000000000     <absolute>
 0000:00000100       __guard_flags              0000000000000100     <absolute>
 0000:00000000       __ImageBase                0000000140000000     <linker-defined>
 0001:00002aa0       ?readstring@@YAXPEAD0@Z    0000000140003aa0 f   COMMAND.obj
 0001:00002b70       ?make_phere@@YAXH@Z        0000000140003b70 f   COMMAND.obj
 0001:00002c50       ?load_snap@@YAXXZ          0000000140003c50 f   COMMAND.obj
 0001:00002d30       ?i_rand_0_n_inclusive@@YAHH@Z 0000000140003d30 f   COMMAND.obj

Answer 1

  77BB8000 .data

这几乎可以肯定是问题所在，您有一个非常大的数据部分。它的大小可疑地接近Windows上单个可执行模块的大小。您可以从这个示例C程序中获得更一致的复制：

unsigned char kaboom[0x7d000000];

int main()
{
    return 0;
}

不是一个很好的错误消息顺便说一句，微软没有保留一个错误代码为这个角落的情况。当然，当您使用0x77BB8000接近边缘时，它不会很好地重复。可执行映像必须适合加载程序创建的内存映射文件的单个视图，以便将代码和数据映射到内存中。视图的硬上限为2G字节，这是32位进程的基本要求，即使在64位版本的Windows上，MMF视图大小也有限制。

该数据段可用的空间量因运行而异。从视图大小中减去地址空间开始和结束处的不可映射区域以及32位EXE进程中操作系统DLL（至少ntdll.dll和kernel32.dll）所需的空间。以及由于ASLR（地址空间布局随机化）而丢失的空间，这是一个会改变的数字。以及被注入的DLL，如反恶意软件和Dropbox使用的DLL。

无法猜测为什么您的数据部分需要如此大。请链接器生成一个链接。映射文件，这样您就可以得到一个细分的部分，大的全局变量应该跳出。请确保以x64为目标，以便有大量可用的地址空间，并使用免费存储（malloc等）分配大型阵列。