Reputation: 648
I'm posting this question here because I've had a lot of trouble when trying to find an answer for it - in particular, all answers on StackOverflow were not fixing the problem.
I have recently upgraded my Visual Studio 2010 32-bit project to compile for x64 as well. The compilation works without problems, but when trying to launch the application, it fails with error code 0xc000007b. Usually this happens when you forgot to upgrade your included DLLs from 32-bit to 64-bit and consequently try loading 32-bit code in your 64-bit application, but in this particular case, I only include DLLs that ship with windows, so WOW should pick the correct DLL version anyway... in theory.
ProcMon indicates that all DLLs are loaded from C:\Windows\System32, which is the correct location for 64-bit plugins. Using Dependency Walker as suggested in this StackOverflow thread is of no help either, as it thinks that all referenced DLLs are 32-bit, probably because DW itself is a 32-bit application, so when it asks for e.g. user32.dll, Windows will pick the version residing in the SysWOW64 folder.
Upvotes: 2
Views: 2892
Reputation: 648
When using a manifest for enabling visual styles on common controls, you must not forget to upgrade the manifest file for your x64 project. It's easy to oversee this issue, as you probably only create your manifest file once and then never touch it again.
Your manifest file might contain a section like this:
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="x86"/>
This makes Windows search for a 32-bit version of the common controls. To fix this issue, you will have to replace all occurences of "x86"
in the manifest file by "amd64"
, or simply "*"
(to make it work on all platforms). Don't forget to create a separate manifest for the 64-bit version of your project if you're not using the "*"
version.
Upvotes: 3