Skip to content

What’s the deal with this .rbf file?

I was updating the installer to one of our applications and every time I ran it, it wanted to reboot at the end of the install.  This installer was installing a web application with some utility apps, nothing that should have forced a reboot.  I was running the installer inside a VMWare virtual machine of Windows 2003.

I’ve been using InstallAware for the last 3 months to author our installations.  It was being signaled by Windows Installer that it needed to do a reboot to complete the installation.  The question was why?  After a bit of digging in the help file, I found that I could use the “/l=filename” command line parameter to have the installer write to a log file.

I ran the installer one more time and copied the log file down to my dev machine to take a look at it.  It had roughly 9400 lines of Windows Installer chattering.  I started scrolling from the end of the file until I came to the line:

Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\3e1b7.rbf. Must reboot to complete operation.

What the frack is an RBF file?  After some googling, I learned that a file with the .rbf extension is a backup of an existing file.  I scrolled up some more and found a bunch of message like this:

Info 1603. The file C:\WINDOWS\system32\msvcr71.dll is being held in use by the following process: Name: VMwareService, Id: 1804, Window Title: '(not determined yet)'.  Close that application and retry.

The “Close that application and retry” tag means that installer would normally prompt the user to close the application that had the file in use.  If the process does not have a window title associated with it, then that prompt would be suppressed.  In my case, the processes were services and did not have window titles.  I found that documented in a few places, this post on the Windows Installer Team Blog being the most useful of them.

A few of the VMWare processes were also using msvcr71.dll and the file was in use.  OK, fine, but it was the same file.  Same bat-version, same bat-time.  Windows Installer should have had enough brains to determine that new file was the same file as current file and just skipped that step.  I don’t think I ever had that problem with Wise for Windows (WFW had enough problems, but that’s another story).  My guess is that it’s an InstallAware issue, but I’m in the process of confirming that.

I did have a work around.  With the Install File MsiCode command, the dialog box for the command’s properties has a check box labeled “Never Overwrite – do not install if another copy exists”.  For msvcr71.dll, our code works pretty much each version that we have seen so far.  Setting that check box eliminated that reboot after every install.