VS2008 在 Windows7 Beta7000下编译出错-The binary is not a valid Windows image.
更新：新装的7048 x64没出现这个问题了，原因还不知道
前些天装上了Windows7 Beta7000x86，却发现原先的项目编译会出现链接错误：
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "". The binary is not a valid Windows image.
是mt.exe在嵌入manifest文件的时候遇到错误，从网上找到的解决方案，是在链接器设置选项中，启用Randomized Ba Address ，如下图：
订婚仪式
原因：
男生阳光头像
john robbins' blog
Saturday, January 24, 2009 5:48 PM jrobbins
The Ca of the Corrupt PE Binaries
After installing Windows 7, I also installed the Windows 7 SDK as I wanted to poke around the updated headers and documentation fil
es to e what was new at a low level. Additionally, I wanted to make sure all my code compiled against the new headers and libraries in ca someone taking my native debugging class tried it and ran into problems. After many years of the SDK team completely ignoring Visual Studio, the Windows 7 SDK installation now looks for Visual Studio and properly integrates with it (I believe this started with the Vista SDK). After hundreds of thousands of emails over the years from people who couldn't compile code from my books and columns becau they hadn't gone through the manual gyrations to integrate the latest SDK with the development environment, it's a huge help.
As I have all my builds automated, I let rip and got a build failure on a few relea build x86 and x64 binaries. The failure was like the following in all tho cas:
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "..\..\..\..\". The binary is not a valid Windows image.
宽宏大度MT.EXE is the tool ud to embed the manifest into your binaries.
As I was running a beta OS, I wondered if this was a problem with anti-virus, so I disabled eTrust and tried the build again but still got the same error.
As I'm using Visual Studio 2008 SP1, CL.EXE and LINK.EXE are doing all the main work of compiling, but MT.EXE comes from the SDK. Since this code compiled correctly on my Vista computer with the Vista SDK installed, my next step was to e if this was possibly a problem with MT.EXE or if CL.EXE and LINK.EXE were exposing a bug in the operating system DLLs they were using. I uninstalled the Windows 7 SDK, which reverted Visual Studio 2008 SP1 to using the Vi
列竖式计算题sta SDK. Giving the recompiles a go, I got the same error from MT.EXE. I verified that I was in fact using the MT.EXE from the Vista SDK. One thing that was confusing to me was that MT.EXE from the Vista SDK and Windows 7 SDK both report the same version number, but the binaries are different sizes.
Looking clor at what binaries were getting corrupt, it was only four out of 56 .EXE files in my build. Interestingly, they were all console applications that were unit tests. Firing up Visual Studio, I created the canonical test console application, Hello World, and verified that it compiled. Looking at the BUILD.HTM file, I saw that Hello World had the following in it:
Creating command line "mt.exe @c:\Junk\cruft\HelloWorld\Relea\RSP00000840485968.rsp /nologo"
Creating temporary file "c:\Junk\cruft\HelloWorld\Relea\BAT000
00940485968.bat" with contents
[
@echo Manifest resource last updated at %TIME% on %DATE% > .\Relea\mt.dep
]
For two conds, I was a little confud about the temporary file creation becau my failing builds didn't have that. What the output told me was that the temporary file indicating MT.EXE creates the resource update time file after it runs successfully.
My hypothesis at this point was that either LINK.EXE was creating a corrupt binary before MT.EXE worked on it, or it was MT.EXE corrupting the binary itlf. Using one of my projects that produced a corrupt binary, I copied out the command lines for CL.EXE, LINK.EXE, and MT.EXE from its BUILD.HTM and ran them directly 电脑如何设置
from a batch file at the command line (properly t up with VCVARS.BAT). I wanted to look at what was in the Portable Executable (PE) data to e if anything was amiss. By the way, you need to read Matt Pietrek's definitive "An In-Depth Look into the Win32 Portable Executable File Format" Parts 1 and Part 2 you'll learn a ton about how Windows works.
Running DUMPBIN.EXE /headers on the resulting EXE allowed me to look at the main portions. Becau MT.EXE puts the manifest into the resource ction of the binary, I paid special attention to it:
SECTION HEADER #4
.rsrc name
0 virtual size
4000 virtual address (00404000 to 00403FFF)
0 size of raw data
村民自治
激烈的竞争 0 file pointer to raw data
0 file pointer to relocation table
郭沫若的作品 0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
Do you e the problem? Here's a good resource ction for comparison:
SECTION HEADER #4
.rsrc name
2B0 virtual size
4000 virtual address (00404000 to 004042AF)
400 size of raw data
1800 file pointer to raw data (00001800 to 00001BFF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
Read Only
