This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: 64bit dll being installed to SysWow64\drivers on upgrade but not on fresh install
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 06, 2010
10:18 AM
64bit dll being installed to SysWow64\drivers on upgrade but not on fresh install
I have a license of IS2010 and we will be migrating to it shortly. But our current software uses IS 8.2. Since there is no longer a forum section for this version I'm posting here in the hopes that I can get some help with this final hurdle before we move on to the current IS version.
So the issue is that our installer package contains three different system-level drivers. A legacy version for win2000, a 32bit version for win2003/win2008 and a 64bit version for win2003/win2008. These three each have their own subfeature and component with conditions (eg. VersionNT64>0 AND VersionNT>= 502 for the 64bit version) that determine which one is installed.
So far so good. On a fresh install the correct driver is installed, for the 32bit versions the Destination is set to "[SystemFolder]Drivers" and for the 64bit version Destination is set to "[System64Folder]Drivers", in both cases the drivers are installed to the System32\Drivers directory as expected.
On upgrade of win2000 and 32 bit win2003/2008 the driver is upgraded correctly as well. However when performing an upgrade on a 64bit win2003/2008 the dll is instead installed to SysWow64\Drivers as if it was a 32bit binary!
Install log says:
[CODE]MSI (s) (8C:E0) [16:27:55:570]: Executing op: ComponentRegister(ComponentId={BFC90265-3ABE-4335-8479-08E49D2EB3F5},KeyPath=C:\Windows\SysWOW64\Drivers\QSFilter.sys,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=1)[/CODE]
- I've specifed "Favor Parent" for the Remote Installation for the sub-features and added them as Required Features to the parent feature.
- I've specified the 64bit component as a 64-bit Component and set Reevaluate Condition to Yes.
- I've set the Previous Package of the Release.
- I've tried both making a hybrid product configuration, as well as a 64bit product configuration (with Template Summary set to x64;1033).
Any additional suggestions would be much appreciated, I'm running out of ideas and things to search for!
So the issue is that our installer package contains three different system-level drivers. A legacy version for win2000, a 32bit version for win2003/win2008 and a 64bit version for win2003/win2008. These three each have their own subfeature and component with conditions (eg. VersionNT64>0 AND VersionNT>= 502 for the 64bit version) that determine which one is installed.
So far so good. On a fresh install the correct driver is installed, for the 32bit versions the Destination is set to "[SystemFolder]Drivers" and for the 64bit version Destination is set to "[System64Folder]Drivers", in both cases the drivers are installed to the System32\Drivers directory as expected.
On upgrade of win2000 and 32 bit win2003/2008 the driver is upgraded correctly as well. However when performing an upgrade on a 64bit win2003/2008 the dll is instead installed to SysWow64\Drivers as if it was a 32bit binary!
Install log says:
[CODE]MSI (s) (8C:E0) [16:27:55:570]: Executing op: ComponentRegister(ComponentId={BFC90265-3ABE-4335-8479-08E49D2EB3F5},KeyPath=C:\Windows\SysWOW64\Drivers\QSFilter.sys,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=1)[/CODE]
- I've specifed "Favor Parent" for the Remote Installation for the sub-features and added them as Required Features to the parent feature.
- I've specified the 64bit component as a 64-bit Component and set Reevaluate Condition to Yes.
- I've set the Previous Package of the Release.
- I've tried both making a hybrid product configuration, as well as a 64bit product configuration (with Template Summary set to x64;1033).
Any additional suggestions would be much appreciated, I'm running out of ideas and things to search for!
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 06, 2010
06:59 PM
This could be caused by older setup.exe's launching the 32-bit version of msiexec.exe (which then causes Windows Installer to resolve 32/64-bit paths incorrectly, even though the base install used the correct paths). This behavior was resolved in IS 2010. You can verify this is the case by manually launching your MSI with the 64-bit msiexec.exe from a command prompt window:
C:\Windows\System32\msiexec.exe -i "C:\PathToMsi\MsiPackage.msi" REINSTALL=ALL REINSTALLMODE=vomus
Note that REINSTALL and REINSTALLMODE are specifying a minor upgrade.
If the above install succeeds, this would verify that you are seeing the behavior caused by older setup.exe's. Unfortunately, there is no way to work around this issue when using setup.exe to launch the upgrade (aside from creating a custom setup bootstrapper).
C:\Windows\System32\msiexec.exe -i "C:\PathToMsi\MsiPackage.msi" REINSTALL=ALL REINSTALLMODE=vomus
Note that REINSTALL and REINSTALLMODE are specifying a minor upgrade.
If the above install succeeds, this would verify that you are seeing the behavior caused by older setup.exe's. Unfortunately, there is no way to work around this issue when using setup.exe to launch the upgrade (aside from creating a custom setup bootstrapper).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 07, 2010
07:48 AM
Hi joshstechnij (Josh S?),
Thanks for the fast response. Unfortunately I can't launch my msi directly as this is an InstallScript project that generates a setup.exe. I could however see that when launching the setup.exe in an upgrade scenario msiexec.exe as well as msiexec.exe*32 appear in the process list of task manager and while installing msiexec.exe*32 is the one using CPU cycles.
I'll see if I can isolate the issue by creating a super-slimmed install package soley for the file in question just to see if I can reproduce and test this. Thank you for your help.
Thanks for the fast response. Unfortunately I can't launch my msi directly as this is an InstallScript project that generates a setup.exe. I could however see that when launching the setup.exe in an upgrade scenario msiexec.exe as well as msiexec.exe*32 appear in the process list of task manager and while installing msiexec.exe*32 is the one using CPU cycles.
I'll see if I can isolate the issue by creating a super-slimmed install package soley for the file in question just to see if I can reproduce and test this. Thank you for your help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 07, 2010
10:12 AM
Tom Teboda wrote:
I'll see if I can isolate the issue by creating a super-slimmed install package soley for the file in question just to see if I can reproduce and test this.
For whatever reason that sent me back a step. Now initial install will install the right file (the 64bit version) but in the wrong dir (syswow64)... I'll keep trying though.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 07, 2010
12:28 PM
Unfortunately, InstallScript MSI projects add a bit of complexity to this scenario. The fix I mentioned for IS 2010 was specific to Basic MSI, since launching the installation merely requires launching msiexec.exe with appropriate command line parameters, we were able to resolve the described behavior by ensuring the correct msiexec.exe was launched (depending on the launching MSI's template summary).
However, for InstallScript MSI, the issue is somewhat different. Because InstallScript MSI projects use Windows Installer's external UI support, the MsiInstallProduct API is called directly by the InstallScript engine to start the MSI installation (as opposed to launching msiexec.exe). The InstallScript engine is 32-bit, and therefore loads a 32-bit version of msi.dll to call this API. As a result, a 32-bit version of MSI is used to install the target package (though this normally isn't an issue for 64-bit packages, MSI does not correctly resolve directory paths in maintenance scenarios).
This issue still exists in IS 2010 for InstallScript MSI projects since the InstallScript engine is still 32-bit. There are a couple of options to work around this behavior:
- Install the drivers separately with a Basic MSI project that is built 32 or 64-bit as needed. This can be installed from the parent InstallScript MSI project through LaunchAppAndWait.
- Use a pure InstallScript project and the DIFx support included (which allows for 32-bit and 64-bit driver support) and launch this from the parent InstallScript MSI. (Note that Developer 8 does not include support for pure InstallScript projects.)
- Use the newer InstallScript MSI embedded UI style (requires MSI 4.5, IS 2009 or newer). This UI style does not use the InstallScript engine as extensively as the traditional InstallScript MSI UI. As a result, a lot of the complexity and overhead that InstallScript MSI projects have is reduced or eliminated (this UI style can almost be thought of as a Basic MSI project that uses the InstallScript UI).
However, for InstallScript MSI, the issue is somewhat different. Because InstallScript MSI projects use Windows Installer's external UI support, the MsiInstallProduct API is called directly by the InstallScript engine to start the MSI installation (as opposed to launching msiexec.exe). The InstallScript engine is 32-bit, and therefore loads a 32-bit version of msi.dll to call this API. As a result, a 32-bit version of MSI is used to install the target package (though this normally isn't an issue for 64-bit packages, MSI does not correctly resolve directory paths in maintenance scenarios).
This issue still exists in IS 2010 for InstallScript MSI projects since the InstallScript engine is still 32-bit. There are a couple of options to work around this behavior:
- Install the drivers separately with a Basic MSI project that is built 32 or 64-bit as needed. This can be installed from the parent InstallScript MSI project through LaunchAppAndWait.
- Use a pure InstallScript project and the DIFx support included (which allows for 32-bit and 64-bit driver support) and launch this from the parent InstallScript MSI. (Note that Developer 8 does not include support for pure InstallScript projects.)
- Use the newer InstallScript MSI embedded UI style (requires MSI 4.5, IS 2009 or newer). This UI style does not use the InstallScript engine as extensively as the traditional InstallScript MSI UI. As a result, a lot of the complexity and overhead that InstallScript MSI projects have is reduced or eliminated (this UI style can almost be thought of as a Basic MSI project that uses the InstallScript UI).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 08, 2010
08:31 AM
Hello Josh,
I wouold like to know, if this issue can also happens in 2011 beta?
Thanks in advance.
I wouold like to know, if this issue can also happens in 2011 beta?
Thanks in advance.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 08, 2010
03:13 PM
There were no changes to the InstallScript engine for IS 2011 regarding this particular issue.