我已经在Windows-7-64 PC上成功开发了Visual Studio 2015(使用IDE)的WinAPI应用程序。 我通常在发行模式下testing程序。
然后我做了一些编辑来源。 该程序编译和链接没有错误,但程序并没有像我预期的那样,所以我切换到debugging模式,并试图build立和运行。 再次VS编译和链接没有错误,但后来抱怨
“无法启动程序”f:\ dropbox \ blah \ x64 \ Debug \ xxx.exe'。“f:\ dropbox \ blah \ x64 \ Debug \ xxx.exe”不是有效的Win32应用程序“。
我觉得这很奇怪,所以我又回到发布模式,再次尝试 – 程序开始正常。 我做了一些编辑,并重build了几次,但后来VS宣布
“无法启动程序”f:\ dropbox \ blah \ x64 \ Release \ xxx.exe“。”f:\ dropbox \ blah \ x64 \ Release \ xxx.exe“不是有效的Win32应用程序。
我试图干净的一切,重新启动VS,甚至重新启动我的电脑..但都无济于事,我仍然得到完全相同的错误。
编辑:在阅读了类似的报告后,我试着暂停Dropbox同步。 它似乎工作,但只有一次或两次,然后问题返回。 然后,我尝试closures多处理器编译,这似乎已经允许我的程序的版本再次运行。 自从编辑器重新编译运行了许多(50+?)次,没有任何问题 – 但仍然拒绝运行debugging版本。
编辑: FYI我的杀毒软件是微软的安全基础
编辑:调用dumpbin和传递我(非运行debuggingexe)产生以下输出:
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链接,并具有完全相同的症状,即运行在发布模式,但不是在debugging模式。
编辑:在迈克尔伯尔的build议我运行依赖沃克我的(非工作)debuggingexe文件,它报告了这些错误: 然后出于好奇,我想我会看看什么dep-walker说我的(工作)释放EXE,并发现我得到完全相同的错误列表!…更多的search,我发现这个SO问题在哪得出的结论是:“它的要点:正如其他人所说的那样,这个工具现在有点过时了,并且不能在新的操作系统上正常工作,因此请保持睁开眼睛,不要因为错过API-MS -WIN-CORE-COM-L1-1-0.DLL',…问题可能完全在于别处。
编辑:我在下面的图像左侧的select框之间切换debugging和释放模式,我点击绿色的三angular形运行该程序。
编辑:我生成的debuggingexe的映射文件。 这里显示的太大了,但是从以下几行开始
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
77BB8000 .data
这几乎是肯定的问题,你有一个非常大的数据部分。 它的大小与Windows上单个可执行模块的可能性相近。 您可以从这个示例C程序中获得更一致的repro:
unsigned char kaboom[0x7d000000]; int main() { return 0; }
不是一个很好的错误信息顺便说一句,微软没有保留这个角落的错误代码。 可以肯定的是,当你接近0x77BB8000的边缘时,不会重复。 可执行映像必须适合加载器创建的内存映射文件的单个视图,以将代码和数据映射到内存中。 该视图具有2 GB的硬性上限,即使在64位版本的Windows上也是32位进程的基本限制和MMF视图大小限制。
该数据部分可用的空间量因运行而异。 从视图大小减去在地址空间的开始和结束处的非可映射区域以及在32位EXE处理中操作系统DLL(至少ntdll.dll和kernel32.dll)所需的空间。 而且由于ASLR(地址空间布局随机化)而失去的空间,这个数字会发生变化。 和注入的DLL,如反恶意软件和Dropbox使用的DLL。
不能猜测为什么你的数据部分需要这么大。 要求链接器生成一个.map文件,以便得到该部分的细目,大的全局变量应该跳出去。 一定要瞄准x64,所以你有大量的地址空间可用,并使用免费商店(malloc等)来分配大型数组。