Why is my 64 bit minifilter driver installing in the SysWOW64\drivers folder?

Question

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?

Answer 1

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.