[wix-users] Burn reboot logic

Joel Budreau joel.budreau at gmail.com
Fri Dec 2 11:13:07 PST 2016


Ahh, so it's saved as the registry key:
"HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<GUID>.RebootRequired".

Thanks!

On Fri, Dec 2, 2016 at 12:53 AM, Andreas Hirth <a_hirth at foxitsoftware.com>
wrote:

> Yes, Burn stores a value in the Registry to remember the reboot pending.
> We faced exactly the same problem like you on our machines used for
> automatic regression tests. The way we fixed this is the following code
> snippet in out PowerShell installation script that comes after the setup
> completed:
>
> if($proc.ExitCode-eq3010){# in case of reboot required return code we
> patch uninstall entry in the registry # to enable a later uninstallation
> without rebooting$uninstallKey=(Get-ChildItemHKLM:\SOFTWARE\Wow6432N
> ode\Microsoft\Windows\CurrentVersion\Uninstall)|where{$_.
> GetValue('BundleCachePath')-like"*$($setupExe.Name)"}$
> rebootKey=(Get-Item(($uninstallKey-replace'HKEY_LOCAL_MACHINE','HKLM:')+'.
> RebootRequired'))Remove-Item($rebootKey-replace'HKEY_LOCAL_
> MACHINE','HKLM:')}
> Exported from Notepad++
>
>
>
>
>
>
> $proc is returned by Start-Process for the setup.exe.
> As you can see we search for the right ARP entry by using the unique name
> of our setup.exe. You could also use the product code but this approach was
> easier for us and is good enough.
>
> Hope that helps.
>
> -- Andreas
>
>
>
> Am 02.12.2016 um 04:31 schrieb Joel Budreau:
>
>> I guess my question is, where does Burn track that? (I'll likely end up
>> looking through the source myself)
>>
>> I'd like to be able to test installs and uninstalls without needing to
>> reboot in the middle (I'm not trying to test the app itself). I'm hoping
>> that there's a registry value or something that I can delete to make Burn
>> forget that packages had previously requested a reboot.
>>
>> On Thu, Dec 1, 2016 at 7:20 PM, Bob Arnson <bob at firegiant.com> wrote:
>>
>> In addition to "system level" reboot pending detection (from WU/AU
>>> engine), Burn tracks when a particular bundle ended with a reboot
>>> required
>>> and won't run apply for that bundle until a reboot has happened.
>>> https://github.com/wixtoolset/issues/issues/5332
>>>
>>> -----Original Message-----
>>> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On
>>> Behalf
>>> Of Joel Budreau
>>> Sent: Thursday, 1 December, 2016 22:08
>>> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
>>> Subject: [wix-users] Burn reboot logic
>>>
>>> I'm trying to figure out how burn decides that a reboot is required, and
>>> therefore won't 'apply' my uninstall request...
>>>
>>> Scenario:
>>> I have a burn bootstrapper with custom WPF/XAML/C# UI that installs a
>>> single MSI. On install the MSI returns 3010 - Install successful, reboot
>>> required. Burn somehow remembers this value, and when I try to run an
>>> uninstall (without rebooting in between) I see this in the bootstrapper
>>> log
>>> file:
>>> ...
>>> Plan complete, result: 0x0
>>> Apply begin
>>> Apply complete, result: 0x8007015e, restart: Required, ba requested
>>> restart: No
>>> ...
>>>
>>> The engine somehow determines that the Apply phase can't be run because a
>>> reboot is still pending. I've googled this forever and haven't been able
>>> to
>>> find an answer. I'm sure I'm missing something simple.
>>>
>>> Thanks,
>>> Joel
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>



More information about the wix-users mailing list