|
Hi,
As some of you have probably noticed, there has been some discussion recently regarding problems with DIFxApp causing rollbacks. I did some more investigation and was able to reliably reproduce the issue and come up with a very good idea on what is causing the problem. All investigation was done with the version of DIFxApp included with Windows DDK version 7600.16385.1; note that this will also reproduce with the version included with WiX 3.0 / 3.5. It was done on a clean Windows XP SP2 virtual machine with .NET Framework 2.0; however we have observed the same problems on Windows 7. As far as I can tell, this is a bug in the DIFxApp DLLs and/or the WiX extension for DIFxApp. If anyone knows some good workarounds, or how to report this to the proper channels and get it fixed it would be much appreciated! From what I can tell, there exist situations in any DIFxApp setup program doing an upgrade where if the user cancels the setup at a certain point (or there is an error in the installation of the new product) then the user's system will be hosed and they would be unable to uninstall the product without some involved technical support. If the bug can't be fixed or worked around, I don't see how DIFxApp is suitable for use in a commercial product that needs to support upgrades (i.e. all products). And since DIFxApp isn't open source, I can't go in and just fix the problem. Very frustrating! The problem is that DIFxApp does not restore the system to a correct state after a failed major upgrade when installing the new product/driver. The following sequence of events on a product will reproduce the problem when doing a major upgrade: 1. RemoveExistingProducts action is started to uninstall the old product. The following actions run in the context of uninstalling the old version of the product/driver. 2. MsiProcessDrivers runs to schedule the MsiUninstallDrivers action. 3. MsiUninstallDrivers runs and successfully removes the old driver from the computer. 4. MsiCleanupOnSuccess runs and does its cleanup tasks. 5. RemoveExistingProducts action is completed successfully. The following actions run in the context of installing the new version of the product/driver: (note that at this point the system has been completely purged of the old driver) 6. MsiProcessDrivers runs and schedules the driver installation. 7. MsiInstallDrivers runs to install the new driver. Suppose this new driver installation is NOT successful. In this example, an unsigned driver was used and so the user was asked whether or not to install it. The user declines. 8. The setup is now in a failing state because MsiInstallDrivers wasn't able to load the new driver. 9. MsiRollbackInstall runs but does nothing since the new driver wasn't installed. 10. The setup concludes by continuing to rollback all other changes (installed files, etc.). The old version of the product is now supposedly in place as it was before, since canceling a Windows Installer setup should roll back all changes that were made since the start of setup. 11. At this point, DIFxApp should run MsiInstallDrivers again to install the old driver that was previously uninstalled, but it does not. At this point, DIFxApp should have restored the old version of the driver as part of a rollback. Unfortunately, it does not. The resulting state of the DIFx portion of the computer is as if an uninstall had been performed. No DIFxApp keys exist in the registry for the old driver, even though the old version of the product is still installed. The old driver is not in the driver store, either. This results in a frustrating experience for the user when they try to uninstall. The MsiUninstallDrivers requires the presence of DIFxApp registry keys for the component in the registry and when it does not find these, it results in an error and a failed uninstall. Also, because the system is in an incomplete state, the user isn't able to use the hardware device either, since the driver was uninstalled and never restored as part of the rollback. While signing the driver would have obviously "fixed" the problem in this case, this is not the root problem. The root problem is that DIFxApp does not install the old driver as part of a rollback when the installation of the new product fails. For example, merely clicking the "Cancel" button at any time after RemoveExistingProducts has completed will reproduce the problem. This was tested and reproduced by canceling setup after the DIFxApp registry keys were removed by the uninstallation of the old product (by constantly pressing F5 to refresh in Registry Editor). After the upgrade setup was canceled at that point, I was unable to uninstall the old product. I have included excerpts from the MSI log file taken during the major upgrade, as shown below. I also showed the log file entry that shows up when trying (and failing) to uninstall the old product. Notes on reading the log: * Some information was sanitized; for example the GUID of the driver component is shown as "{driver component GUID}" because I removed the actual GUID from this public e-mail list. * Large portions of the log file were removed; only relevant data was included. Line numbers are sometimes indicated as "Line XYZ:". * If lines were removed, this is indicated by "<.hundreds of lines.>" Best regards, James Johnston Log files below. Attempts to uninstall after upgrade: DIFXAPP: ERROR 0x2 encountered while opening persistent-info key for component '{driver component GUID}' DIFXAPP: UninstallDriverPackages failed with error 0x2 DIFXAPP: RETURN: UninstallDriverPackages() 2 (0x2) Upgrade: Line 226: Action start 22:26:17: RemoveExistingProducts. <.hundreds of lines.> Action 22:26:22: MsiProcessDrivers. Action start 22:26:22: MsiProcessDrivers. DIFXAPP: ENTER: ProcessDriverPackages() DIFXAPP: INFO: 'Component' is 'MyDriverComponent' DIFXAPP: INFO: Component state 0x3 -> 0x2 DIFXAPP: INFO: 'ComponentId' is {driver component GUID} DIFXAPP: INFO: 'Flags' is 10 DIFXAPP: INFO: component path is DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1644491937-2147298945-839522115-1003'. DIFXAPP: INFO: creating HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\ Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ... Action 22:26:22: MsiUninstallDrivers. Action start 22:26:22: MsiUninstallDrivers. MsiUninstallDrivers: Action ended 22:26:22: MsiUninstallDrivers. Return value 1. DIFXAPP: RETURN: ProcessDriverPackages() 0 (0x0) Line 460: Action ended 22:26:22: MsiProcessDrivers. Return value 1. <.hundreds of lines.> Action 22:26:28: MsiUninstallDrivers. DIFXAPP: UninstallDriverPackages() DIFXAPP: 'CustomActionData' property 'DIFxApp Version' is 2.1. DIFXAPP: 'CustomActionData' property 'UI Level' is 5. DIFXAPP: 'CustomActionData' property 'componentId' is {driver component GUID}. DIFXAPP: 'CustomActionData' property 'flags' is 0xA. DIFXAPP: 'CustomActionData' property 'ProductName' is My Product. DIFXAPP: 'CustomActionData' property 'ManufacturerName' is My Company. DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1644491937-2147298945-839522115-1003'. DIFXAPP: INFO: opening HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\ Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ... DIFXAPP: INFO: ENTER: DriverPackageUninstallW DIFXAPP: INFO: Uninstalling driver package C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf... DIFXAPP: INFO: Successfully removed 'C:\WINDOWS\INF\oem8.inf'. DIFXAPP: INFO: No devices found for C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf uninstall. DIFXAPP: INFO: Driver store entry 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf' removed. DIFXAPP: SUCCESS:Uninstall completed. DIFXAPP: INFO: RETURN: DriverPackageUninstallW (0x0) DIFXAPP: INFO: driver store 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf' uninstalled. DIFXAPP: INFO: deleted add remove programs key for 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf'. DIFXAPP: A reboot is not needed to uninstall the driver package '{driver component GUID}'. 2186: DIFXAPP: RETURN: UninstallDriverPackages() 0 (0x0) <.hundreds of lines.> Action 22:26:49: MsiCleanupOnSuccess. Action start 22:26:49: MsiCleanupOnSuccess. DIFXAPP: ENTER: CleanupOnSuccess() DIFXAPP: INFO: 'Component' is 'MyDriverComponent' DIFXAPP: INFO: 'ComponentId' is {driver component GUID} DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1644491937-2147298945-839522115-1003'. DIFXAPP: INFO: opening HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\ Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ... DIFXAPP: RETURN: CleanupOnSuccess() 0 (0x0) 8765: Action ended 22:26:49: MsiCleanupOnSuccess. Return value 1. <.hundreds of lines.> 9332: Action ended 22:26:50: RemoveExistingProducts. Return value 1. Action 22:26:51: MsiProcessDrivers. Action start 22:26:51: MsiProcessDrivers. DIFXAPP: ENTER: ProcessDriverPackages() DIFXAPP: INFO: 'Component' is 'MyDriverComponent' DIFXAPP: INFO: Component state 0x2 -> 0x3 DIFXAPP: INFO: 'ComponentId' is {driver component GUID} DIFXAPP: INFO: 'Flags' is 10 DIFXAPP: INFO: component path is C:\Program Files\My Product\Product-CDM-Bus\ DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1644491937-2147298945-839522115-1003'. DIFXAPP: INFO: creating HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\ Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ... Action 22:26:52: MsiRollbackInstall. Action start 22:26:52: MsiRollbackInstall. MsiRollbackInstall: Action ended 22:26:52: MsiRollbackInstall. Return value 1. Action 22:26:52: MsiInstallDrivers. Action start 22:26:52: MsiInstallDrivers. MsiInstallDrivers: Action ended 22:26:52: MsiInstallDrivers. Return value 1. DIFXAPP: RETURN: ProcessDriverPackages() 0 (0x0) 9402: Action ended 22:26:52: MsiProcessDrivers. Return value 1. <.hundreds of lines.> Action 22:27:14: MsiRollbackInstall. Action 22:27:14: MsiInstallDrivers. DIFXAPP: ENTER: InstallDriverPackages() DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'. DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'. DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{driver component GUID}'. DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is 'C:\Program Files\My Product\Product-CDM-Bus\'. DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xA. DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'. DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is 'My Product'. DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is 'My Company'. DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1644491937-2147298945-839522115-1003'. DIFXAPP: INFO: opening HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\ Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ... DIFXAPP: INFO: ENTER: DriverPackageInstallW DIFXAPP: INFO: Copied 'productbus.inf' to driver store... DIFXAPP: INFO: Copied 'productbus.cat' to driver store... DIFXAPP: INFO: Commiting queue... DIFXAPP: INFO: Copied file: 'C:\Program Files\My Product\Product-CDM-Bus\i386\ftd2xx.dll' -> 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\i386\ftd2xx.dll' . DIFXAPP: INFO: Copied file: 'C:\Program Files\My Product\Product-CDM-Bus\i386\FTLang.Dll' -> 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\i386\FTLang.Dll' . DIFXAPP: INFO: Copied file: 'C:\Program Files\My Product\Product-CDM-Bus\i386\ftdibus.sys' -> 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\i386\ftdibus.sys '. DIFXAPP: INFO: Copied file: 'C:\Program Files\My Product\Product-CDM-Bus\i386\ftbusui.dll' -> 'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\i386\ftbusui.dll '. DIFXAPP: WARNING:Skipping copy of file ftd2xx64.dll. File is referenced in productbus.inf but not listed in section . DIFXAPP: ERROR: Invalid signature. Possibly rejected by user. (Error code 0x800B0110: The certificate is not valid for the requested usage.) DIFXAPP: INFO: Removed driver package from store. DIFXAPP: INFO: Successfully removed '{driver component GUID}' from reference list of driver store entry '' DIFXAPP: INFO: RETURN: DriverPackageInstallW (0x800B0110) DIFXAPP: ERROR: encountered while installing driver package 'C:\Program Files\My Product\Product-CDM-Bus\productbus.inf' DIFXAPP: ERROR: InstallDriverPackages failed with error 0x800B0110 DIFXAPP: RETURN: InstallDriverPackages() 2148204816 (0x800B0110) Action ended 22:27:18: InstallFinalize. Return value 3. Action 22:27:18: Rollback. Rolling back action: Rollback: MsiInstallDrivers Rollback: MsiRollbackInstall DIFXAPP: ENTER: RollbackInstall() DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'. DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{driver component GUID}'. DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xA. DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'. DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is 'My Product'. DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is 'My Company'. DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1644491937-2147298945-839522115-1003'. DIFXAPP: INFO: This was the component where the install failure occurred. The rollback for this component must have already occurred at the time of failure. No need to rollback again DIFXAPP: ERROR: Rollback failed with error 0x2 10938: DIFXAPP: RETURN: RollbackInstall() 2 (0x2) ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
Thanks for digging into this further. The support e-mail for DIFx Tools
is [hidden email]. I have received responses over the years from different people, but never any resolution to my problems. If that e-mail address is no longer valid, then I can give you the addresses of the specific people that replied. Please keep me posted on what you find out. --Quinton -----Original Message----- From: James Johnston [mailto:[hidden email]] Sent: Thursday, December 09, 2010 3:46 PM To: [hidden email] Subject: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade > Hi, > > As some of you have probably noticed, there has been some discussion > recently regarding problems with DIFxApp causing rollbacks. I did some more > investigation and was able to reliably reproduce the issue and come up with > a very good idea on what is causing the problem. All investigation was done > with the version of DIFxApp included with Windows DDK version 7600.16385.1; > note that this will also reproduce with the version included with WiX 3.0 / > 3.5. It was done on a clean Windows XP SP2 virtual machine with .NET > Framework 2.0; however we have observed the same problems on Windows 7. > > As far as I can tell, this is a bug in the DIFxApp DLLs and/or the WiX > extension for DIFxApp. If anyone knows some good workarounds, or how to > report this to the proper channels and get it fixed it would be much > appreciated! From what I can tell, there exist situations in any DIFxApp > setup program doing an upgrade where if the user cancels the setup at a > certain point (or there is an error in the installation of the new product) > then the user's system will be hosed and they would be unable to uninstall > the product without some involved technical support. > > If the bug can't be fixed or worked around, I don't see how DIFxApp is > suitable for use in a commercial product that needs to support upgrades > (i.e. all products). And since DIFxApp isn't open source, I can't go in and > just fix the problem. Very frustrating! > > ... ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
Seeing as how this seems to be a fundamental problem with DIFxApp not
handling all the upgrade possibilities well, I was curious to see how other products do things and so I ripped apart some MSIs in Orca. I was looking to see if DIFxApp was set up the same way (CustomAction table). I also inspected the placement of the RemoveExistingProducts action since after my previous e-mail I believe that this plays a critical role in whether this corrupted system state may occur. Since I haven't seen any other indication or documentation on the Internet (a Google search for RemoveExistingProducts and DIFxApp reveals little), I thought it would be useful to report my findings so others can see what some commercial software is doing. My findings: All products using DIFxApp place MsiProcessDrivers and MsiCleanupOnSuccess actions in the normal places. CustomAction types are always the same. I identified the program used to compile the MSI by looking at the self-named custom actions each install tool tends to create (e.g. InstallShield has its own DLL with tons of custom actions). Refer to http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-ma jor-msi-upgrade/ to better understand the placement of RemoveExistingProducts action. Examining this table leads me to believe that placement between InstallInitialize and InstallFinalize is the best place, since a canceled setup will always leave the old version on the computer, no matter what. But this doesn't seem to work with DIFxApp due to its bug, as previously noted. My product (with the rollback problem): Compiled with WiX and uses DIFxApp. RemoveExistingProducts is placed after InstallInitialize. According to the previous link, a failure at any time (uninstall or reinstall) results in only the old version remaining: leaving system state exactly as it was found. Unfortunately, as previously noted, a bug in DIFxApp prevents this from happening. Apple Mobile Device Support (included with iTunes; presumably their iPod drivers, etc.). Compiled with WiX and uses DIFxApp. RemoveExistingProducts is placed after InstallFinalize. Probably the DIFxApp bug is not a problem here, because the new version is installed before the old version is uninstalled. An error in the new version setup (from DIFx or other source) would still leave the old version and its drivers untouched. An error in the old version uninstall would leave the new version & its drivers untouched. According to the table at the above link, the pitfall is that if the uninstall fails, then BOTH versions of the product remain installed on the computer. This seems like a very inconsistent, illogical state to be in; I can imagine that there could be some issues with a lot of products (including mine) if this were to happen. (Perhaps an MSI expert can convince me otherwise? Otherwise, I wonder if Apple's software can get itself in a bad way if I click Cancel at just the right moment.) Microsoft LifeCam (webcam driver). Don't know what compiled this; I didn't see any obvious indications. It uses DIFxApp. RemoveExistingProducts is placed after InstallInitialize. It therefore appears to be in a very similar configuration as with my product, and I believe it would leave the user's DIFxApp state inconsistent if the upgrade was canceled at just the right moment. It is interesting to note that the MSI file is wrapped by a bootstrapper: the MSI itself throws no UI. The bootstrapper does NOT present the user with a Cancel button. Perhaps this is a reason why? Oracle VirtualBox (virtual network drivers). Compiled with WiX and uses DIFxApp. RemoveExistingProducts is placed between InstallValidate and InstallInitialize. This seems like the best place to put it. Uninstall happens first, so there's no possibility of having both versions at the same time. If the uninstall fails, then the old version remains. If the install fails, then nothing remains on the computer (i.e. the old version is not reinstalled). I don't see how this DIFxApp bug would be a problem in this scenario since the old version isn't reinstalled. Western Digital SmartWare (some proprietary driver for external hard drive). Compiled with Advanced Installer and uses DIFxApp. RemoveExistingProducts is placed between InstallValidate and InstallInitialize, like with VirtualBox. HP OfficeJet 8500. Compiled with WiX. RemoveExistingProducts is placed after InstallInitialize so I suspect their installer has the same bug. Intel Network Connections driver, MS Virtual PC 2007, and VMware Workstation 7: these products use Windows Installer but have proprietary, non-DIFxApp custom actions for installing drivers. Logitech webcam driver, Dell V310 printer driver, NVIDIA graphics drivers, ATI Radeon graphics driver, Intel HD graphics driver, Intel DH55HC drivers, Intel HD Audio drivers: these products did not appear to use Windows Installer for installing the drivers. (Some drivers had MSI files for helper/utility programs but did not have the MsiDriverPackages table so I conclude they do something else). Best regards, James Johnston -----Original Message----- From: Quinton Tormanen [mailto:[hidden email]] Sent: Friday, December 10, 2010 17:53 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade Thanks for digging into this further. The support e-mail for DIFx Tools is [hidden email]. I have received responses over the years from different people, but never any resolution to my problems. If that e-mail address is no longer valid, then I can give you the addresses of the specific people that replied. Please keep me posted on what you find out. --Quinton -----Original Message----- From: James Johnston [mailto:[hidden email]] Sent: Thursday, December 09, 2010 3:46 PM To: [hidden email] Subject: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade > Hi, > > As some of you have probably noticed, there has been some discussion > recently regarding problems with DIFxApp causing rollbacks. I did some more > investigation and was able to reliably reproduce the issue and come up with > a very good idea on what is causing the problem. All investigation was done > with the version of DIFxApp included with Windows DDK version 7600.16385.1; > note that this will also reproduce with the version included with WiX 3.0 / > 3.5. It was done on a clean Windows XP SP2 virtual machine with .NET > Framework 2.0; however we have observed the same problems on Windows 7. > > As far as I can tell, this is a bug in the DIFxApp DLLs and/or the WiX > extension for DIFxApp. If anyone knows some good workarounds, or how to > report this to the proper channels and get it fixed it would be much > appreciated! From what I can tell, there exist situations in any DIFxApp > setup program doing an upgrade where if the user cancels the setup at a > certain point (or there is an error in the installation of the new product) > then the user's system will be hosed and they would be unable to uninstall > the product without some involved technical support. > > If the bug can't be fixed or worked around, I don't see how DIFxApp is > suitable for use in a commercial product that needs to support upgrades > (i.e. all products). And since DIFxApp isn't open source, I can't go in and > just fix the problem. Very frustrating! > > ... ---------------------------------------------------------------------------- -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
I appear to be looking at the same problem. I was able to reproduce it by hitting 'cancel' near the
end of an uninstall and letting it rollback. After that uninstallation failed. Performing a repair fixed things. Did you email the difx team at the email address Quinton suggested, and if so, did you ever hear anything back. Thanks, Rob On 10/12/2010 20:37, James Johnston wrote: > Seeing as how this seems to be a fundamental problem with DIFxApp not > handling all the upgrade possibilities well, I was curious to see how other > products do things and so I ripped apart some MSIs in Orca. I was looking > to see if DIFxApp was set up the same way (CustomAction table). I also > inspected the placement of the RemoveExistingProducts action since after my > previous e-mail I believe that this plays a critical role in whether this > corrupted system state may occur. Since I haven't seen any other indication > or documentation on the Internet (a Google search for RemoveExistingProducts > and DIFxApp reveals little), I thought it would be useful to report my > findings so others can see what some commercial software is doing. My > findings: > > All products using DIFxApp place MsiProcessDrivers and MsiCleanupOnSuccess > actions in the normal places. CustomAction types are always the same. I > identified the program used to compile the MSI by looking at the self-named > custom actions each install tool tends to create (e.g. InstallShield has its > own DLL with tons of custom actions). > > Refer to > http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-ma > jor-msi-upgrade/ to better understand the placement of > RemoveExistingProducts action. Examining this table leads me to believe > that placement between InstallInitialize and InstallFinalize is the best > place, since a canceled setup will always leave the old version on the > computer, no matter what. But this doesn't seem to work with DIFxApp due to > its bug, as previously noted. > > My product (with the rollback problem): Compiled with WiX and uses DIFxApp. > RemoveExistingProducts is placed after InstallInitialize. According to the > previous link, a failure at any time (uninstall or reinstall) results in > only the old version remaining: leaving system state exactly as it was > found. Unfortunately, as previously noted, a bug in DIFxApp prevents this > from happening. > > Apple Mobile Device Support (included with iTunes; presumably their iPod > drivers, etc.). Compiled with WiX and uses DIFxApp. RemoveExistingProducts > is placed after InstallFinalize. Probably the DIFxApp bug is not a problem > here, because the new version is installed before the old version is > uninstalled. An error in the new version setup (from DIFx or other source) > would still leave the old version and its drivers untouched. An error in > the old version uninstall would leave the new version& its drivers > untouched. According to the table at the above link, the pitfall is that if > the uninstall fails, then BOTH versions of the product remain installed on > the computer. This seems like a very inconsistent, illogical state to be > in; I can imagine that there could be some issues with a lot of products > (including mine) if this were to happen. (Perhaps an MSI expert can > convince me otherwise? Otherwise, I wonder if Apple's software can get > itself in a bad way if I click Cancel at just the right moment.) > > Microsoft LifeCam (webcam driver). Don't know what compiled this; I didn't > see any obvious indications. It uses DIFxApp. RemoveExistingProducts is > placed after InstallInitialize. It therefore appears to be in a very > similar configuration as with my product, and I believe it would leave the > user's DIFxApp state inconsistent if the upgrade was canceled at just the > right moment. It is interesting to note that the MSI file is wrapped by a > bootstrapper: the MSI itself throws no UI. The bootstrapper does NOT > present the user with a Cancel button. Perhaps this is a reason why? > > Oracle VirtualBox (virtual network drivers). Compiled with WiX and uses > DIFxApp. RemoveExistingProducts is placed between InstallValidate and > InstallInitialize. This seems like the best place to put it. Uninstall > happens first, so there's no possibility of having both versions at the same > time. If the uninstall fails, then the old version remains. If the install > fails, then nothing remains on the computer (i.e. the old version is not > reinstalled). I don't see how this DIFxApp bug would be a problem in this > scenario since the old version isn't reinstalled. > > Western Digital SmartWare (some proprietary driver for external hard drive). > Compiled with Advanced Installer and uses DIFxApp. RemoveExistingProducts > is placed between InstallValidate and InstallInitialize, like with > VirtualBox. > > HP OfficeJet 8500. Compiled with WiX. RemoveExistingProducts is placed > after InstallInitialize so I suspect their installer has the same bug. > > Intel Network Connections driver, MS Virtual PC 2007, and VMware Workstation > 7: these products use Windows Installer but have proprietary, non-DIFxApp > custom actions for installing drivers. > > Logitech webcam driver, Dell V310 printer driver, NVIDIA graphics drivers, > ATI Radeon graphics driver, Intel HD graphics driver, Intel DH55HC drivers, > Intel HD Audio drivers: these products did not appear to use Windows > Installer for installing the drivers. (Some drivers had MSI files for > helper/utility programs but did not have the MsiDriverPackages table so I > conclude they do something else). > > Best regards, > > James Johnston > > -----Original Message----- > From: Quinton Tormanen [mailto:[hidden email]] > Sent: Friday, December 10, 2010 17:53 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old > driverwhen doing a major upgrade > > Thanks for digging into this further. The support e-mail for DIFx Tools is > [hidden email]. I have received responses over the years from > different people, but never any resolution to my problems. If that e-mail > address is no longer valid, then I can give you the addresses of the > specific people that replied. Please keep me posted on what you find out. > > --Quinton > > -----Original Message----- > From: James Johnston [mailto:[hidden email]] > Sent: Thursday, December 09, 2010 3:46 PM > To: [hidden email] > Subject: [WiX-users] DIFxApp does not properly rollback to the old > driverwhen doing a major upgrade > >> Hi, >> >> As some of you have probably noticed, there has been some discussion >> recently regarding problems with DIFxApp causing rollbacks. I did > some more >> investigation and was able to reliably reproduce the issue and come up > with >> a very good idea on what is causing the problem. All investigation > was done >> with the version of DIFxApp included with Windows DDK version > 7600.16385.1; >> note that this will also reproduce with the version included with WiX > 3.0 / >> 3.5. It was done on a clean Windows XP SP2 virtual machine with .NET >> Framework 2.0; however we have observed the same problems on Windows > 7. >> >> As far as I can tell, this is a bug in the DIFxApp DLLs and/or the WiX >> extension for DIFxApp. If anyone knows some good workarounds, or how > to >> report this to the proper channels and get it fixed it would be much >> appreciated! From what I can tell, there exist situations in any > DIFxApp >> setup program doing an upgrade where if the user cancels the setup at > a >> certain point (or there is an error in the installation of the new > product) >> then the user's system will be hosed and they would be unable to > uninstall >> the product without some involved technical support. >> >> If the bug can't be fixed or worked around, I don't see how DIFxApp is >> suitable for use in a commercial product that needs to support > upgrades >> (i.e. all products). And since DIFxApp isn't open source, I can't go > in and >> just fix the problem. Very frustrating! >> >> ... > > ---------------------------------------------------------------------------- > -- > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > WiX-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
I emailed [hidden email] and received this response.
"AFAIK, Difx doesn’t do anything to explicitly support RemoveExistingProducts. The scenario described on that page would require it to rollback a partial install of a new driver and the previous uninstall of the old driver. The limited functionality in the rollback mechanism of DIFx does not support that." So it looks like there isn't going to be a fix for this. Rob On 11/03/2011 14:00, Rob Hamflett wrote: > I appear to be looking at the same problem. I was able to reproduce it by hitting 'cancel' near the > end of an uninstall and letting it rollback. After that uninstallation failed. Performing a repair > fixed things. Did you email the difx team at the email address Quinton suggested, and if so, did > you ever hear anything back. > > Thanks, > Rob > > On 10/12/2010 20:37, James Johnston wrote: >> Seeing as how this seems to be a fundamental problem with DIFxApp not >> handling all the upgrade possibilities well, I was curious to see how other >> products do things and so I ripped apart some MSIs in Orca. I was looking >> to see if DIFxApp was set up the same way (CustomAction table). I also >> inspected the placement of the RemoveExistingProducts action since after my >> previous e-mail I believe that this plays a critical role in whether this >> corrupted system state may occur. Since I haven't seen any other indication >> or documentation on the Internet (a Google search for RemoveExistingProducts >> and DIFxApp reveals little), I thought it would be useful to report my >> findings so others can see what some commercial software is doing. My >> findings: >> >> All products using DIFxApp place MsiProcessDrivers and MsiCleanupOnSuccess >> actions in the normal places. CustomAction types are always the same. I >> identified the program used to compile the MSI by looking at the self-named >> custom actions each install tool tends to create (e.g. InstallShield has its >> own DLL with tons of custom actions). >> >> Refer to >> http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-ma >> jor-msi-upgrade/ to better understand the placement of >> RemoveExistingProducts action. Examining this table leads me to believe >> that placement between InstallInitialize and InstallFinalize is the best >> place, since a canceled setup will always leave the old version on the >> computer, no matter what. But this doesn't seem to work with DIFxApp due to >> its bug, as previously noted. >> >> My product (with the rollback problem): Compiled with WiX and uses DIFxApp. >> RemoveExistingProducts is placed after InstallInitialize. According to the >> previous link, a failure at any time (uninstall or reinstall) results in >> only the old version remaining: leaving system state exactly as it was >> found. Unfortunately, as previously noted, a bug in DIFxApp prevents this >> from happening. >> >> Apple Mobile Device Support (included with iTunes; presumably their iPod >> drivers, etc.). Compiled with WiX and uses DIFxApp. RemoveExistingProducts >> is placed after InstallFinalize. Probably the DIFxApp bug is not a problem >> here, because the new version is installed before the old version is >> uninstalled. An error in the new version setup (from DIFx or other source) >> would still leave the old version and its drivers untouched. An error in >> the old version uninstall would leave the new version& its drivers >> untouched. According to the table at the above link, the pitfall is that if >> the uninstall fails, then BOTH versions of the product remain installed on >> the computer. This seems like a very inconsistent, illogical state to be >> in; I can imagine that there could be some issues with a lot of products >> (including mine) if this were to happen. (Perhaps an MSI expert can >> convince me otherwise? Otherwise, I wonder if Apple's software can get >> itself in a bad way if I click Cancel at just the right moment.) >> >> Microsoft LifeCam (webcam driver). Don't know what compiled this; I didn't >> see any obvious indications. It uses DIFxApp. RemoveExistingProducts is >> placed after InstallInitialize. It therefore appears to be in a very >> similar configuration as with my product, and I believe it would leave the >> user's DIFxApp state inconsistent if the upgrade was canceled at just the >> right moment. It is interesting to note that the MSI file is wrapped by a >> bootstrapper: the MSI itself throws no UI. The bootstrapper does NOT >> present the user with a Cancel button. Perhaps this is a reason why? >> >> Oracle VirtualBox (virtual network drivers). Compiled with WiX and uses >> DIFxApp. RemoveExistingProducts is placed between InstallValidate and >> InstallInitialize. This seems like the best place to put it. Uninstall >> happens first, so there's no possibility of having both versions at the same >> time. If the uninstall fails, then the old version remains. If the install >> fails, then nothing remains on the computer (i.e. the old version is not >> reinstalled). I don't see how this DIFxApp bug would be a problem in this >> scenario since the old version isn't reinstalled. >> >> Western Digital SmartWare (some proprietary driver for external hard drive). >> Compiled with Advanced Installer and uses DIFxApp. RemoveExistingProducts >> is placed between InstallValidate and InstallInitialize, like with >> VirtualBox. >> >> HP OfficeJet 8500. Compiled with WiX. RemoveExistingProducts is placed >> after InstallInitialize so I suspect their installer has the same bug. >> >> Intel Network Connections driver, MS Virtual PC 2007, and VMware Workstation >> 7: these products use Windows Installer but have proprietary, non-DIFxApp >> custom actions for installing drivers. >> >> Logitech webcam driver, Dell V310 printer driver, NVIDIA graphics drivers, >> ATI Radeon graphics driver, Intel HD graphics driver, Intel DH55HC drivers, >> Intel HD Audio drivers: these products did not appear to use Windows >> Installer for installing the drivers. (Some drivers had MSI files for >> helper/utility programs but did not have the MsiDriverPackages table so I >> conclude they do something else). >> >> Best regards, >> >> James Johnston >> >> -----Original Message----- >> From: Quinton Tormanen [mailto:[hidden email]] >> Sent: Friday, December 10, 2010 17:53 >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old >> driverwhen doing a major upgrade >> >> Thanks for digging into this further. The support e-mail for DIFx Tools is >> [hidden email]. I have received responses over the years from >> different people, but never any resolution to my problems. If that e-mail >> address is no longer valid, then I can give you the addresses of the >> specific people that replied. Please keep me posted on what you find out. >> >> --Quinton >> >> -----Original Message----- >> From: James Johnston [mailto:[hidden email]] >> Sent: Thursday, December 09, 2010 3:46 PM >> To: [hidden email] >> Subject: [WiX-users] DIFxApp does not properly rollback to the old >> driverwhen doing a major upgrade >> >>> Hi, >>> >>> As some of you have probably noticed, there has been some discussion >>> recently regarding problems with DIFxApp causing rollbacks. I did >> some more >>> investigation and was able to reliably reproduce the issue and come up >> with >>> a very good idea on what is causing the problem. All investigation >> was done >>> with the version of DIFxApp included with Windows DDK version >> 7600.16385.1; >>> note that this will also reproduce with the version included with WiX >> 3.0 / >>> 3.5. It was done on a clean Windows XP SP2 virtual machine with .NET >>> Framework 2.0; however we have observed the same problems on Windows >> 7. >>> >>> As far as I can tell, this is a bug in the DIFxApp DLLs and/or the WiX >>> extension for DIFxApp. If anyone knows some good workarounds, or how >> to >>> report this to the proper channels and get it fixed it would be much >>> appreciated! From what I can tell, there exist situations in any >> DIFxApp >>> setup program doing an upgrade where if the user cancels the setup at >> a >>> certain point (or there is an error in the installation of the new >> product) >>> then the user's system will be hosed and they would be unable to >> uninstall >>> the product without some involved technical support. >>> >>> If the bug can't be fixed or worked around, I don't see how DIFxApp is >>> suitable for use in a commercial product that needs to support >> upgrades >>> (i.e. all products). And since DIFxApp isn't open source, I can't go >> in and >>> just fix the problem. Very frustrating! >>> >>> ... >> >> ---------------------------------------------------------------------------- >> -- >> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, >> new data types, scalar functions, improved concurrency, built-in packages, >> OCI, SQL*Plus, data movement tools, best practices and more. >> http://p.sf.net/sfu/oracle-sfdev2dev >> _______________________________________________ >> WiX-users mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> ------------------------------------------------------------------------------ >> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, >> new data types, scalar functions, improved concurrency, built-in packages, >> OCI, SQL*Plus, data movement tools, best practices and more. >> http://p.sf.net/sfu/oracle-sfdev2dev > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
I certainly understand that supporting this properly might require
non-trivial amounts of work for the DIFx team. They'd probably need to add significant additional logic for reinstalling the old driver during a rollback, for example. However, excuses like this really shouldn't cut it because at the end of the day, they break core, commonly-used functionality in Windows Installer. DIFxApp is intended for bundling drivers with applications. Applications are not frozen in time, and are continually updated to fix bugs and add new features. Users must upgrade applications. I'm guessing that is probably the reality for 99% of the people on this mailing list who use WiX. RemoveExistingProducts is the publicly documented, supported method of doing this in Windows Installer. The DIFxApp team has stated that upgrades are not supported via RemoveExistingProducts. Suppose we make the statement that a setup platform (like Windows Installer) is broken if application upgrades (e.g. major upgrades) do not work. We can then make the statement that DIFxApp breaks Windows Installer, because it does not support Windows Installer's method of upgrades. What is their proposed alternative for upgrades if not RemoveExistingProducts? Ask the user to manually uninstall the old version, and then install the new one?!? Realistically that is not a user-friendly solution and makes the setup look unprofessional. The workaround I found of placing RemoveExistingProducts between InstallValidate and InstallInitialize only makes the issue less severe. Placement of RemoveExistingProducts in this position is far from ideal, because if the user presses "Cancel" after the old product is uninstalled, then they will be left with no product at all on the computer (they would have to manually reinstall the old version). That violates one of the core design principles of Windows Installer, which is that it's supposed to be transactional and setup should be an all-or-nothing proposition. Pressing "Cancel" should *always* roll back the computer to exactly how it was before setup was begun - that includes restoring old versions of the software. The fact that Microsoft's hardware division is distributing MSI files susceptible to this bug is interesting. Other OEMs are doing it too. It wasn't just me that fell into this trap. In my opinion, if DIFxApp doesn't support commonly-used built-in Windows Installer actions then they need to document this in MSDN with big, bold letters so that setup authors don't fall into this trap which appears to be so easy to fall into, and so time consuming to debug! This is something that needs to be front page and center in the documentation for ANY DIFxApp-related documentation (e.g. the WiX extension, the DIFxApp documentation in MSDN, other setup authoring programs that build on MSI/DIFx, etc). I'll bet most setup authors using DIFxApp are also using RemoveExistingProducts because they didn't know they weren't supposed to do that. Every setup I examined had RemoveExistingProducts and was either affected by the bug, or the setup authors found my workaround on their own, or got lucky. (Any maintainers for WiX documentation want to add this to the DIFx extension documentation? I wouldn't know where to start with this process.) Perhaps if enough people complain, they will fix the design fault in DIFxApp. General rant: this is just another example of Microsoft products not working well together. For a marketing campaign slogan of "better together", they seem to be doing rather poorly at that at times. There seems to be an acute lack of viewing the big picture when looking at small details like this. A second example: I recently had the misfortune of having to implement drag-and-drop support in our application. Who knew dragging and dropping a simple bitmap could be so complicated?! Try implementing simple drag-and-drop code for a bitmap in C# / .NET / WinForms. Then try dragging/dropping to/from Microsoft Word. Hint: it won't work. This is because MS Word only supports device independent bitmaps, while .NET only supports device dependent bitmaps. I reported this issue to the Visual Studio team: http://connect.microsoft.com/VisualStudio/feedback/details/652248/. And they said they won't fix it: it is by design. I guess they figured it would be enough to impose a requirement that other programs also support DDBs. The Microsoft Office team is apparently isolating themselves from customers because I found no place to properly report a bug like I did in Visual Studio (they probably want more of my money first before any form of two-way communication can begin). Maybe they think it is enough to require that other programs support DIBs. Classic example of pointing the finger at the other party, I guess. And yet, at the end of the day - drag-and-drop between two flagship Microsoft products does not work. It's another example of not seeing the big picture and refusing to do anything about it when customers try to point this out. It's very frustrating to deal with. (Heck... if one of those two products was open source, I would have seriously considered fixing it and submitting a patch...) James -----Original Message----- From: Rob Hamflett [mailto:[hidden email]] Sent: Wednesday, April 27, 2011 08:00 To: [hidden email] Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade I emailed [hidden email] and received this response. "AFAIK, Difx doesn't do anything to explicitly support RemoveExistingProducts. The scenario described on that page would require it to rollback a partial install of a new driver and the previous uninstall of the old driver. The limited functionality in the rollback mechanism of DIFx does not support that." So it looks like there isn't going to be a fix for this. Rob On 11/03/2011 14:00, Rob Hamflett wrote: > I appear to be looking at the same problem. I was able to reproduce > it by hitting 'cancel' near the end of an uninstall and letting it > rollback. After that uninstallation failed. Performing a repair > fixed things. Did you email the difx team at the email address Quinton suggested, and if so, did you ever hear anything back. > > Thanks, > Rob > > On 10/12/2010 20:37, James Johnston wrote: >> Seeing as how this seems to be a fundamental problem with DIFxApp not >> handling all the upgrade possibilities well, I was curious to see how >> other products do things and so I ripped apart some MSIs in Orca. I >> was looking to see if DIFxApp was set up the same way (CustomAction >> table). I also inspected the placement of the RemoveExistingProducts >> action since after my previous e-mail I believe that this plays a >> critical role in whether this corrupted system state may occur. >> Since I haven't seen any other indication or documentation on the >> Internet (a Google search for RemoveExistingProducts and DIFxApp >> reveals little), I thought it would be useful to report my findings >> so others can see what some commercial software is doing. My >> findings: >> >> All products using DIFxApp place MsiProcessDrivers and >> MsiCleanupOnSuccess actions in the normal places. CustomAction types >> are always the same. I identified the program used to compile the >> MSI by looking at the self-named custom actions each install tool >> tends to create (e.g. InstallShield has its own DLL with tons of custom >> >> Refer to >> http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts- >> in-a-ma jor-msi-upgrade/ to better understand the placement of >> RemoveExistingProducts action. Examining this table leads me to >> believe that placement between InstallInitialize and InstallFinalize >> is the best place, since a canceled setup will always leave the old >> version on the computer, no matter what. But this doesn't seem to >> work with DIFxApp due to its bug, as previously noted. >> >> My product (with the rollback problem): Compiled with WiX and uses >> RemoveExistingProducts is placed after InstallInitialize. According >> to the previous link, a failure at any time (uninstall or reinstall) >> results in only the old version remaining: leaving system state >> exactly as it was found. Unfortunately, as previously noted, a bug >> in DIFxApp prevents this from happening. >> >> Apple Mobile Device Support (included with iTunes; presumably their >> iPod drivers, etc.). Compiled with WiX and uses DIFxApp. >> RemoveExistingProducts is placed after InstallFinalize. Probably the >> DIFxApp bug is not a problem here, because the new version is >> installed before the old version is uninstalled. An error in the new >> version setup (from DIFx or other source) would still leave the old >> the old version uninstall would leave the new version& its drivers >> untouched. According to the table at the above link, the pitfall is >> that if the uninstall fails, then BOTH versions of the product remain >> installed on the computer. This seems like a very inconsistent, >> illogical state to be in; I can imagine that there could be some >> issues with a lot of products (including mine) if this were to >> happen. (Perhaps an MSI expert can convince me otherwise? >> Otherwise, I wonder if Apple's software can get itself in a bad way >> if I click Cancel at just the right moment.) >> >> Microsoft LifeCam (webcam driver). Don't know what compiled this; I >> didn't see any obvious indications. It uses DIFxApp. >> RemoveExistingProducts is placed after InstallInitialize. It >> therefore appears to be in a very similar configuration as with my >> product, and I believe it would leave the user's DIFxApp state >> inconsistent if the upgrade was canceled at just the right moment. >> It is interesting to note that the MSI file is wrapped by a >> bootstrapper: the MSI itself throws no UI. The bootstrapper does NOT >> present the user with a Cancel button. Perhaps this is a reason why? >> >> Oracle VirtualBox (virtual network drivers). Compiled with WiX and >> uses DIFxApp. RemoveExistingProducts is placed between >> InstallValidate and InstallInitialize. This seems like the best >> place to put it. Uninstall happens first, so there's no possibility >> of having both versions at the same time. If the uninstall fails, >> then the old version remains. If the install fails, then nothing >> remains on the computer (i.e. the old version is not reinstalled). I >> don't see how this DIFxApp bug would be a problem in this scenario since >> >> Western Digital SmartWare (some proprietary driver for external hard drive). >> Compiled with Advanced Installer and uses DIFxApp. >> RemoveExistingProducts is placed between InstallValidate and >> InstallInitialize, like with VirtualBox. >> >> HP OfficeJet 8500. Compiled with WiX. RemoveExistingProducts is >> placed after InstallInitialize so I suspect their installer has the same bug. >> >> Intel Network Connections driver, MS Virtual PC 2007, and VMware >> Workstation >> 7: these products use Windows Installer but have proprietary, >> non-DIFxApp custom actions for installing drivers. >> >> Logitech webcam driver, Dell V310 printer driver, NVIDIA graphics >> drivers, ATI Radeon graphics driver, Intel HD graphics driver, Intel >> DH55HC drivers, Intel HD Audio drivers: these products did not >> appear to use Windows Installer for installing the drivers. (Some >> drivers had MSI files for helper/utility programs but did not have >> the MsiDriverPackages table so I conclude they do something else). >> >> Best regards, >> >> James Johnston >> >> -----Original Message----- >> From: Quinton Tormanen [mailto:[hidden email]] >> Sent: Friday, December 10, 2010 17:53 >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] DIFxApp does not properly rollback to the >> old driverwhen doing a major upgrade >> >> Thanks for digging into this further. The support e-mail for DIFx >> Tools is [hidden email]. I have received responses over the >> years from different people, but never any resolution to my problems. >> If that e-mail address is no longer valid, then I can give you the >> addresses of the specific people that replied. Please keep me posted on >> >> --Quinton >> >> -----Original Message----- >> From: James Johnston [mailto:[hidden email]] >> Sent: Thursday, December 09, 2010 3:46 PM >> To: [hidden email] >> Subject: [WiX-users] DIFxApp does not properly rollback to the old >> driverwhen doing a major upgrade >> >>> Hi, >>> >>> As some of you have probably noticed, there has been some discussion >>> recently regarding problems with DIFxApp causing rollbacks. I did >> some more >>> investigation and was able to reliably reproduce the issue and come >>> up >> with >>> a very good idea on what is causing the problem. All investigation >> was done >>> with the version of DIFxApp included with Windows DDK version >> 7600.16385.1; >>> note that this will also reproduce with the version included with >>> WiX >> 3.0 / >>> 3.5. It was done on a clean Windows XP SP2 virtual machine with >>> .NET Framework 2.0; however we have observed the same problems on >>> Windows >> 7. >>> >>> As far as I can tell, this is a bug in the DIFxApp DLLs and/or the >>> WiX extension for DIFxApp. If anyone knows some good workarounds, >>> or how >> to >>> report this to the proper channels and get it fixed it would be much >>> appreciated! From what I can tell, there exist situations in any >> DIFxApp >>> setup program doing an upgrade where if the user cancels the setup >>> at >> a >>> certain point (or there is an error in the installation of the new >> product) >>> then the user's system will be hosed and they would be unable to >> uninstall >>> the product without some involved technical support. >>> >>> If the bug can't be fixed or worked around, I don't see how DIFxApp >>> is suitable for use in a commercial product that needs to support >> upgrades >>> (i.e. all products). And since DIFxApp isn't open source, I can't >>> go >> in and >>> just fix the problem. Very frustrating! >>> >>> ... >> >> --------------------------------------------------------------------- >> ------- >> -- >> Oracle to DB2 Conversion Guide: Learn learn about native support for >> PL/SQL, new data types, scalar functions, improved concurrency, >> built-in packages, OCI, SQL*Plus, data movement tools, best practices and >> http://p.sf.net/sfu/oracle-sfdev2dev >> _______________________________________________ >> WiX-users mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> --------------------------------------------------------------------- >> --------- Oracle to DB2 Conversion Guide: Learn learn about native >> support for PL/SQL, new data types, scalar functions, improved >> concurrency, built-in packages, OCI, SQL*Plus, data movement tools, >> best practices and more. >> http://p.sf.net/sfu/oracle-sfdev2dev > > > ---------------------------------------------------------------------- > -------- > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit for your > organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d ---------------------------------------------------------------------------- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
In reply to this post by James Johnston
I don't think there's much the DIFXApp team can do to make the lib foolproof/robust.
I'm pretty sure that DIFXApp is simply a wrapper around the win32 setupapi API. I've used both for the last few years. In many cases, I've found that even when using the win32 api directly, it's not possible to rollback uninstalled drivers, the exact behavior is very platform dependent. In many cases, the api returns "reboot required", at which point there is no chance of reinstalling the driver in the same session. This can be because the driver service was marked for deletion, so SCM will deny recreating the service until after a reboot. I'd be very surprised if DIFXApp can work around this. |
|
I believe that's it. We opened a case with the DIFXApp team on this issue last year and got a will not fix response but no real explanation. Thank you!
Thanks, Tom -----Original Message----- From: jjbean [mailto:[hidden email]] Sent: Friday, July 01, 2011 3:27 PM To: [hidden email] Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old driver when doing a major upgrade I don't think there's much the DIFXApp team can do to make the lib foolproof/robust. I'm pretty sure that DIFXApp is simply a wrapper around the win32 setupapi API. I've used both for the last few years. In many cases, I've found that even when using the win32 api directly, it's not possible to rollback uninstalled drivers, the exact behavior is very platform dependent. In many cases, the api returns "reboot required", at which point there is no chance of reinstalling the driver in the same session. This can be because the driver service was marked for deletion, so SCM will deny recreating the service until after a reboot. I'd be very surprised if DIFXApp can work around this. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/DIFxApp-does-not-properly-rollback-to-the-old-driver-when-doing-a-major-upgrade-tp5821359p6538903.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
|
In reply to this post by jjbean
On 01-Jul-11 15:27, jjbean wrote:
> In many cases, I've found that even when using the win32 api directly, it's > not possible to rollback uninstalled drivers, the exact behavior is very > platform dependent. In many cases, the api returns "reboot required", at > which point there is no chance of reinstalling the driver in the same > session. This can be because the driver service was marked for deletion, so > SCM will deny recreating the service until after a reboot. The best solution possible is to stop and unload your driver, if at all possible. Otherwise, the closest you'll be able to get is to force a reboot, even in the case of a rollback. -- sig://boB http://joyofsetup.com/ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/wix-users |
| Powered by Nabble | Edit this page |
