Config.Msi folder and problem

[Peter]

Hi,

Actually I had a post about the problem before (see "Retained .msi or .rbf
file" by Peter on 3/4/2002), and expect reply from Ruidong Li. Now I have
some updates on the problem and hope get some solutions/suggestions from
anybody who had similar issue or and idea.

After more tests/trials on the package, here are some new findings:
1) With our package (Dev7.02 Basic, with major upgrading ability, installed
on w2k), it can stably reproduce the error by installing -> reboot ->
uninstalling, which will result in a Config.Msi dir under C: drive with a
.rbf file, and a reg entry (HKLM\System\CurrentControlSet\Control\Session
Manager\ PendingFileRenameOperations) with the .rbf file as it's value.

2) That only happens when I uninstall the package from Add/Remove applet, if
I run commandline (msiexec /x thefile.msi), there is no problem.

3) Dump packages with or without CA (but without upgrading ability) don't
have that problem.

Seems to me that the problem is either related to upgrading or to something
I did wrong in my package, and not to the engine or dirver, because of 3),
do you guys think so? InstallShield told me that the problem is from
Microsoft (MSI), what do you think?

Ruidong, if you see this post, could you please let me know your idea?
InstallShield people said I should contact MS people on that.

Thanks,
Peter

[Ruidong Li]

What happen if you do a reboot after the on installation? From the
problemLog, Windows Installer was not able to delete one .rbf file:

RollbackCleanup: File: E:\Config.Msi\595d4.rbf
Info 1903.Scheduling reboot operation: Deleting file
E:\Config.Msi\595d4.rbf. Must reboot to complete operation.

This could occur when files are still in-use during the un-installation, so
Windows Installer was not able to remove the actual file until after a
reboot and .rbf file will not get removed until the corresponding file is
removed.

Thanks!
Ruidong [MS]

This posting is provided "AS IS" with no warranties, and confers no rights.

[Peter]

Ruidong,

Thanks for your reply.
What do you mean to "do a reboot after the on installation"? To add a reboot
CA after 'OnInstallation' (I don't think InstallShield has this standard
CA)? If you mean to reboot immediately after installation, that's what I
just have done.

I understand that there is file in-use during uninstallation, but how can I
get more information on which file (or why) is that?

Your help is really appreciated,
Peter

"Ruidong Li" <ruido...@online.microsoft.com> wrote in message
news:xZefxAr2BHA.396@cpmsftngxa07...

[Ruidong Li]

Hello Peter,

Sorry about the confusion, I mean do a reboot after the un-installation.
You could do this either manually or set REBOOT property to Force.

[Peter]

Ruidong,

The whole problem is that 'WE DON'T WANT THIS HAPPEN', not how to fix it
AFTER it happened.

Your idea is right, the reboot after uninstallation does eliminate the
folder, but our problem already happened at install. As I stated in my
previous posts, if the install cause this folder (plus the reg entry)
happens after INSTALL (not UNINSTALL), then bad things happen to our
application (refer to previous posts for details).

How to prevent it from happening?

Thanks,
Peter

"Ruidong Li" <ruido...@online.microsoft.com> wrote in message

news:Z9sYakO3BHA.2184@cpmsftngxa08...

[Erik Kupferer [MS]]

Hi Peter,

The file that is in use is FDEventMsg.dll. It is an NCR file. If the
Windows Installer encounters any files in use when it attempts to
install/upgrade/remove them they are flaged for install/upgrade/removal
upon reboot. If you want the Windows Installer engine not to require a
reboot to replace this file then you will need to find what
application/process is holding this file and kill it. That has be done
before you launch the Windows Installer to install/upgrade/remove your
application that contains this file.

I hope that helps.

Let me know if you have any questions.

Regards,

- Erik

[Peter]

Erik,

Is there a standard way "to find what application/process is holding this
file and kill it"?

We have our application files installed in one dir, so I probably can loop
through all of them before install/upgrade/remove, and find out which is in
use, and kill it.

Thanks,
Peter

"Erik Kupferer [MS]" <eri...@online.microsoft.com> wrote in message
news:acfnDUY4BHA.1596@cpmsftngxa08...

[Ruidong Li]

I don't know if there is a standard way to find out what files are hold by
which process/application. Without writing any code, you could download
the Process Explorer utility from www.sysinternals.com to find out all
files that is been hold by each running process.