我已经在Windows-7-64 PC上的Visual Studio 2015中(使用IDE)成功开发了WinAPI应用程序。我通常在发布模式下测试程序。
然后,我对源进行了一些编辑。该程序进行了编译和链接,没有错误,但是该程序的行为不符合我的预期,因此我切换到Debug模式并尝试构建和运行。再次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,甚至重新启动我的PC ..但无济于事,我仍然遇到完全相同的错误。
编辑:阅读了类似的报告后,我尝试暂停保管箱同步。然后它似乎可以工作,但是只有一次或两次,然后问题再次出现。然后,我尝试关闭多处理器编译,这似乎使程序的发行版再次运行。从那以后,我进行了多次编辑-重建-运行(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
编辑:刚尝试在通过dropbox链接的另一台计算机(windows-10-64)上进行编译生成运行,并且具有完全相同的症状,即在发布模式下运行,但不在调试模式下运行。
编辑:根据迈克尔·伯尔的建议,我在(非工作状态)调试exe上运行了依赖行者,并报告了这些错误:然后出于好奇,我想我会看看dep-walker对我的(工作中)的看法释放exe文件,发现我得到的错误列表完全相同!...经过进一步搜索,我发现了一个SO问题,它的结论是:“它的要旨:正如其他人所说的,该工具现在有点过时了并且无法始终与更新的OS正常运行。因此请睁大眼睛,不要因丢失'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
77BB8000 .data
这是几乎可以肯定的问题,你有一个非常大的数据部分。它的大小可疑地接近Windows上单个可执行模块的大小。您可以从以下示例C程序获得更一致的再现:
unsigned char kaboom[0x7d000000];
int main()
{
return 0;
}
顺便说一句,这不是一个很好的错误消息,Microsoft并未为此情况保留错误代码。并且可以肯定的是,当您以0x77BB8000接近边缘时,它不会很好地重复。可执行映像必须适合装入程序创建的将存储器中映射的代码和数据映射到内存的文件的单个视图。该视图的硬上限为2 GB,这是32位进程的基础,即使在64位版本的Windows上,MMF视图的大小也受到限制。
一次运行到下一次运行,可用于该数据段的空间量有所不同。从视图大小中减去地址空间的开始和结束处的不可映射区域,以及32位EXE进程中操作系统DLL(至少为ntdll.dll和kernel32.dll)所需的空间。还有由于ASLR(地址空间布局随机化)而丢失的空间,该数字会发生变化。以及注入的DLL,例如反恶意软件和Dropbox使用的DLL。
不能猜测为什么您的数据部分需要那么大。要求链接器生成一个.map文件,以便对本节进行细分,应该删除较大的全局变量。确保以x64为目标,因此您有很多可用的地址空间,并使用免费存储(malloc等)分配大数组。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句