Reputation: 8281
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?
Upvotes: 1
Views: 245
Reputation: 36328
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.)
Upvotes: 2