My apologies for the multiple posts, but I've found some more information that might tell some of you something, even if I don't know what it implies.
One thing I might not have previously mentioned is that the restart request does NOT appear if I wait for a few minutes after install before trying to uninstall the software. Comparing the logs between the two uninstalls of when the restart request does and does not appear, the only difference (aside from timestamps) is this: With restart request: MSI (s) (A4:18) [11:17:44:613]: Note: 1: 2727 2: MSI (s) (A4:18) [11:17:44:660]: RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary. MSI (s) (A4:18) [11:17:44:660]: Note: 1: 1610 MSI (s) (A4:18) [11:17:55:299]: RESTART MANAGER: The user chose to go on with the installation, although a reboot will be required. MSI (c) (3C:88) [11:17:44:676]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup. MSI (s) (A4:18) [11:17:55:299]: Note: 1: 2727 2: MSI (s) (A4:18) [11:17:55:299]: Doing action: InstallInitialize Action ended 11:17:55: InstallValidate. Return value 1. With no restart request: MSI (s) (E4:B0) [15:32:00:536]: Note: 1: 2727 2: MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MyClientCommModule will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MySensor1 will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MySensor2 will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: RESTART MANAGER: Detected that the service MySensor3 will be stopped due to a service control action authored in the package before the files are updated. So, we will not attempt to stop this service using Restart Manager MSI (s) (E4:B0) [15:32:00:583]: Note: 1: 2727 2: MSI (s) (E4:B0) [15:32:00:583]: Doing action: InstallInitialize Action ended 15:32:00: InstallValidate. Return value 1. So there are two things I've noted: 1) The only thing different I can tell between the two uninstall procedures is the difference in time between the install and uninstall. For example, if I wait 5 seconds, then I see the restart request, but if I wait a minute or two after installing before uninstalling, then there is no restart reqest. Some of the sensors do periodically run cmd.exe or third-party exes that I install, but the services are designed to drop everything and stop if they are asked to. Furthermore, in Process Explorer, I can see that they are child processes of the service's process, so...I wouldn't think this would be a problem for the Windows Installer? 2) My previous hypothesis that the uninstaller was choking on "WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\SomeFile.class' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0)" was flat out wrong, since the exact same log lines show up in both uninstallers' logs. So why would it sometimes think that some "critical application holds file[s]", and other times, it can tell exactly which processes/services hold the services? Does any of this point to some source for the problem (and hopefully a solution)? Alain -----Original Message----- From: Alain Forget [mailto:afor...@cmu.edu] Sent: June 21, 2013 12:14 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue I've found a number of Restart Manager posts similar to this: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-the-Restart-Manager-td3162984.html Since our services' JSL exes basically use Java, maybe it's Java that's locking our files, and the uninstaller doesn't/can't dig deeper into what's controlling what to realise the files are locked by java, which is run by our services' exes? Even if that's the case, I have yet to see a reply on how to solve the problem. Alain -----Original Message----- From: Alain Forget [mailto:afor...@cmu.edu] Sent: June 21, 2013 11:42 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Uninstall restart issue Blair (and anyone else interested), You were bang on about both manually trying to launch the service to test it and using " around the formatted string. Sometimes when I've been working at something for too long, I don't think of things like that and can't see the forest for the trees. :-s Unfortunately, the uninstaller is *still* requesting a restart just as before. However, without actually manually restarting the computer, our software does completely uninstall anyway, so the uninstaller's concerns are for naught. The verbose logs still look very similar to before, with many entries just before CostFinalize like this which is what I think is what leads to the request to restart: MSI (s) (A4:18) [11:17:44:582]: WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\MyClient\OneOfManyFiles.ini' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0). Maybe those lines have nothing to do with the request to restart, but a file or folder being "blocked" seems to be the only thing I can see that could be related to the problem. I do think it is better that the Windows Installer creates/registers the services from independent exes now (instead of doing it with CAs like before), but somehow, it's still not understanding that these files are locked by the services that are going to be stopped. Arg, why not? Hopefully you have some other insights on what might be going on? Alain -----Original Message----- From: Blair Murri [mailto:os...@live.com] Sent: June 21, 2013 04:31 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Uninstall restart issue Alain, Temporarily remove the ServiceControl\@Start and install. Then use the service control manager and start. See what errors are reported, diagnose, and tweak the installation. Once your service starts when installed, replace the @Start attribute. I didn't see anything special done when jsl.exe was passed an "install" switch, but I didn't walk the code in a debugger either. If you have spaces in your installation directory path (such as the space between Program and Files) you may need to update your ServiceInstall\@Arguments to be Arguments="-ini "[#fileClientCommModuleJslConfig]"" Blair Murri > From: afor...@cmu.edu > To: jacob.hoo...@greenheck.com; wix-users@lists.sourceforge.net > Date: Thu, 20 Jun 2013 17:09:30 -0400 > Subject: Re: [WiX-users] Uninstall restart issue > > Anyone out there have any ideas about our problem below? > > I'm thinking anyone with experience using WiX or the Windows Installer with > JSL or a Java-based service are best positioned to know how to solve this. > > Alain > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: June 19, 2013 19:12 > To: 'Hoover, Jacob'; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I've implemented Blair's 2nd suggestion, and the services do seem to get > installed, but I don't think they're being installed correctly, because the > services then cannot start and the installer fails. > > I think the -install argument of jsl.exe does some other special things to > wrap the Java program and install it as a service than the ServiceInstall > does, which is why it worked when I was installing the service using jsl.exe > directly, instead of trying to do it with ServiceInstall. > > Any ideas are welcome, and I can provide any logs you think would help. > Here's a snippet of what my service-related WiX looks like now: > > <Component Id='compClientCommModuleJslConfig' Guid='MYGUID1'> > <File Id='fileClientCommModuleJslConfig' > Name='jsl_ClientCommModuleServiceConfig.ini' DiskId='1' > Source='jsl_ClientCommModuleServiceConfig.ini' KeyPath='yes' /> </Component> > <Component Id='compClientCommModuleJslExe' Guid='MYGUID2'> > <File Id='fileClientCommModuleJslExe' > Name='MyClientCommModuleService.exe' DiskId='1' Source='jsl.exe' > KeyPath='yes' /> > <ServiceInstall > Id="servInstClientCommModule" > Name="MyClientCommModule" > Arguments="-ini [#fileClientCommModuleJslConfig]" > Description="My Client Communication Module" > DisplayName="My Client Communication Module" > ErrorControl="normal" > Start="auto" > Type="ownProcess" > Vital="yes" > > > </ServiceInstall> > <ServiceControl > Id="servClientCommModule" > Name="MyClientCommModule" > Remove="uninstall" > Start="install" > Stop="both" > Wait="yes" > /> > </Component> > > > -----Original Message----- > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] > Sent: June 19, 2013 16:13 > To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I don't think so, assuming you are having a unique EXE per service. I think > what Blair was saying is the issue of having the same exe name (single > component) in multiple services. I think what you need is a component per > file, with the exe of each of the services (unique copy for each) and their > related ServiceInstall/ServiceControl elements in a component. > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: Wednesday, June 19, 2013 1:16 PM > To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > I agree that one file per component is best, but would doing so conflict with > Blair's 2nd solution for registering my services such that the uninstaller > can wait for the StopServices step to release the other files in use before > deciding that a restart is required? > > > -----Original Message----- > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] > Sent: June 19, 2013 14:10 > To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > No, a component can only have one key path, be it a file, directory, or > registry entry. Any time the key file changes, the component will be > serviced. If you have the exe being the key file and it never changes, then > your jar files will never be updated unless you are doing a major upgrade > with REP scheduled early (which in effect removes the old version before > installing the new version). > > Personally I would place each file in its own component, in case you ever > want to do a minor upgrade or patch in the future. > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: Wednesday, June 19, 2013 12:51 PM > To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.' > Subject: RE: [WiX-users] Uninstall restart issue > > Oh, I see, so if we make a Component contain multiple files, any time any one > of those files are changed, the installer will uninstall and reinstall the > entire component, and all the files therein (assuming I understand > correctly). This is fine for our purposes, and we are already only doing > MajorUpgrades for simiplicity, so this all sounds good. > > Once I do it, I'll post back to let you know how it turns out. > > > -----Original Message----- > From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] > Sent: June 19, 2013 13:30 > To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. > Subject: RE: [WiX-users] Uninstall restart issue > > One file per component is the most flexible for maintenance, but depending on > your patching/upgrade plan it may not be needed. If the key file to the > component is a 3rd party exe (and all of your jars were within this > component), then you would have to have RemoveExistingProducts scheduled > early, and you could only ever do major upgrades (unless you are going to > recompile their exe after incrementing the version info). > > -----Original Message----- > From: Alain Forget [mailto:afor...@cmu.edu] > Sent: Wednesday, June 19, 2013 12:12 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Uninstall restart issue > > You're quite right; after installing our software, there is a separate > jsl.exe process for each of our services. One disturbing thing I've noticed > is that if I then reboot the computer after installing our software, then > open the Task Manager and press the Show Processes from All Users button, the > Task Manager UI becomes unresponsive, even though it will still update the > visible processes' statuses. Once our software is uninstalled, bringing up > the Task Manager and pressing Show Processes From All Users works fine. Odd > that this does not happen immediately after installing, but before > restarting. But anyway, one problem at a time, in case what we're doing now > will fix it. > > I will try your 2nd suggestion: > > <Component Id="ClientCommModuleService"> > <File KeyFile="yes" Name="ClientCommModuleService.exe" Source="jsl.exe"/> > <ServiceInstall Name="MYCLIENTClientCommModule" Arguments="-ini > [#jsl_ClientCommModuleServiceConfig.ini]" ...> > ... > </ServiceInstall> > <ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../> > ... > </Component> > > One question: I assume that all the class files used by each service should > still be in their own parent Component (as the tutorials strongly advocate), > or should all files used by a given service be in the the same parent > Component as the service (i.e. be placed at the last "..." in the above code)? > > Alain > > -----Original Message----- > From: Blair Murri [mailto:os...@live.com] > Sent: June 19, 2013 09:08 > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Uninstall restart issue > > I looked at the source code from the jsl website and what they are doing is > installing whichever jsl*.exe binary as the service executable (passing '-ini > <config-file>' as the argument), and loading the java.dll file from the > selected java runtime after parsing the config file, then using jni to > connect the service control manager callbacks and api to the java classes. > > Restart manager (and its predecessor) is going to look at the EXE binary that > was used to start each process holding files of interest. It also checks to > see if each process of interest is a service or not, treating each slightly > differently. > > Windows Installer doesn't easily share the same service binary for multiple > services from different components due to the requirement that the component > defining a service have its keypath be the service binary, which is the > reason I used a pattern of reusing the jsl.exe binary into multiple target > binary files (one for each service). > > Blair > > > From: afor...@cmu.edu > > To: wix-users@lists.sourceforge.net > > Date: Tue, 18 Jun 2013 17:31:25 -0400 > > Subject: Re: [WiX-users] Uninstall restart issue > > > > Hm, interesting. Assuming you are right and this is what's going on, I > > don't think all four services are sharing jsl.exe, because it is only used > > to create (or remove) Java-based services. Wouldn't the exe actually be > > java.exe, because my services are Java programs? If so, I'm not sure how to > > tell if a running java.exe is for our services or some other Java-based > > software. > > > > I am currently travelling, but will look more closely into what the > > services' exe is. As an insanity check, I assume that should be in the Task > > Manager process list, or must it be found elsewhere? > > > > If the exe is java.exe, and not jsl.exe, how do you think that might affect > > your other proposed solutions (which I like, if I can get them to work and > > understand them more fully)? > > > > Alain > > > > -----Original Message----- > > From: Blair Murri [mailto:os...@live.com] > > Sent: June 18, 2013 04:22 > > To: 'General discussion for Windows Installer XML toolset.' > > Subject: Re: [WiX-users] Uninstall restart issue > > > > Restart manager in your situation is probably working something like this: > > > > Look at each component that is being removed Look at each and every > > file in each of those components Look at each and every process > > holding any of those files open? > > Is that process's binary the keypath of any component that contains a > > ServiceConfig that will be stopping that service in this transaction? If > > so, eliminate this process as one that will cause a reboot. > > If there are any processes left over, prompt for user decision (since a > > reboot could happen). > > > > If after actually running the transaction none of the files are still open > > when they are deleted then no actual reboot will be requested (or executed) > > as a result of files-in-use (despite the dialog). > > > > I'm guessing in your case that all four services are sharing one executable > > (jsl.exe) and that executable isn't the keypath of one or more of the > > components supplying the ServiceConfig stop directives. Thus, restart > > manager doesn't find the service(s) and thus doesn't know how the restart > > will be avoided (since none of the processes can use restart manager's > > "freeze dry" method since all of them in your case are services). > > > > To address this one remedy would be to restructure along these lines: > > > > <Component Id="ClientCommModuleService"> > > <File KeyFile="yes" Name="ClientCommModuleService.exe" > > Source="jsl.exe"/> > > <ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../> > > ... > > </Component> > > <CustomAction Id="cmdInstallClientCommModuleService" .../><!-- > > reference #ClientCommModuleService.exe instead of #jsl.exe in defining this > > CA--> <InstallExecuteSequence> > > <Custom Action="cmdInstallClientCommModuleService" > > ...>$ClientCommModuleService>2</Custom> > > </InstallExecuteSequence> > > > > repeat for each of the remaining three services. > > > > A big problem with using JSL this way is that is that it is a form of > > Self-Reg (and all the evil that entails). A much better (more reliable and > > repeatable) way would be to identify each of the elements from your .ini > > service config files related to service configuration and copy them into > > the appropriate places in the ServiceControl & ServiceInstall (and their > > child elements) along the lines of this: > > > > <Component Id="ClientCommModuleService"> > > <File KeyFile="yes" Name="ClientCommModuleService.exe" > > Source="jsl.exe"/> > > <ServiceInstall Name="MYCLIENTClientCommModule" Arguments="-ini > > [#jsl_ClientCommModuleServiceConfig.ini]" ...> > > ... > > </ServiceInstall> > > <ServiceControl Name="MYCLIENTClientCommModule" Stop="both" .../> > > ... > > </Component> > > > > Even better would be to write a Wix Extension to wrap this second pattern > > and contribute it to the JSL project so they could maintain it (since the > > "-ini" argument (and how that file is parsed) is their implementation > > detail) which would parse the INI file at build time to fill in all the > > service related pieces (that way data is never entered twice). It could > > even select jsl.exe or jsl64.exe automatically based on whether the > > component was 32- or 64-bit, or include the debug version if debug is > > defined, or whatever). > > > > Blair Murri > > > > > > -------------------------------------------------------------------- > > -- > > -------- 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 > > > > > ---------------------------------------------------------------------- > -------- 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
