Thank you for the insight, Phil!I scanned through the logs again and i do see a 
"Info 1903" logged.
MSI (s) (60:04) [15:51:30:283]: Verifying accessibility of file: 
28253a39.rbfInfo 1903.Scheduling reboot operation: Deleting file 
C:\Config.Msi\28253a39.rbf. Must reboot to complete operation.
According to this blog post: 
http://blogs.msdn.com/b/windows_installer_team/archive/2005/09/19/470980.aspx - 
QuestionWhat happens when a file is in use on uninstall? If it is marked for 
deleting in place on reboot. will a reboot be required before an install of the 
same file by another install? If it is first moved to a temp directory or 
renamed and then marked for delete on reboot, is a reboot not required before 
an install of the same file by another install?
AnswerWhen you uninstall MSI and the file being uninstalled is in use and all 
of the following are false
The files in use are not executables.The installer is not actually trying to 
install those files.The process holding those files is the process invoking the 
installation.The process holding those files is one that does not have a window 
with a title associated with it.the user will be given a FilesInUse Dialog with 
the option to RETRY, CANCEL or IGNORE.If you choose Ignore,
the file in question will be renamed and placed in Folder Config.rbf where it 
will be deleted upon reboot.An entry such as the following will be placed in 
the log per Logging of Reboot Requests [Windows Installer]MSI (s) (BC:24) 
[15:23:14:208]: Verifying accessibility of file: 2841496c.rbf
Info 1903. Scheduling reboot operation: Deleting file 
D:\Config.Msi\2841496c.rbf. Must reboot to complete operation.I any of the 
first four bullets are true or if this is a quiet uninstall, the above Ignore 
case will happen automatically.
1. Given that this is a silent install (which according to the blog post is 
treated as user choosing 'ignore'), is the installer choosing to ignore the 
reboot? 2. I have seen this issue only on customer machines so far. when i try 
for a local repro, the process that is holding onto the dll is always killed by 
Restart Manager. Is there a way to consistently repro it?3. Would adding an 
explicit "ScheduleReboot" fix the issue?
Regards,Surya
> Date: Tue, 18 Feb 2014 09:46:01 -0800
> From: phildgwil...@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Scheduling a system reboot on restart manager        
> failure
> 
> The difficulty is that you can see log entries saying a reboot is
> required but something will happen later that reverses that. Windows
> will not commit to a reboot if it turns out later to be unnecessary
> (because the app shut down, a Dll unloaded, or the app could be
> isolated in memory and release the in-use files). You can't use the
> reboot entry in the log as evidence that there is a bug somewhere. If
> the exit code doesn't say a reboot is necessary, it's not clear to me
> that other entries in the log mean that there is a bug anywhere.
> ---------------
> Phil Wilson
> 
> 
> On Mon, Feb 17, 2014 at 1:09 PM, Suryadeep Biswal <surya6...@hotmail.com> 
> wrote:
> > The exit code seems to be 0.
> > Action ended 15:51:30: INSTALL. Return value 1.MSI (s) (60:04) 
> > [15:51:30:358]: Note: 1: 1707 MSI (s) (60:04) [15:51:30:358]: Product: **** 
> > -- Installation completed successfully.
> > MSI (s) (60:04) [15:51:30:358]: Windows Installer installed the product. 
> > Product Name: ****. Product Version: ****. Product Language: ****. 
> > Manufacturer: ****. Installation success or error status: 0.
> >>>Did it reboot after the install that this log is from?No, it did not.
> >>>It's still not clear to me if it should be rebooting but isn't or not 
> >>>rebooting but you think it should.Aren't both the same thing? It should be 
> >>>rebooting according to the logs, but it actually does not.
> > Regards,Surya
> >> Date: Mon, 17 Feb 2014 12:09:26 -0800
> >> From: phildgwil...@gmail.com
> >> To: wix-users@lists.sourceforge.net
> >> Subject: Re: [WiX-users] Scheduling a system reboot on restart manager     
> >>    failure
> >>
> >> 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
> >
> > ------------------------------------------------------------------------------
> > 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

Reply via email to