1
votes

I am building a managed code bootstrapper application with WiX Burn 3.8. One of the PackageGroups includes ExePackage elements to install Windows Installer 4.5 on Windows Server 2003. The x86 version of the package is shown below. (The following code snippets have been slightly altered to avoid exposing any sensitive client information.)

<!-- Microsoft Windows Installer 4.5 Redistributable x86 -->
<ExePackage Id="WindowsServer2003_KB942288_v4_x86.exe"
            DisplayName="Microsoft Windows Installer Redistributable x86"
            SourceFile="{a_path}\WindowsServer2003-KB942288-v4-x86.exe"
            Name="redist\Windows_Installer\WindowsServer2003-KB942288-v4-x86.exe"
            InstallCommand="/q /norestart"
            RepairCommand="/q /norestart"
            DetectCondition="VersionMsi &gt;= v4.5 AND Not VersionNT64"
            InstallCondition="InstallSqlExpress = &quot;yes&quot; AND VersionMsi &lt; v4.5 AND VersionNT = v5.2 AND Not VersionNT64"
            Compressed="no"
            DownloadUrl="http://downloads.{mycompany}.com/{some_path}/WindowsServer2003-KB942288-v4-x86.exe"
            Permanent="yes"
            SuppressSignatureVerification="no">
  <!-- Exit codes
       0 = Success, no reboot required
    3010 = Success, reboot required
  -->
  <ExitCode Value="0" Behavior="success" />
  <ExitCode Value="3010" Behavior="forceReboot" />
  <ExitCode Behavior="error"/>
</ExePackage>

Burn does not seem to be restarting or resuming after restart as advertised, and I'm not sure why. I'm passing the /q and /norestart command line parameters and identifying a 3010 exit code as requiring a reboot, as specified on MSDN's Windows Installer Redistributables documentation.

The installer log (trimmed of timestamp information below) shows that the restart is happening. You can see a combination of log events from the Burn engine and my managed bootstrapper application below:

Restart requested by WindowsServer2003_KB942288_v4_x86.exe: RestartInitiated
Applied execute package: WindowsServer2003_KB942288_v4_x86.exe, result: 0x0, restart: Initiated
ApplyComplete.  Result: None
State changed.  Status: 0
Must reboot.  Showing warning.
Apply complete, result: 0x0, restart: Initiated, ba requested restart:  No
Exiting UI.
Shutting down, exit code: 0x0
Shutting down.  Restart: RestartInitiated
Bootstrapper application requested restart at shutdown. Planned to restart already: No.
Exit code: 0x0, restarting: Yes
Restarting computer...
=======================================

The Burn engine does write a Registry key to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. The GUID key has the following value, which looks like it should resume the bootstrapper after the restart:

"C:\Documents and Settings\All Users\Application Data\Package Cache\{a_guid}\{my_burn_installer}.exe" /burn.log.append "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{my_installer}{timestamp}.log" "/PARENTEXE=C:\Documents and Settings\Administrator\Desktop\{my_nsis_installer}.exe" {two_more_command_line_params} /burn.runonce

I have checked the file path listed in the Registry key, and I see my Burn-based installer and a state.rsm file there. However, the system does not restart when the log says it is going to, and the installer does not resume after manually restarting the system.

As you can see from above, the Burn bootstrapper is wrapped in an NSIS package to install the Windows Imaging Component, which is a prerequisite for installing .NET Framework 4 on Windows Server 2003. See this StackOverflow question for more details on why that is necessary. I don't believe that this the source of the problem because the Burn-based bootstrapper runs from the package cache, but I could be wrong.

I'm testing on a 32-bit Windows Server 2003 R2 Standard Edition Hyper-V virtual machine with no updates applied.

1

1 Answers

2
votes

Use WiX v3.9. It includes the fix for when the RunOnce key is too long on XP/2003 and the ability to install multiple prereq packages (as I explained in the linked question).

As for the computer not restarting, that's a mystery. Since Burn doesn't force applications to close when calling InitiateSystemShutdownEx, an application is probably blocking shutdown.