1
votes

I have a 32 bit C++ executable on a shared network drive. I have a bunch of 64 bit Windows 7 Professional PC's on this network. Some of them run my program just fine, others produce the "The application was unable to start correctly (0xc000007b)" error.

After reading the SO question The application was unable to start correctly (0xc000007b) and others like it I installed Dependency Walker.

Dependency Walker identified 2 DLL's - MSVCP120D.Dll and MSVCR120D.DLL - as 64 bit in the dependency tree. But both DLL's are in the same directory as the executable. (So why does the program run on any PC?!) Running dumpbin with the /headers option confirmed they were 64 bit.

These DLL's are distributed with Visual Studio 2013 so I copied new ones from there to my folder. Dumpbin /headers identifies the new ones as "1C4" not x64 like the previous ones. Dependency Walker no longer flags them as 64 bit but it still says "Modules with different CPU types were found" and in the detailed break out for those DLL's it flags them in red as "452", not x86. The program still fails with (0xc000007b) on the same PC's.

What is a 452 (= hex 1C4) CPU and how do I get true x86 versions of these DLLs?

1
Delete the DLLs from the program directory and run the Visual C++ Redistributable Runtime package from the MS website.Ben Voigt
@ Ben Voigt OK I did that. The Redistributable Package reported "Setup Successful" I deleted all the local DLL's staring with "ms" - there are other DLL's specific to the application. I'm still getting the 7B error on the same machines. It IS true that the machines where it runs without problems are all ones where Visual Studio has been installed in the past.user316117
@Hans Passant - Sorry, but it's not a typo. It really does say 1C4 and Dependency Walker says 452 (which is decimal for 1C4 in hex). I have a vague recollection that this is code for an ARM processor but I can't find any confirmation on the web and I don't know why there should be ARM DLL's on my PC.user316117
The most important thing is what Hans said - "don't deploy debug builds". If the executable is loading any DLLs that end in a D, you've built it wrong. (But, well, it might not actually be illegal if you're only using it in-house.)Harry Johnston

1 Answers

2
votes

Machine type code 0x1C4 is ARM. There is a table in this answer.

I haven't been able to find any confirming documentation on Microsoft's site, but I can confirm that the ARM binaries in Visual Studio 2013 have machine type 0x1C4.

(As to how you wound up with them: they're the first ones you'll find if you search the Visual Studio folder in Program Files, because "ARM" sorts before either "x64" or "x86". My guess is you simply didn't notice that there was more than one platform available.)