Jump to content

Welcome to Geeks to Go - Register now for FREE

Geeks To Go is a helpful hub, where thousands of volunteer geeks quickly serve friendly answers and support. Check out the forums and get free advice from the experts. Register now to gain access to all of our features, it's FREE and only takes one minute. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more.

Create Account How it Works


  • Please log in to reply




  • Member
  • PipPipPip
  • 262 posts
Humph. When comps decide to act up mysteriously, they serve up multiple issues. So here's another question:

I just did a system restore, and now there is an empty folder in my C:\ called 'config.msi'. It was created one minute after the restore took place. Any ideas on what might have created it?

  • 0



  • Guest
turn off system restore by unchecking it.. start ..control panel..system..system restore..take check mark out click ok

try deleteing it and then reboot

if it doesnt show up should be ok

heres some info

Iím uninstalling a product on Windows Server 2003. At the time of uninstall, one of the productís DLL is in use. The log file generated during uninstall contains the following entry:

MSI (s) (A0:CC): Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1903

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

In spite of the message indicating that reboot is necessary, Iím not prompted for reboot when uninstall completes. Is there some sort of bug in my install program or is this by design?

I thought that reboot was going to automatically occur to avoid the above scenario, but apparently this isnít so. Can someone comment on this scenario and suggest what we might do overcome this problem?

Generally this can be safely ignored.

The only authoring degree of freedom with reboots is the REBOOT Property [Windows Installer] and generally folks want less reboots not more.

.rbf files are internal copies (technically the moved original) of the files that Darwin keeps for Rollback Installation [Windows Installer] purposes. Al this says is that Darwin is going to put an entry into the windows registry to delete this file at the next reboot of the system.

The behavior by Windows Installer is by-design. This is related to the functionality that Windows NT offers for handling in-use files. Win9X systems used a replace on reboot model for updating files that were in-use. WinNT systems provided a better model that helped eliminate unnecessary reboots by providing a move-and-replace model. The Installer makes full use of the WinNT model on those platforms. When the file is in use and must be removed, the installer can simply rename it to some secret location and then schedule it for deletion at a later time. Since nobody else can find the file (they usually ask for it by its former name), the delete-on-reboot portion of the update is considered optional. Why reboot for a file that none knows about?

Currently there is no way to turn off the Installer's reboot-ignore behavior on file removal. If the behavior doesn't fit your model (and you're identified one such occurrence), then adjust your setup to make it work. You can either ensure that your file is not held in use by getting all users to unload it or alternatively authoring your setup to force a reboot for the scenario. At this point, the only identification of the state is the 1903 message sent to the log file (or to an external UI handler). There are no properties that are set to identify the scenario as ReplacedInUseFiles is only set when the Installer actually overwrites an existing in-use file.

after you reboot go back and restore your system recovery by replacing check mark back in box
  • 0




  • Topic Starter
  • Member
  • PipPipPip
  • 262 posts
Thanks rushin1nd,

I deleted the file after turning off system restore, and it's not reappearing.

I'm still not sure why it was created, but my guess is it was due to using a restore point that had an older version of QuickTime. I undid the restore but the config.msi was still on the C: drive (until I deleted it just now of course).
  • 0

Similar Topics

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

As Featured On:

Microsoft Yahoo BBC MSN PC Magazine Washington Post HP