I am wondering how others have possibly addressed a problem I have. I
have a client who wants to install drivers I have developed as part of a
32-bit install program. Normally, I expect separate installs for 32-bit
and 64-bit so I am wondering if there are any gotcha (besides not being
able to use Driver Install Frameworks) that I need to be aware of. Any
suggestions or warnings about doing driver installs under WoW64 would be
appreciated.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Can’t say much for hardware drivers, but mini-filters can be installed simply by disabling WoW64 redirection
(and obviously copying the correct binary…) and no other changes from a 32-bit installer on x64 Windows.
Unless you are running some program during install, which is not yours (i.e. you cannot modify it to comply with
WoW64 requirements for this purpose), then the install would work for any type of driver.
INF based installations might present some issues, but I have no specific recommendations or known gotchas here.
One obvious issue is if you need to communicate with the driver right after the installation, from the
installation program. In that case, your communication mechanism must be able to accept IOCTLs from 32-bit apps, and
pad the data properly.
E.g. most filters would probably be controlled by both 32 and 64-bit apps, and any pointer must be recalculated
in the driver and in user mode (and obviously cannot be directly passed between the two). What I did for this
purpose is for any pointer in a structure:
PVOID lpSomePointer;
#ifndef _WIN64
DWORD dwSomePointerPadding;
#endif
Dejan.
Don Burn wrote:
I am wondering how others have possibly addressed a problem I have. I
have a client who wants to install drivers I have developed as part of a
32-bit install program. Normally, I expect separate installs for 32-bit
and 64-bit so I am wondering if there are any gotcha (besides not being
able to use Driver Install Frameworks) that I need to be aware of. Any
suggestions or warnings about doing driver installs under WoW64 would be
appreciated.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
It depends on how the driver is installed. If that is through an INF file
then that is usually installed programmatically by executing rundll32.exe
setupapi …
The trick is then to NOT execute the 32bit version of rundll32 that resides
in your \Windows\SysWOW64 directory but the 64bit version. Then everything
else that gets executed in that chain will be a 64 bit process.
To access the 64-bit version of rundll32.exe from a wow application, you can
disable fs redirection (Wow64DisableWow64FsRedirection ). or specify the
system32 directory as “sysnative”.
//Daniel
“Don Burn” wrote in message news:xxxxx@ntdev…
>I am wondering how others have possibly addressed a problem I have. I have
>a client who wants to install drivers I have developed as part of a 32-bit
>install program. Normally, I expect separate installs for 32-bit and
>64-bit so I am wondering if there are any gotcha (besides not being able to
>use Driver Install Frameworks) that I need to be aware of. Any suggestions
>or warnings about doing driver installs under WoW64 would be appreciated.
>
>
> Don Burn
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
I have single 32-bit wrapper which enapsulates 32-bit and 64 bit installers. If wow64 is detected, then 64-bit installer is executed, 32-bit installer otherwise
Some more explanations. This is actually two real hardware drivers,
though one of them is a root enumerated KMDF driver that accesses the
LPT port. The LPT version is only installed if the LPT port is present
on the system. The other device uses WinUSB.
This will be a DLL used as part of a larger MSI install of an
application. If the driver does not install, then the client does not
want the application to install. So I can do it with two installer
app’s but this gets messy on coordinating back the results. I think it
can be done with one set of code and setupAPI but am not sure, the
Microsoft doc’s are vague.
I don’t use rundll32 for driver installs, period. The last time I was
foolish enough to be involved with the a project that did the support
time quickly got to orders of magnitude more than doing it right.
Normally I would do this with 32 and 64 bit versions of the DLL calling
DifxAPI to do the preintalls, and then setup API’s to install the root
enumerated device.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Don Burn” wrote in message news:xxxxx@ntdev…
> I don’t use rundll32 for driver installs, period. The last time I was
> foolish enough to be involved with the a project that did the support time
> quickly got to orders of magnitude more than doing it right.
>
You are right about that. There is a long chain of processes and a hell of
usermode stuff excecuted that do weird things such as DDE that easily can
get stuck and lead to a driver not installed.
//Daniel
Don Burn wrote:
I am wondering how others have possibly addressed a problem I have. I
have a client who wants to install drivers I have developed as part of a
32-bit install program. Normally, I expect separate installs for 32-bit
and 64-bit so I am wondering if there are any gotcha (besides not being
able to use Driver Install Frameworks) that I need to be aware of. Any
suggestions or warnings about doing driver installs under WoW64 would be
appreciated.
I always do one package, with one INF file and two subdirectories. I
include both copies of DPInst, and my installer calls the appropriate one.
The only tricky part is remembering about file system redirection in
your 32-bit installer.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 22-May-2012 20:38, Tim Roberts wrote:
Don Burn wrote:
> I am wondering how others have possibly addressed a problem I have. I
> have a client who wants to install drivers I have developed as part of a
> 32-bit install program. Normally, I expect separate installs for 32-bit
> and 64-bit so I am wondering if there are any gotcha (besides not being
> able to use Driver Install Frameworks) that I need to be aware of. Any
> suggestions or warnings about doing driver installs under WoW64 would be
> appreciated.
I always do one package, with one INF file and two subdirectories. I
include both copies of DPInst, and my installer calls the appropriate one.
The only tricky part is remembering about file system redirection in
your 32-bit installer.
By the way, Inno Setup does this automatically. You just say in the
script that the payload is 64-bit aware.
– pa
[off list]
Don,
I have done this numerous times and have the scars to prove it 
Bottom line, if at all possible, just use two MSI packages (one for x86, one
for x64) and be done with it. If DIFxAPP can do the job for you just let
it. Install/Upgrade/Rollback-On-Failure/Repair/Uninstall works for the most
part and especially well for PnP drivers. NetService class takes some
extra work.
Now the only way I have done this that did not involve a platform specific
MSI is to build a custom action DLL (32-bit) which contained as binary
resources platform specific .EXE files buried in it. The .EXE modules were
built as RPC servers that took a command line (a GUID) to specify a private
binding string and the DLL was the RPC client. The DLL is loaded as a CA,
get’s called at an entry point, extracts the platform specific RPC server
EXE, runs it, then calls into the RPC service to do whatever was needed in
platform specific code. One such incarnation of this was simply an RPC
layer over DIFxAPI, some SetupAPI helpers, and INetCfg.
However I have it on the roadmap to look at another MSI feature in Windows
Installer 4.5+ that permits a single MSI transaction to include separate
MSIs. I am thinking of using that to split one installer into platform
neutral and platform specific MSI files and have a ‘bootstrapper’
(setup.exe) combine the two MSI modules required for any one platform into a
single transaction. So for x86 it would be (common + drivers-x86) and on
x64 (common + drivers-x64).
But honestly, the per-platform MSI is in the end way easier to get right and
not constantly be fiddling with.
Good Luck,
-dave cattley
Not so much off list now was it
-dave
Spawn a 64bit driver installer from the 32bit main installer.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Don Burn” wrote in message news:xxxxx@ntdev…
>I am wondering how others have possibly addressed a problem I have. I
> have a client who wants to install drivers I have developed as part of a
> 32-bit install program. Normally, I expect separate installs for 32-bit
> and 64-bit so I am wondering if there are any gotcha (besides not being
> able to use Driver Install Frameworks) that I need to be aware of. Any
> suggestions or warnings about doing driver installs under WoW64 would be
> appreciated.
>
>
> Don Burn
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>