Strange VC Linker Error LNK1107 that references link.exe

Question

I am getting a really strange linker error appearing:

link.exe : fatal error LNK1107: invalid or corrupt file: cannot read at 0x270

But this is strange, because usually the error message tells you what object is invalid or corrupt. In other words, typically this error message looks something like this:

myDLL.dll : fatal error LNK1107: ....

However, in this case, the invalid object is the application itself (link.exe) that is running!

I've tried replacing the executable with another copy that I know is valid. Same error.

The command I am running is this:

../vendor/microsoft/msdev80_2005/VC/bin/link.exe /NOLOGO /SUBSYSTEM:CONSOLE /LIB
PATH:../vendor/microsoft/msdev80_2005/VC/atlmfc/lib /LIBPATH:../vendor/microsoft
/msdev80_2005/VC/lib /LIBPATH:../vendor/microsoft/msdev80_2005/VC/PlatformSDK/Li
b /LIBPATH:lib/win32/dbg /OUT:bin/win32/dbg/bugshow.exe Advapi32.lib ws2_32.lib
bugshow/obj/win32/dbg/main.o libA.lib libB.lib libC.lib libD.lib

main.o is getting compiled using the following compiler directive:

../vendor/microsoft/msdev80_2005/VC/bin/cl.exe /nologo /X /w /EHsc -I../vendor/m
icrosoft/msdev80_2005/VC/atlmfc/include -I../vendor/microsoft/msdev80_2005/VC/in
clude -I../vendor/microsoft/msdev80_2005/VC/PlatformSDK/Include /D_WIN32 /DBOOST
_USE_WINDOWS_H /DWIN32_LEAN_AND_MEAN /D_WIN32_WINNT=0x0501 /DBOOST_THREAD_USE_LI
B /DBOOST_ALL_NO_LIB /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Z7
/MTd /c -I../vendor/boost.org/boost/1.45.0/include /Fobugshow/obj/win32/dbg/main.o 
bugshow/main.cpp

Any ideas why link.exe would be failing like this?

UPDATE:

When I add the folder that link.exe resides in to my PATH, and then call link.exe without the path prefix, I get the following error instead:

LINK: fatal error LNK1181: cannot open input file 'link.exe'

Why is link.exe trying so desperately to open itself??!?!

Answer 1

I figured out the problem!

There is a nasty little ENVIRONMENT variable that the MSVC linker uses (described here) on Microsoft's MSDN page. It says:

LINK, if defined, prepends arguments in the command line.

My system had the environment variable LINK defined as STATIC by a recent application I installed. This caused link.exe to interpret the command-line instantiation of itself as follows:

STATIC link.exe /NOLOGO /SUBSYSTEM:CONSOLE ...

In other words, *argv[1] which is usually the first command line parameter, was actually link.exe. It basically bumped all the arguments down by one offset. This in turn caused link.exe to try and interpret itself as its first input file!

Absolutely, unbelievably frustrating and hard to detect problem...