Hey all, I’m happy to report that we figured out the root cause of the really strange rollback behavior we saw in the .NET Framework setup (described in a post earlier this week) and I wanted to pass on what we found in case any of you hit this issue with a Windows Installer-based setup in the future. Here is a rough outline of the issue and the underlying problem:
- There was an orphaned registry value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts that pointed to a rollback script
- At the end of all Windows Installer setups, it performs a standard action to “remove backup files“ and when it does this it searches this registry value and executes any rollback scripts (*.rbs) it finds there
- On this machine, the RBS file belonged to a different product. Note that you can use the script named WiLstScr.vbs in the Windows Installer SDK to display the contents of an RBS in a text file to figure out what product it belongs to.
- When this orphaned RBS file was executed, a custom action within it failed because it actually belonged to another product and some of the properties it needed weren’t set properly, and that caused the whole installation of the current product to rollback
The only thing we are not sure about is why the RBS file was orphaned in the registry and on the user’s machine to begin with, so we’ll have to keep digging into that if we get any additional repro machines and see if we can figure it out. We are going to look into making the next version of Windows Installer smarter about which RBS files it will run when it is removing backup files to try to help avoid this scenario in the future, but in the meantime if you encounter this behavior in any of your scenarios, start by taking a look at that registry value and see if there is any orphaned data that may be causing your setup to rollback.
Hope this helps……