MSI 4.5 Chaining doesn't work

[Christopher_Pai]

Test Bed:
Super clean install of XP SP3-VL/sysprep via MSDN on Hyper-V and snapshotted after minisetup.

Install:
Micro1.msi - Simple Basic MSI test project containing a single keyfile
Micro2.msi - Same as above
Product1.msi - Simple Basic MSI that references the above 2 packages and bootstraps MSI 4.5.

If I run setup.exe, it installs MSI 4.5 and doesn't ask for a reboot. I then install Product1.msi and it never installs Micro1.msi or Micro2.msi. At the end of the install, it asks for a reboot.

After the reboot, if I uninstall Product1 and reinstall, Micro1 and Micro2 get installed.

But let's say I roll the machine back to the snapshot, run setup.exe and install MSI 4.5 and force a reboot by cancelling at InstallWelcomePassword. Now I run setup.exe again and this time when Product1 installs it properly installs Micro1 and Micro2.

[Christopher_Pai]

Log from successful install:

[CODE]MSI (s) (6C:E0) [15:21:54:749]: MainEngineThread is returning 0
=== Verbose logging started: 7/22/2008 15:21:55 Build type: SHIP UNICODE 4.05.6001.00 Calling process: C:\WINDOWS\Installer\MSI4.tmp ===
MSI (c) (D4:90) [15:21:55:624]: Resetting cached policy values
MSI (c) (D4:90) [15:21:55:624]: Machine policy value 'Debug' is 0
MSI (c) (D4:90) [15:21:55:624]: ******* RunEngine:
******* Product: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{12B75389-1F72-4A6C-8F2A-545EFD759D06}\micro2.msi
******* Action:
******* CommandLine: **********
MSI (c) (D4:90) [15:21:55:624]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (D4:90) [15:21:58:624]: Failed to grab execution mutex. System error 258.
MSI (c) (D4:90) [15:21:58:655]: Cloaking enabled.
MSI (c) (D4:90) [15:21:58:655]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (D4:90) [15:21:58:655]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (6C:D4) [15:21:58:671]: Running installation inside multi-package transaction C:\Documents and Settings\Administrator\Desktop\DISK1\Product1.msi
MSI (s) (6C:D4) [15:21:58:671]: Grabbed execution mutex.
MSI (s) (6C:B0) [15:21:58:702]: Resetting cached policy values
MSI (s) (6C:B0) [15:21:58:702]: Machine policy value 'Debug' is 0
MSI (s) (6C:B0) [15:21:58:702]: ******* RunEngine:
******* Product: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{12B75389-1F72-4A6C-8F2A-545EFD759D06}\micro2.msi
******* Action:
******* CommandLine: **********[/CODE]

Log from Failed install:

[CODE]MSI (s) (E0:28) [15:01:36:170]: Propagated Reboot to the client/parent install.
MSI (s) (E0:28) [15:01:36:170]: Value of RebootAction property is 1
MSI (s) (E0:28) [15:01:36:170]: Windows Installer requires a system restart. Product Name: Product1. Product Version: 1.00.0000. Product Language: 1033. Type of System Restart: 1. Reason for Restart: 2.

MSI (s) (E0:28) [15:01:36:202]: MainEngineThread is returning -1
1: RollbackCleanup 2: Removing backup files 3: File: [1]
MSI (s) (E0:D0) [15:01:36:327]: User policy value 'DisableRollback' is 0
MSI (s) (E0:D0) [15:01:36:327]: Machine policy value 'DisableRollback' is 0
MSI (s) (E0:D0) [15:01:36:327]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (E0:D0) [15:01:36:467]: Creating MSIHANDLE (25) of type 790536 for thread 1232
MSI (s) (E0:1C) [15:01:36:467]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI4A.tmp, Entrypoint: ISChainPackagesCleanup
MSI (s) (E0:1C) [15:01:36:655]: Closing MSIHANDLE (25) of type 790536 for thread 1232
MSI (s) (E0:D0) [15:01:36:733]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (E0:D0) [15:01:36:733]: Restoring environment variables
MSI (s) (E0:D0) [15:01:36:733]: Closing MSIHANDLE (24) of type 790535 for thread 296
MSI (s) (E0:D0) [15:01:36:733]: Calling SRSetRestorePoint API. dwRestorePtType: 0, dwEventType: 103, llSequenceNumber: 3, szDescription: "".
MSI (s) (E0:D0) [15:01:36:733]: The call to SRSetRestorePoint API succeeded. Returned status: 0.
MSI (c) (C8:60) [15:01:36:748]: Back from server. Return value: -1
MSI (c) (C8:60) [15:01:36:748]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (C8:60) [15:01:36:748]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'.
Action ended 15:01:36: ExecuteAction. Return value 1.
MSI (c) (C8:60) [15:01:36:764]: Doing action: SetupCompleteSuccess
Action 15:01:36: SetupCompleteSuccess. [/CODE]

I'm wondering now, is this because MSI itself needed 4.5 or could this failure also occur if Product1 needed a reboot?

[Christopher_Pai]

Ok, this fails:

1) run setup.exe
2) Accept MSI 4.5 Install
3) Install Welcome.... Roll
4) SetupCompleteSuccess ( Chained Installs Not Installed )

This Works:

1) run setup.exe
2) Accept MSI 4.5 Install
3) Install Welcome... CANCEL, NO REBOOT
4) run setup.exe
5) Install Welcome... Roll
6) SetupCompleteSuccess ( Chained Installs ARE Installed )

[#4]

This sounds like it is related to the "hot patching" functionality that the MSI 4.5 install uses on XP to install the MSI 4.5 engine.

When this occurs MSI.dll is updated to the 4.5 version immediately, however apps. that already have MSI.dll loaded (such as Setup.exe) still use the old version.

If you cancel and restart the setup in this case Setup.exe then loads the updated MSI.dll and uses it in all cases.

The interesting thing is that in the first case, anything that the setup does that launches another process, such as a custom action, uses the latest MSI.dll as well. Since we launch Msiexec to do the actual setup, it was assumed that a basic MSI setup would use the latest in all cases, but perhaps this is not the case.

To make the experience similiar to previous Windows Installer installs, we try to delay the reboot till the end of the setup by default, but this can be changed by editing the XP prereq. Just change the reboot behavior of the prereq to "Reboot the machine and resume on reboot", and rebuild, the setup will then ask for a reboot immediately after installing MSI 4.5 and will close the setup if the user selects not to reboot.

Devin Ellingson
Software Developer
Acresso Software

[Christopher_Pai]

I found another interesting thing. If I make a simple .BAT file that calls MSI4.5 followed by msiexec /i foo.msi it works.

I also would prefer to defer the reboot. I'm wondering if anything can be done to setup.exe to allow this?

I'm also wondering why MSI shows Product1 as a successful install when in fact it failed as shown in the logs.

[#6]

Yes, any EXE that is run after the MSI 4.5 install is completed should use the MSI 4.5 engine.

The only way to get a currently running app to use the latest MSI.dll is either to restart the app or unload MSI.dll from the process and reload it, unfortunately, this of course would invalidate any open handles to the DLL, and if your code didn't load the DLL it is difficult to determine whether there are any open handles to the DLL.

Perhaps it would be possible to have a custom action that prompts the user and restarts the setup, however the problem is that I'm not sure how you could detect this condition.

Another interesting note, on Vista none of this applies, MSI.dll is never updated till after reboot, so I guess MS has given up on this functionality. Perhaps the best solution is just to prompt for a reboot right after the WI install is completed. (i.e.) changing the settings of the prereq to match Vista.

Devin Ellingson
Software Developer
Acresso Software

[JohnnyEnglish]

The issue here is related to the fact that a reboot is scheduled. If you create an MSI containing other chained packages, only the main install will run if a reboot is required. So if the Schedule Reboot action is run none of the chained MSIs will be executed and only the parent will be installed.

In the MSI 4.5 pre-requisite you will see under the behavior section that if a reboot is required we note it and reboot after the installation. In order to do this we pass a property (ISSCHEDULEREBOOT) to the MSI so that the Schedule Reboot action is run.

To work around this you can modify the reboot behavior in the prq to ignore the reboot.

John Cresswell
Acresso Software

[Shuttledude]

That didn't work for me. What I did was this:

1. In the Redistributables view, I right-clicked the Windows Installer 4.5 for XP and selected Edit Prerequisite.

2. On the Behavior tab of the dialog that appears, at the bottom there is a drop-down combo box for "If the prerequisite appears to need a reboot" I selected the "Ignore it, and fail to resume if machine is rebooted" entry.

3. Rebuilt the project (0 errors 0 warnings)

4. Tested on an XP computer that did not have Windows Installer 4.5. At the start of the install Windows Installer 4.5 process begins and completes with no warnings or errors. As the install proceeds I got an error message stating "Error -1601 The Windows Installer Service could not be accessed."

5. Thinking that this simply means the Windows Installer Service has been stopped, I looked at the list of services (right-click My Computer, Manage, click on Services and Applications / Services). It was running, so there went that theory out the window.

After closing the install and re-starting (but not rebooting!) the install works perfectly, which is the same observation Christopher Painter stated above.

So ... it seems to have made no difference at all. Drat! 😞

[JohnnyEnglish]

Is the 1601 error new since you changed the prq to ignore the reboot? Could you upload an MSI log for this?

The behavior I saw (and I assume this was the same for Chris) was that the MSI launched without problem but at the end of the Install instead of launching the chained packages it just finishes.

All you have done by changing this option is to stop the ISSCHEDULEREBOOT property from being set.

What service pack level of XP are you running this on?

[Shuttledude]

JohnnyEnglish: here are my answers to your questions:

1. Is the 1601 error new since you changed the prq to ignore the reboot?
ANSWER: No, I saw this before modifying the prerequisite.

2. Could you upload an MSI log for this?
ANSWER: Sorry, I don't know where this would have been stored on the computer.

3. The behavior I saw (and I assume this was the same for Chris) was that the MSI launched without problem but at the end of the Install instead of launching the chained packages it just finishes.
ANSWER: The error I got occurred before any of my files could be transferred to the computer. It happened immediately after the Windows Installer 4.5 install process completed.

4. What service pack level of XP are you running this on?
ANSWER: Service Pack 2. But I know this will also have to work on XP computers having Service Pack 3.

[Tim_Mayert]

How about the Mutext error that shows up in the Chaining install log:
Failed to grab execution mutex. System error 258

I have mutliple install msi's chained into my parent install project and I see this error between each builds. Currenlty I do not have it completely working as it seem to hit a roll back after the 3rd product is installed and so far this is the only error I see in the log.

[Tim_Mayert]

I have also noted that if any of the chained install projects return a 3010 - requires a reboot, that instead of just logging this and continuing or actually performing the reboot it will actually fail the install package a perform a rollback of the entire install package, all packages installed.

Is there anyway to have the installs ignore this 3010 and continue the install process? We can not have the entire chained packages rollback just because one of the chained install packages requires a reboot. I would perfer to just have this recorded and then have a prompt at the end of the entire install to have the machine rebooted.

Has anyone else ran into this and if so what did you do to get around this issue?