[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 618
  • Last Modified:

Problem running a C++ application developed with a 32-bit Windows XP system, on a 64-bit Windows XP system. Error: (0xc000007b).

We're currently having a problem with a C++ application developed in Visual Studio 6 on a 32-bit version of Windows XP Professional. We've previously tested the application on two 32-bit versions of Windows XP Professional, and both tests have been successful so far. We're now trying to perform the test on a 64-bit version of Windows XP Professional and receiving the following message:

The application failed to initialize properly (0xc000007b). Click on OK to terminate the application.

Any help with regards to this error would be greatly appreciated. If any further information is required to fix this problem, just ask.

Thank you very much,
Adam Pollock.
Encoded, Ltd.
0
encoded66
Asked:
encoded66
  • 6
  • 4
  • 3
1 Solution
 
AxterCommented:
Have you tried running it via debug mode, and checked were it's failing in the code?
0
 
encoded66Author Commented:
We have indeed. Exactly the same thing happens. It's as if the application itself isn't actually being run, in so much as it's failing during the initilisation stages of loading the application.
0
 
jkrCommented:
The error is

# for hex 0xc000007b / decimal -1073741701 :
  STATUS_INVALID_IMAGE_FORMAT
# {Bad Image}
# The application or DLL %hs is not a valid Windows image.
# Please check this against your installation diskette.

IOW: The binary is corrupt.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
AxterCommented:
That more then likely means that the application has not been built against the correct 64bit environment.
Is this an AMD64 machine or a IA64 machine?
What are you using for your build option?  Is it /MACHINE:IA64 or /MACHINE:AMD64
0
 
encoded66Author Commented:
We've managed to eliminate a corrupt binary by hosting the file externally and attempting to run it over the network from both a 32-bit machine and a 64-bit machine. It runs perfectly from the 32-bit machine, but fails in the same way from the 64-bit machine.

This couldilluminate a possible issue though, in that the 64-bit version of Windows doesn't view it as a valid binary?
0
 
encoded66Author Commented:
Axter:

We're compiling it as a 32 bit application, and assuming that the 64-bit version of windows will just perform all of its emulation wizardry for us? Is this incorrect?
0
 
jkrCommented:
>>that the 64-bit version of Windows doesn't view it as a valid binary?

Actually, that would be the WOW64 subsystem, which does not ditinguish between IA64 or AMD64, since it is 32bit. Are you using any special processor features that might not be available on WOW64?
0
 
encoded66Author Commented:
>> Are you using any special processor features that might not be available on WOW64?

Not that we're aware of. Project options, etc, have pretty much been left at default as much as possible. As we haven't changed anything regarding processor features, I would assume that we, hopefully, would not be using anything "unusual" that would not be supported.
0
 
jkrCommented:
0
 
jkrCommented:
0
 
AxterCommented:
I recommend you check all the dependencies your binary has, and validate that they all have 32bit compatible DLL's on that test machine.
You can use Dependency Walker to do this, which is a free tool you can download from the following site:
http://www.dependencywalker.com/
0
 
encoded66Author Commented:
I've had a quick read of the "Running 32-bit Applications" page, which seemed to point mostly on to 404 pages. I've read the "Best Practises for WOW64" and it seems like we are not doing anything that would cause problems.

I'm going to check that all dependant DLL's have a 32-bit compatible version, and then report my findings here soon.
0
 
encoded66Author Commented:
Dependancy Walker quickly showed that the problem lied with a DLL being called deep within the depths of the application that did not have a 32-bit compatible version.

Thank you very much for all your help.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now