在VS刚刚构建之后,"xxx.exe不是有效的Win32应用程序"

Question

我已经在Windows-7-64 PC上成功开发了Visual Studio 2015中的WinAPI应用程序(使用IDE).我通常在发布模式下测试程序.

然后我对我的来源进行了一些编辑.程序编译和链接没有错误,但程序没有像我预期的那样,所以我切换到调试模式,并尝试构建和运行.再次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

编辑:调用dumpbin并传递我的(非运行的调试exe)产生以下输出:

File Type: EXECUTABLE IMAGE

  Summary

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

编辑:刚尝试在不同的机器上完成编译 - 运行 - 运行(windows-10-64),它通过Dropbox链接并具有完全相同的症状,即在发布模式下运行但不在调试模式下运行.

编辑:根据Michael Burr的建议,我在我的(非工作)调试exe上运行了dependancy walker,它报告了这些错误: 然后出于好奇,我以为我会看看dep-walker对我的(工作)发布exe的说法,发现我得到完全相同的错误列表!...在更多搜索时我发现了这个问题,其中得出的结论是:"它的要点:正如其他人所说的那样,该工具现在有点陈旧,并且在新的操作系统上并不总能正常工作.因此请密切关注并且不要因错过'API-MS而误导-WIN-CORE-COM-L1-1-0.DLL',......问题可能完全在其他地方."

编辑:我从下图中左侧的选择框切换调试和释放模式,然后单击绿色三角形运行程序.

编辑:我生成了调试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程序中获得更一致的repro:

unsigned char kaboom[0x7d000000];

int main()
{
    return 0;
}

不是一个非常好的错误消息btw,微软没有为这个角落案例保留错误代码.当然,当你接近0x77BB8000的边缘时,它不会重复得那么好.可执行映像必须适合加载器创建的内存映射文件的单个视图,以将代码和数据映射到内存中.该视图具有2 GB的硬上限,即使在64位版本的Windows上,也是32位进程的基础和MMF视图大小限制.

可用于该数据部分的空间量因运行而异.从视图大小中减去的是地址空间的开头和结尾处的不可映射区域以及32位EXE进程中操作系统DLL(至少ntdll.dll和kernel32.dll)所需的空间.由于ASLR(地址空间布局随机化)而丢失的空间,这个数字会发生变化.和注入的DLL一样,反恶意软件和Dropbox使用的DLL.

无法猜测为什么您的数据部分需要如此之大.要求链接器生成一个.map文件,以便获得该部分的细分,大型全局变量应该跳出来.确保以x64为目标,以便有大量可用的地址空间,并使用免费存储(malloc等)来分配大型数组.