What was the exit code of that setup? I'd expect 3010 if it was going to do a reboot. Did it reboot after the install that this log is from? It's still not clear to me if it should be rebooting but isn't or not rebooting but you think it should.
You shouldn't need a ScheduleReboot action if Windows is going to do one anyway, but I was thinking that a ScheduleReboot (at the "end") with a condition of ReplacedInUseFile might be a useful test. --------------- Phil Wilson On Mon, Feb 17, 2014 at 11:43 AM, Suryadeep Biswal <surya6...@hotmail.com> wrote: > Thank you for the pointers, Phil. I will give ReplacedInUseFiles a try. > I do see logs from RM saying that a reboot will be necessary. I am not sure > if a ScheduleReboot custom action needs to be defined with the proper > conditions for this reboot to happen. Currently, i do not have a > "ScheduleReboot" action in the wix file.I will check internally if the logs > can be shared. Meanwhile, i am pasting relevant logs from RM. > MSI (s) (60:04) [15:50:59:190]: RESTART MANAGER: Will attempt to shut down > and restart applications in no UI modes.MSI (s) (60:04) [15:50:59:190]: > RESTART MANAGER: Did detect that a critical application holds file[s] in use, > so a reboot will be necessary.MSI (s) (60:04) [15:50:59:190]: Note: 1: 1610 > MSI (s) (60:04) [15:50:59:191]: RESTART MANAGER: The user chose to go on with > the installation, although a reboot will be > required.........................Info 1903.Scheduling reboot operation: > Deleting file C:\Config.Msi\28253a39.rbf. Must reboot to complete operation. > I also see this at the end: > MSI (s) (60:B4) [15:51:30:422]: Incrementing counter to disable shutdown. > Counter after increment: 0MSI (s) (60:B4) [15:51:30:422]: Note: 1: 1402 2: > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts > 3: 2 MSI (s) (60:B4) [15:51:30:424]: Note: 1: 2265 2: 3: -2147287035 MSI > (s) (60:B4) [15:51:30:434]: Note: 1: 1402 2: > HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts > 3: 2 MSI (s) (60:B4) [15:51:30:435]: Decrementing counter to disable > shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: > -1MSI (s) (60:B4) [15:51:30:435]: Post-install cleanup: removing installer > file 'C:\Windows\Installer\6e05a.msi'MSI (s) (60:B4) [15:51:30:436]: > Post-install cleanup: removing installer folder > 'C:\Windows\Installer\{A4567957-54CC-460C-860D-7477702586BF}\' (if empty)MSI > (s) (60:B4) [15:51:30:436]: Note: 1: 2318 2: MSI (s) (60:B4) [15:51:30:437]: > Destroying RemoteAPI object.MSI (s) (60:FC) [15:51:30:437] : Custom Action Manager thread ending.MSI (c) (E8:DC) [15:51:30:440]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1 > Regards,Surya >> Date: Mon, 17 Feb 2014 10:54:21 -0800 >> From: phildgwil...@gmail.com >> To: wix-users@lists.sourceforge.net >> Subject: Re: [WiX-users] Scheduling a system reboot on restart manager >> failure >> >> You may be able to use some combination of MSIRMSHUTDOWN and >> MSIRESTARTMANAGERCONTROL to get the result you want. Having said that, >> you seem to be saying that MSI/RM is already scheduling a reboot if it >> doesn't shut things down properly, but that seems to be the problem >> you're trying to solve, so perhaps you could clarify why you seem to >> want to do what is already happening anyway. It's definitely worth >> investigating why those processes won't shut down nicely, and if they >> can integrate with RM and preserve their internal state. >> >> The ReplacedInUseFiles property might be what you need as an >> indication that a reboot is needed. I believe that when there is no UI >> the ScheduleReboot action does a reboot without asking (it is silent, >> after all) so a verbose log might be useful in the case that it >> appears a reboot is needed but doesn't happen. >> --------------- >> Phil Wilson >> >> >> On Sat, Feb 15, 2014 at 12:03 PM, Suryadeep Biswal >> <surya6...@hotmail.com> wrote: >> > Hi, >> > I need some help with coordinating a system reboot with specific restart >> > manager error codes during a major upgrade of a MSI.To be more specific - >> > 1. Suppose "A.dll", a binary which is installed by the MSI (and is >> > upgraded by higher versions) is loaded into memory by several processes.2. >> > While performing a major upgrade to a MSI which contains a higher version >> > of A.dll, Restart manager tries to shutdown and restart all these >> > processes. In some cases I have seen this failing and a message from RM in >> > the installation logs stating that a reboot is needed. we are investigate >> > the cause for these failures but from what i have read, it can be happen >> > for cases where the process running on a different session or under a >> > different user credential. >> > What i would ideally like is to schedule a reboot in case restart manager >> > fails to shut down all the processes that are using any dll which is being >> > replaced. If there was a MSI property indicating the return code of >> > Restart Manager shutdown action, i could have simply used it, but i could >> > not find any such property. My goal is to avoid unnecessary reboots (thus >> > discarding the solution of reboot always). Is there a way to do it without >> > duplicating the Installer - Restart manager interaction code (in which >> > case i can write the error code into a WIX property)? >> > Please note that this is a silent upgrade and there are no UIs. Thanks for >> > any advice! >> > Regards,Surya >> > ------------------------------------------------------------------------------ >> > Android apps run on BlackBerry 10 >> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> > Now with support for Jelly Bean, Bluetooth, Mapview and more. >> > Get your Android app in front of a whole new audience. Start now. >> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > WiX-users mailing list >> > WiX-users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/wix-users >> >> ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users