I'm having trouble installing a 64 bit program on my windows PC.
I'm running windows 7 64 bit.
Looking in regedit after a bit of googling I noticed the files seem to be in the opposite directories to what I think they should be.
Nope, those look correct to me. They are indeed confusing at first, and can be difficult to talk about.
System32 is the native system directory, and happens to be misleadingly named on a 64-bit system.
SysWow64 indicates the system directory for the Windows (32)-on-Windows 64.
Note of course that only a 64-bit application, or one that has disabled redirection, can use a path containing "System32" to reach the 64-bit files it contains.
Related
I have a 32 bits executable that calls functions inside a Dll file. When installed, the dll is copied in the same folder of the executable and the system directory (system32 on 32 bit platform and sysWOW64 on 64 bits platforms). I've sucessfully tested this executable on:
a Pc with winXP 32 bits,
a Virtual Machine with Win7 32 bits,
two PCs with win7 64 bits,
a laptop with win8 64 bits.
Then a customer gave me a laptop with Win 7 64 bits. It is infected with a virus (those kind of virus that hide all your folders and files in your memory stick and create shorcuts). On this laptop, my executable is unable to find my dll despite it is copied in the respective folders. My exe shows an error message that says "Unable to find mydll.dll".
Is it possible that the virus is interrupting the calls to the dll and messing up with my executable?
Yes, a virus can hook into ("override") LoadLibrary or GetProcAddress and just return a null value.
Then you'll receive this message.
Or it can put itselfs into the dll-loading process (infection) and cause a failure by an unintended malfunction.
It can remove execution permission
Or it can override the dll's magic bytes, so the system does no longer recognize the dll as dll...
Or it can "override" the file listing API, and always return null...
Or it can also recursively load/call itselfs until a stackoverflow occurs (it can also do this with a time-delay, causing seemingly random crashes)
or... or... or...
Generally speaking, it's a bad idea to do any testing whatsoever on a machine you know to be infected with a virus. Certainly one that is obviously mucking with the entire system. You literally cannot trust any single thing being said by the system because it is compromised.
So, really this has nothing to do with whether or not your DLL can be seen, bla bla bla... You should be concentrating on wiping the drive on that machine and starting over.
And while you're at it, don't put that thumb drive into another machine. Put it on a Linux box and format it. (virus can't spread that way.)
I am a newbie to Windows device drivers. My immediate task is to take an existing 32 bit minifilter driver and port it to 64 bit Windows. My development environment is Windows 7/64 bit, Visual Studio 2012 Ultimate, DDK 7600.16385.1, and SDK 7.1A. The install package is a setup.exe created with InstallShield 2013.
I've found some doc on porting drivers to 64 bit, but it's all about code issues. I haven't been able to find an idiot's guide covering step-by-step instructions for everything else you might have to change, so I decided to take the naive try-it-and-see-what-happens approach and just recompile for 64 bit, with the one exception to that being code signing since I did read somewhere that Win64 requires signed drivers.
The pre-existing build for the driver project used DDKBuild.cmd, and I have modified the properties for the Win64 platform to specify ../scripts/build.cmd -WNETAMD64 free $(OutDir) on the build command line. The compile and link are successful. I've modified the InstallShield project to pull in the signed 64 bit code file instead of the 32 bit code.
The installation appears to run successfully on a 64 bit system (Win2008 R2). There's a two line script that runs during the install:
rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 .\xxxxxflt.inf
fltmc load xxxxxflt
The rest of our application is actually Java, which makes some JNI calls to a couple of DLLs, one of which calls FilterLoad(). (BTW, the JVM and the DLLs remain 32 bit, but my understanding is that 32 bit code should be able to load a 64 bit driver via FilterLoad(). Please correct me if I'm wrong.) The return from FilterLoad() was ERROR_FILE_NOT_FOUND, and that caused me to notice that, as stated above in the question, the xxxxxxflt.sys file had been copied into SysWOW64\drivers instead of System32\drivers.
I know this is wrong, because Win64 is oppositeland, so System32 is where 64 bit stuff should go and SysWOW64 is where 32 bit stuff should go. What I don't know is why it ended up there. Are there changes necessary in the .inf file in order to identify this as a 64 bit driver? Is there anything I might have to do in the InstallShield project to tell it to build a 64 bit installer or run scripts in a 64 bit engine? Does the script have to do something to force use of the 64 bit version of rundll32? Something else, perhaps?
I haven't seen this specific problem, but I've had issues with this type of "WOW64" thing before. It usually means there is something within your software that is 32-bit and is being run in that mode, so anything you do will end up in the a "Program Files (x86)" or "WOW64" type location. Here is what I think might be happening:
This could have something to do with the way you are calling rundll32.exe. See the following post:
rundll32.exe equivalent for 64-bit DLLs
It's possible that if your InstallSheild installation is creating a 32-bit executable then it is running in WOW mode already which means that it's probably choosing the rundll32.exe that is in the WOW directory, thus the reason your installation ends up there too.
You might look at modifying your script to call the specific one based on the platform, or see if you can change your InstallShield to run as a 64-bit application in non WOW64 mode.
Just out of curiosity, if I am creating a program installer, how should I decide in which "Program Files" directory to install to? On 32-bit systems, the environmental variable "%programfiles%" is good enough. However, on 64-bit systems, 32-bit programs should not install to that folder and instead to "%programfiles(x86)%", which as I understand points to "C:\Program Files (x86)". My question is: How should the installer decide which environment variable to use? Will the value of "%programfiles%" change for a 32-bit application, or should I always check first whether "%programfiles(x86)%" exists before using "%programfiles%", or should I do something entirely different?
Thanks! This is just out of my own curiosity, as I try to get used to 64-bit operating systems.
When the 32-bit program (installer in your case) asks the system to resolve the ProgramFilePath constant (check the exact name in MSDN), the system does not return C:\Program files, but C:\Program files(x86). So it's the system that decides, not the application.
I'm pretty certain that I read somewhere that Windows did this for you automagically. In other words, if your installer was 32-bits, it would be routed to the x86 directory variant even though you were trying to install into Program Files.
I'm sure I read this on The Old New Thing but here's a link that supports the contention until I can find that one.
Ah, yes, here it is, from the ever useful Raymond Chen.
Commenter Koro is writing an installer in the form of a 32-bit program that detects that it's running on a 64-bit system and wants to copy files (and presumably set registry entries and do other installery things) into the 64-bit directories, but the emulation layer redirects the operations into the 32-bit locations. The question is "What is the way of finding the x64 Program Files directory from a 32-bit application?"
The answer is "It is better to work with the system than against it." If you're a 32-bit program, then you're going to be fighting against the emulator each time you try to interact with the outside world. Instead, just recompile your installer as a 64-bit program. Have the 32-bit installer detect that it's running on a 64-bit system and launch the 64-bit installer instead. The 64-bit installer will not run in the 32-bit emulation layer, so when it tries to copy a file or update a registry key, it will see the real 64-bit file system and the real 64-bit registry.
Trying to find third issue in the database with no luck.
So, I'm developing on a 64bit system (windows seven).
I'm making a simple console programme that check if a dll is present on the windows system. in that case I check in the system32 folder and then, in the sysWOW64 folder.
The pro gramme is 32bit application.
On a 32bit target platform, I can check normally the win32dll, as the SysWOW64 directory doesn't exist, no problem.
Bit when it execute on a 64bit system I can check the win32 directory, but the sysWOW64 directory always me point to the system32 directory.
It seems that on 64bit system there is a kind of redirection.
I'm trying to use the "Wow64DisableWow64FsRedirection" but I have "error C3861: 'Wow64DisableWow64FsRedirection': identifier not found" when I compile.
So there are two questions:
In winbase.h this function is disabled, how to get it work ?
How to determine if I'm currently on a 32 or 64 bit system as programme is running?
You don't have to search for DLLs. LoadLibrary() and LoadLibraryEx() will automatically search all relevant folders for you.
The search order is as follows:
The directory from which the application loaded.
The system directory.
The 16-bit system directory.
The Windows directory
The current directory.
The directories that are listed in the PATH environment variable.
If you're sure that you want to disable the redirection you can do so with Wow64DisableWow64FsRedirection as you mentioned. To make it "work", you have to set
#define _WIN32_WINNT 0x0501 (or higher)
before you include windows.h
About How to determine if i'm currently on a 32 or 64 bit system, I think that you could check the size of an int pointer...
int bits = IntPtr.Size * 8;
Console.WriteLine( "{0}-bit", bits );
While not perhaps what you're looking for, slightly wasteful if you know those are the only two places the file could be located, and possibly wouldn't work if the user has modified them (Although a whole host of other things will have broken for the user too), you could simply use the %Path% environmental variable.
Is there a way from a 32bit application running on a 64bit system to have access to the default folders for 64bit applications?
For example, using SHGetSpecialFolderPath with CSIDL_PROGRAM_FILES from a 32bit application returns "C:\Program Files (x86)' If the same call was used from a 64bit application, I would get "C:\Program Files". Is there a way of getting that "C:\Program Files" from a 32bit application?
A related question here does not help SHGetFolderPath() 32 bit vs 64 bit nor does supressing the wow64 filesystem redirection before calling SHGetSpecialFolderPath
Answering my own question, it seems it is not possible with SHGetSpecialFolderPath. In Vista and later, using the replacement function SHGetKnownFolderPath allows it with FOLDERID_ProgramFilesX64
I believe the whole reason for having separate folders was to prevent 32 and 64 bit applications from mixing. Therefore, you shouldn't need to see a folder belonging to a different bitness from your application.
You may have a very good reason, but I don't see one in your question as posted.