Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
edwardpig

The system cannot execute the specified program

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

That is correct. The item you linked to is a security update to the redistributable package. You cannot redist the update, but you could redist the original package. Is there perhaps a newer version available that already contains that update?

Edit: woops, I saw published date July 09.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×