1

I have spent the past 3 days running in-place while tracking down the cause of forced reboots on my system, but have finally narrowed it down to a very specific cause. I have a service suite that I am working on in Wix. There are 10 msi's that are all held together with a burn install. As these 10 installs run, they create dependencies on the services that are installed before them. Everything on this install works great, except for uninstalling it when the services are up and running. The service that has others relying on it tells Windows a restart is necessary even though it isn't (to the best of my knowledge).

Calling the bootstrapper with the argument '/norestart' stops the silent uninstall from auto-restarting, but windows still ends up in the "don't do anything else until a reboot happens" phase which is better, but not ideal.

Is there any way to have my CulpritServiceInstall.msi be physically unable to flag my machine for a restart? I understand this may not be the best solution, but I am 90% convinced the restart flag is being set on false assumptions by the windows installer (it is worried that certain services need to start up again, but they have been purged from the system).

I can post my wix wxs file for everyone if anyone thinks that can help.

Validation of my issue: if the dependent services are not running during the time of the uninstall, everything goes fine. It seems like the uninstall takes a snapshot of the services' state at the beginning of uninstall 1, and holds onto it until the very end.

EDIT: BradFordrg found my issue. I somehow got pretty far off the correct path to fixing this. I never tried running the angry msi all by itself. I always paired it with my dependent services. My testing was too bias. I could have found this myself by scanning the msi log for the word "reboot" which I thought I did, but clearly did not.

Shadoninja
  • 1,276
  • 1
  • 12
  • 22
  • 1
    Take a verbose log of the uninstall and see what it says. Also, what does your WiX say about stopping services? Does it have Wait=yes? And does the service and its contaiining process really shutdown correctly? If the service and containing process do not go away correctly (and that can be a coding issue) then Windows will need a reboot to delete it. Is it still in the services applet? If so what state is it in? Maybe the process is still running? So there is a lot more you could look at to get a handle on the problem. – PhilDW Jun 11 '15 at 18:17
  • It was the files not going away properly. Good suggestion. – Shadoninja Jun 12 '15 at 17:53

1 Answers1

4

The restart flag is not being set on false assumptions.

There are various places in the installer log file that show the installer is trying to delete files, but is not able to because the files are locked by 1 or more processes:

592.MSI (s) (B0:58) [12:22:45:305]: Executing op: FileRemove(,FileName=asm-4.1.jar,,ComponentId={4E9A32EC-C065-4BA6-83C8-ADC327C94B12})
593.Info 1903.Scheduling reboot operation: Deleting file C:\Program Files\Data Indexer\elasticsearch\lib\antlr-runtime-3.5.jar. Must reboot to complete operation.

603.MSI (s) (B0:58) [12:22:45:305]: Executing op: FileRemove(,FileName=asm-commons-4.1.jar,,ComponentId={40A5E481-AA7E-45F6-A609-A65F2DFB8902})
604.Info 1903.Scheduling reboot operation: Deleting file C:\Program Files\Data Indexer\elasticsearch\lib\asm-4.1.jar. Must reboot to complete operation.

When this happens the installer will use the technique outlined in How can I force the deletion of locked files in C/C++? to mark the file for deletion and request a reboot.

A quick scan through the installer log shows these files were locked:

  • C:\Program Files\Data Indexer\elasticsearch\lib\antlr-runtime-3.5.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\asm-4.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\asm-commons-4.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\groovy-all-2.3.2.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\jna-4.1.0.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\jts-1.13.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\log4j-1.2.17.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-analyzers-common-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-codecs-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-core-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-expressions-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-grouping-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-highlighter-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-join-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-memory-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-misc-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-queries-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-queryparser-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-sandbox-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-spatial-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\lucene-suggest-4.9.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\spatial4j-0.4.1.jar
  • C:\Program Files\Data Indexer\elasticsearch\lib\sigar\sigar-1.6.4.jar

Based on the file type we can take an educated guess that the java runtime environment is responsible. You could confirm this by using Microsoft's Process Explorer to find out which processes have the files open.

Community
  • 1
  • 1
bradfordrg
  • 1,863
  • 2
  • 21
  • 34