edwardpig

Okay, I figured it out. I used the tool mt.exe to extract the manifest file from both the 'good' binary (the one built on 8/27) and the 'bad' one, and compared them. The manifests are pretty minimal, but the 'good' one specifies a version of 8.0.50608.0 for both Microsoft.VC80.CRT and Microsoft.VC80.MFC. The 'bad' one specifies a version of 8.0.50727.4053. So the upshot is that a Windows update on my build machine indirectly changed the dependencies for my executable, and I had no idea it had happened. Isn't that cool? Better yet is the solution. The Google told me I needed to download and run vcredist_x86.exe on the machine where I want to run the executable. This works; however, I'm not allowed to distribute vcredist with my executable. So all of my users will need to download and run vcredist_x86.exe themselves if they want this executable to work.

Very frustrating problem here. A Windows native executable (.exe) gets created as part of an automated build process, using Visual Studio 2005. It uses 'MFC in a Static Library' and the linker is set to automatically generate a manifest file. The executable produced on 8/27 works as expected, on all machines we test on. However, the executable produced on 9/17 (and all those produced thereafter) do NOT run on our test machines (XP and various flavors of Vista). Attempts to run them from the command line return the message"The system cannot execute the specified program". However, all versions of this binary DO work as expected on my development machine, no matter when they were built. Google tells me that the likeliest cause of the problem is either 1) An incorrect manifest file, or 2) An unfulfilled runtime dependency. However, running Dependency Walker against both a functional and non-functional version of the executable tells me that both versions have identical dependencies. More annoyingly, to the best of my knowledge, NOTHING changed in the source code or on the build machine between the creation of the 'usable' binary on 8/27 and the unusable ones on 9/17 and thereafter. The only difference I can think of is that Windows updates were applied to the build machine in that interval. So --- does anyone know how a Windows update might have modified the build environment to produce this problem, or are there any other ideas as to why this executable suddenly will not run anywhere but on my development box?