One thought, making the command line in the run-once key longer might be an
issue as I believe there is already an issue with this getting too long.
Is it possible to move the point at which the run-once key is written until
just before a restart?
Neil
Problem:
========
When burn is used to install one or more MSI-packages (very probably also
exe-packages) on Windows XP
and one of the packages contains a driver install, the burn-bootstrapper is
started a second time
during the installation-chain, showing the startup-screen once more erroneously.
The install itself is going through successfully and the final "Success" screen
is shown at the end.
This is very annoying, as the second startup-screen will confuse customers to
think that the
installation did not go through correctly.
This behavior does not show up on Windows 7 or 8.
Analysis:
=========
During analysis using the Process-Monitor-Tool I discovered that the second
(erroneously shown)
burn startup-screen was shown by the bootstrapper that is instantiated by the
runonce executable
(complete process-chain: services.exe -> msiexec.exe -> msiexec.exe ->
runonce.exe -> burn_bootstrapper.exe)
Being instantiated from runonce.exe and also the specific commandline provided
to the bootstrapper
(/burn.runonce) revealed that the bootstrapper was re-run due to it being
written to the RunOnce
registry-key.
Burn writes this RunOnce registry-key to restart itself in case of reboot
during the package-installation-
chain.
Unfortunately it seems like this RunOnce feature is executed prematurely.
There are two links to this topic that someone mentioned on the wix-users
mailing-list:
http://blogs.msdn.com/b/junfeng/archive/2006/09/19/761765.aspx
http://support.microsoft.com/kb/281820
It seems like a driver-installation might fire the RunOnce-registry-keys due to
driver-infs having
the feature to also contain RunOnce options that the driver-install-creator
might want to have
executed post inf-installation.
Obviously this interferes with the RunOnce usage of burn.
There are two sub-problems:
Part 1:
=======
The errouneous display of a second installer startup-screen.
Part 2:
=======
The intended use for RunOnce in burn is foiled due to the Registry-Key being
deleted by the
premature firing of the RunOnce condition.
Solution Part 1
===============
Is possibly fixed very easy. The commandline written into the RunOnce-key must
be expanded to
contain some kind of information for the new (RunOnce-initated) burn-process to
find out whether it
is still running in the same boot-session, or an intermediate boot has occurred.
If it is still the same session, the burn-process should stop immediately,
showing no user-interface.
If it detects a reboot in between it will proceed like intended.
Two methods for detection come to mind:
a.) add the current-time (in UTC) to the command-line.
This way the RunOnce-initiated detection can use its current time & the time
since the last boot to
find out if a reboot has taken place in between.
b.) In case some unique ID (GUID?) exists that Windows sets to a new value on
each reboot, this might
be put on the commandline & checked by the RunOnce-initiated burn-instance.
Any pointers to such an
id would be highly welcome...
Solution Part 2
===============
I'm not 100% sure about the total burn-architecture, so my proposal might
interfere with other features...
Instead of calling the UpdateResumeMode function (in registration.cpp) once at
the start of the install,
it should be called once before each package in a chain.
This way it gets refreshed in case one of the packages cause the RunOnce action
to be fired prematurely.
I'd be happy to get feedback on my ideas...
Best regards,
Tobias
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
