I always use vbscript to perform deletion, especially using active setup.
Write a vbscript to delete your HKCU entries and copy it to the machine before reboot. Give the path of the vbscript in Active Setup.
So when you delete HKLM entrie and reboot, active setup triggers vbscript which will delete HKCU entries.

Add vbscript + Active setup entries [with path to vbscript] to your main MSI and let it cleanup the install, delete HKLM entries and reboot. Once you reboot the machine, vbscript will take care of the rest.

Let me know if you need any assistance with the vbscript.

Thanks,
Eshwar

Thanks Eshwar

Its possibly me thats actually misunderstanding how active setup works then, because in my eyes my Wisescript exe that cleans up the HKCU keys should do the same as what your VBScript does?

In my active setup StubPath key I'm calling the exe directly, not doing a repair of the MSI itself, so thinking about it as Im typing is the MSI actually running at all, is it not simply the Exe that's firing off, completely independant of the MSI?

If thats the case, I need to find out what is causing this reboot. Unfortunately having been experimenting this morning, its not replicated on my virtual machines that I use for basic testing, which suggests its perhaps a combination of what my MSI is doing and something present/different in the live environment.

Chris

Did you check your wise script EXE if there is any custom that is triggering the reboot?

Coz when the user logins in for the first time, active setup registry entry [stubpath] will be executed, which will execute the wise EXE that you've specified.

Yup I did check but it doesn't do anything like that, literally all the exe consists of is a few "edit registry" lines that remove some HKCU keys related to the app we've removed. They all live in HKCU\Software\App so couldnt be triggering a reboot by removing them I wouldnt think.

The more I think about it, the more Im convinced its not my removal tool thats actually triggering the reboot, so I'll have to find some more live guinea pig machines I can run it on to see if I can determine the actual cause.

Chris

Check the application event log to see if your active setup's cleanup might be "damaging" another MSI installation's registry keys, leading to a self healing operation on the other MSI, and a forced reboot. The application event log records any MSI installs, repairs, etc, and is an often overlooked source of diagnostic information.

Also, you could enable verbose MSI logging through the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmup"

This will record a log in the temp folder for any MSI install/repair activity. Clear your temp folder of any existing rubbish before you start, so that it is easier to identify any new content.