Weird rollback behavior I saw in Windows Installer yesterday

I saw a very odd rollback behavior in the .NET Framework setup yesterday that I thought I should post in case anyone else runs into something similar.  This was the 2nd time I saw it, but the first time in a scenario from a non-Microsoft internal machine.  When it first happened I had written it off as a one-off caused by daily builds of the OS, the .NET Framework or something like that.  But apparently it is possible to get the machine into this state through released products (possibly beta bits, but still valid in my opinion)

Essentially what happened was the .NET Framework setup proceeded all of the way through installation and then initiated a full rollback.  I couldn't find any evidence in the verbose MSI log file that any kind of error had triggered the rollback, and the last section of the log told me that the return code was 0 and that the .NET Framework installation completed successfully.  I had to use filemon and regmon (from to diagnose that there was a file in the folder c:\config.msi named *.rbs that was being executed, and then finally I traced it back to the following registry value on the machine:


I wasn't able to determine how that value got set, and searching for information about this registry hive in msi.chm and on the internet didn't yield any conclusive information.  The closest I came to a possible explanation is in the section named Active (Incomplete) Installations at

What I think may have happened is some other Windows Installer setup (more than likely the .NET Framework itself) got orphaned before it completed, and then this script was left behind in the registry and inadvertantly got launched by future installations.  Normally when a Windows Installer setup gets orphaned and you try to run another MSI, it will say that an installation is currently in progress and is suspended and asks if you want to rollback before you continue with the new setup, but for whatever reason we didn't see that in these 2 instances.  I'm still hoping to get a more thorough explanation from the Windows Installer team about what is really going on here, and I'll post my findings back here.....

Comments (5)
  1. Christopher Painter says:


    Did you ever find out more on this.  I'm getting reports of an SCCM F12 build of a clean machine where about 50 packages later an installer fails, rollbacks and then starts to remove the SCCM client.   I'm still gathering evidence but I suspect I'll see orphaned RBS files from the SCCM installer.

  2. Hi Christopher Painter – Unfortunately, we never ended up figuring out the root cause of the orphaned rollback scripts in this scenario.  We also never ended up seeing another instance of this particular failure after I originally wrote this blog post.  Very strange…

  3. Christopher Painter says:

    We have a ticket open with MSFT: [REG:114112512089430] SCCM 2012 R2: OSD failures for a particular HW load where msiexec creates a child process that uninstalls the SCCM client intermittently for unknown reasons

    I was working with an SCCM Support Escalation Engineer who wasn't an MSI expert.  We were looking through a logfile for a very simple wix installer that I wrote (accept for a custom action that we wrote that failed and correctly triggered a rollback ).  The weird thing is the log showed a bunch of rollback executing operation statements for things that weren't in the installer and were never logged during the script generation phase.  

    I was on a conference call when I started to speculate that it was almost like MSI was executing some orphaned rollback scripts and sure enough when I did a google search I landed on your blog.   Thanks! 🙂

    So whatever this is ( I've asked the SCCM team to pass in the DISABLEROLLBACK=1 to the SCCM client install )  it's alive and well in Windows 7.

    1. Two years later and it bit us again. Thank goodness for this blog article or I would have been scratching my head again.

Comments are closed.

Skip to main content