Running executable from VS2008 crashes with error "Application was unable to start correctly (0x000007b)" x64

Question

This error is present in both Debug/Release.

So the original problem was that it had 32 bit library that I did not link to 64 version of it. (Previous version of this question) I fixed that.

And application works on Windows Server Standard 2008R2 x64.

I tried running application on Windows Server Enterprise but got above (title) mentioned error message.

Dependency walker says "Modules with different CPU types were found" and for some reason it seems its linking incorrectly to 32 bit library, but thats something that comes from mshtml.dll (win lib) and it links to winsxs\x86.. folder to COMCTL32.dll, but that lib is in System32 folder (correct one ) so not sure why is it linking to this one

Any ideas???

Answer 1

I tried re-installing Visual C++ redistributable but no help.

Which one - the one that came with your installed and patched VC compiler, or did you download it from the net? Did you install the 32 bit redist or the 64 bit - they are seperate installs, ie 64 bit redist doesn't include 32 bit redist files.

Modules with different CPU types were found

yes, you have to match the CPU type, all 32 bit or all 64 bit.

Given the IESHIMS gives the impression working on a browser plugin

• If your making a Browser Helper Object (BHO - IE addon-on/extension) then you need to register seperately 32 & 64 bit, but if your connecting to ie as an external server then you just need to make sure you have the right one to match the rest of your app.
• If your making a FF plug-in then don't forget to add the mozilla directory to the search path for depends, and when you make changes don't forget you have to reset the firefox plugin cache to try and load the plug-in again (change the folder name, start FF, then change the name back)

%ProgramFiles%/Internet Explorer to System32.

So that would be the 64bit ie dll, to the ??/System32

I'd recommend removing any of the dlls you have added to system32, that way leads to dll hell.