There is no such dependency "baked-in" to the system. The only tracking is the parent process's ID is in placed in the child's process information structure at the child's launch. When a process ends, all handles assigned to that process are automatically closed and children are not given any handle to their parents (unless the parent explicitly prepared and sent them one). Also, while the service control manager tracks the processes hosting each service, it does not track subprocesses. The only other overall "tracking" of note is when the system stops all processes associated with any given profile being unloaded (whether some user account being logged out or the entire system is shutting down).
WRT process monitor: first filter on all accesses/handles to the files you are replacing in your upgrade, looking to see especially what process(es) still have what file(s) open when Windows Installer is renaming/moving them in preparation to write out the newer version of them (it won't actually throw the flag to prompt for reboot until it is unable to delete those renamed copies, but all holders of those files should have already closed their handles due to exiting before the attempt to overwrite). The majority of cases I've seen of this in the field have been anti-virus software locks, but that doesn't exclude something else... Blair > From: afor...@cmu.edu > To: r...@robmensching.com; wix-users@lists.sourceforge.net > Date: Tue, 2 Jul 2013 15:04:21 -0400 > Subject: Re: [WiX-users] Upgrade uninstall restart issue > > I don't know the Windows process & service model as well as I probably > should, but my hypothesis regarding my problem is that the package installer > cannot stop MyClient service, because MyClient service spawned the bundle > installer, which in turn spawned the package installer which is trying to > stop MyClient service. > > I'm guessing this causes an unresolvable loop because there's some kind of > dependency whereby the MyClient service won't fully stop until its children > processes have terminated, even though MyClient's execution does not actually > dependent on those processes at all (and I in fact WANT it to stop/terminate, > and it is coded as such, as far as I know). > > To those of you who understand processes and services better than I, does > this make sense? Or is there no such parent-child dependency amongst > processes/services? > > Alain > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: July 1, 2013 18:20 > To: 'Rob Mensching'; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Upgrade uninstall restart issue > > > Burn is very self-contained and only uses files it carries with it, > > although a custom BA can do anything. > > I'm not using any custom BA (that I know of). My Bundle source is below this > message, for your reference. Please let me know if you see anything wrong (or > don't see something that should be there). > > > If you haven't already, I'd recommend using Process Monitor to see if what > > locks your files when they are trying to be removed. > > I've been wrestling with the Process Monitor logs and, having never used it > before now, I can't make sense of the jungle of activity. Do you have any > suggestions on what exactly I should be looking for? > > > Note: Burn will not install or uninstall packages that are not explicitly > > listed in the Chain today. However, a package in your chain may upgrade an > > existing package on the machine during install. > > Yes, that is what I would expect, so I'm not sure how that might be a bad > thing in my case. > > > Note2: Very screwy that a package would be detected per-user when it is > > really per-machine. That would be something to investigate further. > > Good to know that's not something to ignore, but I have no idea how to > investigate further. As I said, in our Package, we have set > InstallScope='perMachine' and even tried adding InstallPrivileges='elevated', > as well as ForcePerMachine="yes" to the MsiPackage element in the Bundle's > Chain, but somehow it still seems to think the package was installed per > user, when it definitely should not be. So how could this be further > investigated? > > Finally, as promised, our Bundle's WiX source: > > <?xml version='1.0' encoding='windows-1252'?> <Wix > xmlns='http://schemas.microsoft.com/wix/2006/wi' > xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"; > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"; > > > > <?ifndef PRODUCTVERSION?> > <?error PRODUCTVERSION must be defined ?> <?endif ?> > > <Bundle > Name="My Client v$(var.PRODUCTVERSION) Installer" > UpgradeCode="MYUPGRADEGUID" > Version="$(var.PRODUCTVERSION)" > Copyright="Copyright © Us. All rights reserved." > IconSourceFile="lib/Icon.ico" > Manufacturer="Us" > DisableModify="yes" > HelpUrl="mailto:u...@us.com"; > > > <BootstrapperApplicationRef > Id="WixStandardBootstrapperApplication.RtfLicense" > > <bal:WixStandardBootstrapperApplication > LicenseFile="License.rtf" > LogoFile="lib\logo.png" > SuppressOptionsUI="yes" > ThemeFile="MyRtfTheme.xml" > /> > </BootstrapperApplicationRef> > > <!-- Abort installation if not running with administrator privileges --> > <bal:Condition Message="This installer requires administrator > privileges to run."> > Privileged <!--OR AdminUser--> > </bal:Condition> > > <!-- Abort installation if not running on Windows 7 or 8 --> > <bal:Condition Message='Sorry, but this software only supports Windows > 7 or Windows 8.'> > VersionNT >= v6.1 AND v7.0 > VersionNT > </bal:Condition> > > <Chain DisableSystemRestore="yes"> > <PackageGroupRef Id="pkgJRE7" /> > <MsiPackage > Id="pkgMyClient" > DisplayName="My Client" > Cache="no" > Compressed="yes" > ForcePerMachine="yes" > Permanent="no" > SourceFile="MyClientPackage_v$(var.PRODUCTVERSION).msi" > Visible="no" > Vital="yes" > ></MsiPackage> > </Chain> > </Bundle> > </Wix> > > -----Original Message----- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: July 1, 2013 01:28 > To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Upgrade uninstall restart issue > > I don't know what in Burn would lock existing files. Burn is very > self-contained and only uses files it carries with it, although a custom BA > can do anything. If you haven't already, I'd recommend using Process Monitor > to see if what locks your files when they are trying to be removed. I'd be > very surprised if it was anything in the Burn process. > > The order you are seeing in Burn is expected. There are some details here: > https://support.firegiant.com/entries/24024208-Bundle-chain-execution-order- > > Note: Burn will not install or uninstall packages that are not explicitly > listed in the Chain today. However, a package in your chain may upgrade an > existing package on the machine during install. > > Note2: Very screwy that a package would be detected per-user when it is > really per-machine. That would be something to investigate further. > > > > On Sun, Jun 30, 2013 at 7:43 PM, Alain Forget <afor...@cmu.edu> wrote: > > > I know about those, but how do I use them to prevent Burn from locking > the existing files before it runs the installer package to MajorUpgrade? > > > -----Original Message----- > From: Phill Hogland [mailto:phogl...@rimage.com] > Sent: June 30, 2013 20:54 > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Upgrade uninstall restart issue > > > Maybe this blog would be helpful: > > http://code.dblock.org/msi-property-patterns-upgrading-firstinstall-and-maintenance > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrade-uninstall-restart-issue-tp7586315p7587020.html > Sent from the wix-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
