I have a driver I have written in unmanaged C++ using Visual Studio 2010. When compiling the DLL on a 64-bit Windows 7 the post-build step is:
echo Copying $(TargetFileName) to the OS's 64-bit system folder ...
xcopy $(TargetPath) $(SystemRoot)\System32\. /Y /Q
However, the dll is copied to $(SystemRoot)\SysWOW64\ instead, which supposedly only happends to 32-bit assemblies.
BUT! If I copy the dll to System32 using Windows Explorer or with xcopy from a command shell the dll is correctly placed in the System32 folder. What am I doing wrong? Is it because Visual Studio is a 32-bit program and the POST-BUILD event is run in context of that 32-bit process?
Your script is being run from a 32-bit process. As a sort of band-aid solution you should be able to replace system32 with sysnative and the WOW64 layer should do the right thing.
Update: Sorry, maybe this instead: %windir%\sysnative\cmd.exe /C "xcopy ..."
The variable SystemRoot is expanded corresponding to the calling program.
Since the calling program (devenv.exe) is a 32-Bit program it is replaced with the SysWOW64.
Related
I'm' trying to build a C++ application with Visual Studio 2015 using OpenSSL.
The application experiences a 0xC0000007b error with the message "The application was unable to start correctly". Using Dependency walker I saw my application, built as x86, uses the X64 OpenSSL DLL (in System32 instead of SYSWOW64).
How can i force Visual Studio to use the 32-bits DLL?
I just added these two dependencies :
libeay32.lib
ssleay32.lib
And visual studio loads automatically ( or windows ? ) the 64 bits version, which gets me the 0xc0000007b error
Edit : Yeah, the DLL 32-bits are in the SysWow64 too.
Any idea please ?
Thanks a lot :)
You cannot force Visual Studio to automatically find proper libraries for your architecture. Instead of it you should point to it explicitly via Library Path. Use $(PlatformName) there if you have multiple target platforms.
If you compile application as x86 than Windows automatically redirects you to the proper 32 bit system32 folder. But don't rely on it, deploy required OpenSSL dlls locally, into your application folder. If you have multiple target platforms it's also handy to use $PlatformName macros in post-build event. E.g:
copy "$(SolutionDir)3rdParty\OpenSSL\$(PlatformName)\ssleay32.dll" "$(TargetDir)"
copy "$(SolutionDir)3rdParty\OpenSSL\$(PlatformName)\libeay32.dll" "$(TargetDir)"
I've trying to use my 64-bit C++ application into a 32-bit system, but I've encountered some problems with Visual Studio 2008.
I've just downloaded the solution on my 32-bit pc (Microsoft Windows Xp), and set Visual
Studio settings to: Debug|Win32
The compiling phase is alright, but if I try to run the program, the system says:
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: C:\wspace4\BioTesi\BioCpp.dll: %1 is not a valid Win32 application
Somehow the system does not interpret my dll as 32-bit. I think I'm missin' some Visual Studio setting... but which?
How to solve this problem?
Thanks!
Have you set up different build paths for the 32 and 64-bit dlls and exes? It's quite likely you have some 64-bit outputs overwriting the 32-bit ones. Some things to try:
Check out a clean workspace from your version control system so you don't have any unexpected items lying around
Open the Configuration Manager and check that the 32-bit configuration of the solution is actually building the 32-bit versions of each project
Use DependencyWalker which will show the .exe and .dll icons with a '64' overlay if they happen to be 64-bit
I'm trying to do the SDL tutorial here http://lazyfoo.net/SDL_tutorials/lesson03/windows/msvsnet2010e/index.php
I did everything they asked me to do, everything built correctly, but when I tried to run the executable, I always get the error: "application was unable to start correctly 0xc000007b"
I'm using Win7 on a mac (bootcamp), with visual stdio 2010 professional
If you have placed SDL.dll under C:\Windows\system32 or \SysWOW64 like the tutorial says, doing this may work:
Download SDL.dll (Runtime Libraries > Win32, not the 64-bit version*) and place it in the project folder where the .exe file is located.
E.g. if the project location is C:\myproject, place the SDL.dll at C:\myproject\Debug.
Then you can remove SDL.dll from \system32 or \SysWOW64. This can also prevent version conflicts, like the tutorial suggests.
*) I'm on 64-bit Windows 7, and the 64-bit version of SDL.dll didn't work for me.
Ensure that the SDL.dll (or SDL2.dll) that the .exe loads (from its own directory, or from a Windows system directory) matches the SDL.lib that it was linked with. Examples:
The application was unable to start correctly (0xc000007b)
Dev IL linking and compiling error (0xc000007b)
This applies to any version of Visual Studio, 32 or 64 bit, and any of Lazyfoo's tutorials.
Also what helped me - ensure you are using x86 .dll for the x86 application and not x64 dll files for the x86 app and vice versa.
Ran into this issue in VS2019 when running in debug mode, had to add path to my debugging environment.
Project properties->debugging settings
Currently Visual Studio just starts cl.exe for C++ source compilation. cl.exe needs to be in one of folders listed on the %PATH% environment variable.
Since there're separate versions of cl.exe for 32-bit and 64-bit compilation in order to compile a 32-bit project after compiling a 64-bit project it is necessary to restart Visual Studio.
The typical solution is to have two .cmd files each settings %PATH% appropriately and then starting Visual Studio. Is there a solution that doesn't require restarting Visual Studio?
You do not have to restart. Just setup two 'Solution Platforms' (Win32 and x64 for example) in your solution and projects and you are ready to go, as Visual Studio will automatically find the correct tools.
There is always the Build->Batch Build command, in which you can select the configurations to build.
Currently Visual Studio just starts cl.exe for C++ source compilation. cl.exe needs to be in one of folders listed on the %PATH% environment variable.
That isn't true. VS does not depend on the path to locate cl.exe (cl.exe is not in my path, but VC++ can compiler perfectly well regardless). I think it uses either the registry, or else it uses the configuration stored in Tools/Options/Projects and Solutions/VC++ Directories.
Since there're separate versions of cl.exe for 32-bit and 64-bit compilation in order to compile a 32-bit project after compiling a 64-bit project it is necessary to restart Visual Studio.
No, just create different targets for the project.
Configuration: Windows server 2008 x64.
Software is cross platform c++ 64bit.
The previous installer defaulted to asking the user to install to
c:\Program Files (x86)\company\version
For the last release I changed the installer using a path override to install to
c:\Program Files\company\version
The guys who does testing for us said that with the new install to c:\Program Files\ sub processes don't start. Override installing to c:\Program Files (x86)\xxx everything runs fine. Going to cmd.exe and running from C:\Program Files\xxx gives the "yyy.exe is not a valid Win32 application" error. Again this is not an issue with c:\Program Files (x86).
A customer also installed to default location and gets the same errors.
My build/dev machine does not show any of these errors. It runs a demo version of server 2008 (and visual studio express) that never updates and is never rebooted.
Is there something special about the "x86" tacked onto the Program Files ?
NOTE:
This is NOT a problem on my dev machine which is also server 2008 x86_64.
dumbin /headers clearly indicates these programs are 64bit.
At this point there is no answer.
Workaround is to just install to Program Files (x86) or elsewhere and be done with it. Will put in an FAQ that users should NOT install to Program Files (they'll look at a faq if stuff goes nuclear).
This could be a problem with the installer, it could be a classic case of "quack.exe" but applied to "Program Files". There's good reason why I generally hate windows.
The Program Files (x86) directory is where 32-bit programs are installed. When a 32-bit application is running, the %ProgramFiles% environment variable is set to C:\Program Files (x86)\ (by default; this could actually be located on a different drive).
Are you absolutely sure this program is being compiled as 64-bit?
Maybe the exe finds a dll in a 32-bit somehow in that particular configuration? E.g. when sb managed to mess up his 64-bits dir with 32-bit dlls.
Remember that not loadlibraried dll's are also loaded on startup.
I think this is related to the manifest of the application. Have you changed this somehow? I got the same error when I was switching back and forth between compilers. vc9 (vs2008) created a manifest which we normally never use when we compile on .net 2003.