Configure Windows Screensaver via Active Setup

in

(Or How Active Setup Execution Order Ruined our Week)

At my workplace we recently were given what appeared to be a very simple assignment; deploy a custom screensaver to a group of machines and make it active. The active screensaver is a user setting and is stored at HKCU\Control Panel\Desktop\SCRNSAVE.EXE. The screensaver was packaged as an MSI but since it had no entry points to trigger a repair of the HKCU registry entries, the repackaging team used Active Setup to trigger the repair for each user that logs on. They’ve done this hundreds of times before and it always works as expected. In fact, years ago, I made a merge module that can be simply dropped into an MSI to run a custom action that automatically creates the appropriate Active Setup Registry keys. So there is almost nothing that can go wrong, until of course it does.

Everything worked as expected for existing users that already had profiles on the machine, but for new users the screensaver was set to none. Everything appeared to be working as expected, Windows Installer logs showed that the repair had happened without errors, but the key was missing for a new user.

Eventually I got involved and did a procmon boot capture to figure out what was happening. It turns out the key was being created as expected, but then was deleted a second later.

procmon log
procmon log

Digging a little deeper into the command performing the RegDeleteValue operation revealed the full command line, %SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SytemRoot%\system32\themeui.dll, which quickly led me right back to… Active Setup.

Active Setup Registry
Active Setup Registry

It seems the default theme configuration is triggered via Active Setup and it was happening after our screensaver configuration. Google wasn’t very helpful for figuring out if the Active Setup execution order could be manipulated but I did find one clue:

Finally, it is possible to define the order in which Active Setup commands are run - the clues are in the registry so I will leave it to you to figure this out! (Or you can email me…)

Basically, the Active Setup commands are run in the alphabetical order of the entries under Installed Components. Since our merge module automatically uses the MSI ProductCode GUID for this entry, we simply needed to change the ProductCode to something that occurs after {2C7339CF–2B09–4501-B3F3-F3508C9228ED} and we were all set.