Have you considered a UNIX-like approach like passing the PID? Burn could
easily check it's PID against the passed value to see if it is already running.
--
John Merryweather Cooper
Build & Install Engineer -- ESA
Jack Henry & Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com<mailto:jocoo...@jackhenry.com>
www.jackhenry.com<http://www.jackhenry.com>
From: Tobias Erichsen [mailto:i...@tobias-erichsen.de]
Sent: Friday, November 8, 2013 3:18 AM
To: wix-devs@lists.sourceforge.net
Subject: [WiX-devs] Issue & possible solution: Burn Startup-Screen is shown
twice (on Windows XP) if bootstrapper contains driver-installation
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
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
------------------------------------------------------------------------------
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
