x86 AMD64 DLL issue - Visual Studio 2005?

Question

Hello,

I am receiving an error that says "The application was unable to start correctly (0xc000007b). Click OK to close the application." When I attempt to run a program I have compiled with Visual Studio 2005.

When I run the windows program "depends" on this executable, I see a TON of DLLs which are listed as "x86" dlls. These all appear to be OS dll's (located in the c:\windows\system32 directory). "Depends" lists these as red where it describes the architecture, since I am making an AMD64 binary. A few of the DLLs (QT dlls I compiled from source) are listed as AMD64.

I have tried adding "c:\windows\SysWOW64" to my path before "c:\windows\system32" and rebuilding my application. This looks to me like where the 64 bit versions of these DLLs live. This still receives the same failure message. My project is setup to be build as a x64 project. Under my project -> properties -> linker -> advanced -> Target Machine, I have tried both "MachineX64" and "Not Set". Both of these settings result in the same error message at run time when I attempt to run my executable.

I am not very knowledgeable about building software in the windows environment. Most of my experience comes from Linux. To me, this seems like a DLL architecture issue, but I am not certain. Google'ing this error message did not provide me with much useful information. Any help provided would be much appreciated. I just started a new job, and seem like I am having lots and lots of problems when it comes to actually running our code...

Thank you very much for taking the time to read my question,

-Brian J. Stinar-

First of all, thank you very much for providing me feedback.

'set' provides me with the following information which I believe will help answer some of your questions. As I am not intimately familiar with windows system administration, please let me know if there are any other commands you think I should run to provide you with more useful information. The output I believe is relevant from 'set' is below:

LIBVERSION=win64

PROCESSOR_ARCHITECTURE=AMD64

PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel

PROCESSOR_LEVEL=6

PROCESSOR_REVISION=1a05

Under my system properties, I find the following values which I believe will help clarify my situation:

Windows 7

Processor : Intel(R) Xeon(R) CPU W3530 @ 2.80GHz 2.79 GHz

System Type : 64-bit Operating System

I'm not completely sure that I understand the difference between x64 and ia64, but as far as I understand, ia64 is for the itanium class processors, which I do not have. I believe I have a x64 processor. This is according to reading the post on

http://mikedimmick.blogspot.com/2006/03/whats-difference-between-x64-and-ia-64.html

Xeon processors fall into the x64 category. I'm not sure if I understand how AMD64 fits into this though.

Should I have AMD64 DLLs that I am linking to, and should my program be listed of CPU type AMD64 if I actually have an Intel Xeon chip?

Thank you again for your help,

-Brian J. Stinar-

Answer 1

SysWOW64 is where 32-bit DLLs live on a 64-bit system. ('WOW' is 'Windows On Windows,', e.g 32-bit windows DLLs on 64-bit windows, so SysWOW64 is 'Sys'tem folder for Windows On Windows64) Normally, program runtime operation is automatically redirected here by Windows when it detects a 32-bit image on a 64-bit installation.

I agree with Rup - sounds like your image is built for a different architecture than you're running.

Answer 2

Hello,

There were two DLLs that were incorrect. These were :

libifcoremdd.dll libmmdd.dll

I was working with a coworker on this problem today, and he copied them over from a location he knew was good. When I was working earlier with a different coworker, we copied them over from a different location that turned out to be incorrect.

Additionally, if anyone else is having similar problems,

dumpbin /headers DLLName 

will give lots of useful information about the DLLs you are using. I'm not exactly sure what the difference was between these different DLLs (I overwrote the old ones, before I checked them). If I do additional analysis on this issue, I will post the results here. I suspect the DLLs were either x86 or ia64, instead of x64 DLLs like I needed.

What is the best solution for packaging and moving around DLLs like this in the Windows environment? Just copying them to a directory in my path doesn't seem like the best solution.

Thanks a lot everyone!

-Brian J. Stinar-

brian-stinar.blogspot.com