Looking at a complete verbose log may help. Otherwise there's not enough info here to say what's wrong. It doesn't help much to say that the CA is "something like this". For example, what type is it? We could assume it's deferred, but it's better to know for a fact.
1. I assume the V1 install has an uninstall CA to remove the driver. If so, at the end of REP of V1 there will be no driver on the system. Does it uninstall the driver? 2. When V2 fails, has it installed the V2 version of the kernel driver? If so, does it have a rollback custom action to remove it? At the point where V2 fails we don't know whether there is a V2 kernel driver on the system or not, and if there is a rollback CA in V2 to uninstall it. Anyway the log will show the sequence of events and conditions that resulted in this situation so you should be able to why V1's re-install of the driver didn't happen. If it says the condition evaluated to false, it occurs to me that the re-install of V1 may actually be part of the rollback transaction, in which case you need a rollback CA to re-install the driver, not an install CA. However I'm not sure of that - I forget the details of how that all hangs together. Phil Wilson On Thu, Jan 9, 2014 at 3:43 PM, Suryadeep Biswal <surya6...@hotmail.com>wrote: > We ship a MSI which supports upgrades. We schedule the > RemoveExistingProducts > custom action after InstallInitialize using MajorUpgrade > element – > > > > <MajorUpgrade > > > Schedule="afterInstallInitialize" > > > AllowDowngrades="yes" /> > > > > The MSI performs a variety of things including GACing, > writing to registry and also includes a custom action which is used to > install > a kernel mode driver. > > We have been running into an issue in the following scenario > - > > > > 1. > V1 MSI is installed first. > > 2. > V2 MSI is installed at a later point. > > a. For > cases, there is a bug in v2 MSI, we expect the MSI installation to roll > back > and finally leave the system with v1 installed. > > b. We > see everything rolling back to v1 (including the registry keys, file > versions > etc.) except for the kernel driver. After the previous rollback, we no > longer > see the kernel mode driver. > > > > In the log file, I did not see the custom action being run > when v1 is reinstalled. > > InstallExecuteSequence for the custom action that > installs the kernel driver looks something like this – > > > > <Custom Action="InstallDrivers" > Before="WriteRegistryValues" > > > (NOT REMOVE) AND > Privileged > > > </Custom> > > > > I am wondering if the conditions have something to do with > this? I would appreciate any help in figuring out the root cause for this > issue. > > > > Regards, > > Surya > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
