Building a correctly linked executable to avoid error 0xc000007b

2
votes

I am building a 32-bit executable with VS 2012's default build settings. It works correctly on one 64-bit computer (development machine); on another 64-bit computer, the program crashes with error 0xc000007b.

A bit of study and using a dependency walker indicates the problem is that the executable is loading 64-bit dlls rather than 32-bit dlls.

I am reasonably sure that this is solvable by configuring the build to statically link required code rather than calling out to the DLLs.

1). Is this solution a reasonably correct and portable solution?

2). How do I configure VS 2012 to link statically as above?

N.b: this is a C++ native program.

1
windowsvisual-studio-201232bit-64bit
A 64-bit DLL doesn't fall from the sky. You'll need to be explicit about where it came from and why that machine doesn't have a 32-bit version of that DLL. – Hans Passant
Provided that everything (except the OS itself, of course) is linked statically, that is indeed a correct and portable solution. However, if you need to link to third-party DLLs, which themselves depend on dynamically linking the runtime library, then this approach won't work. In that case, you'll need to install the right version of the runtime library on the target machine. – Harry Johnston
@HarryJohnston: Not actually a problem in my specific case. But that's good to know for the next person to have this problem! – Paul Nathan

1 Answers

0
votes

While this is not per se the answer to the "reasonably correct and portable" question #1 above, the answer to #2 I found from How do I make a fully statically linked .exe with Visual Studio Express 2005?. If the compiler /MD option is changed to /MT, it switches from linking in the DLL to linking it in statically and the problem goes away[1].

[1]. Just because the problem goes away doesn't mean it's solved.