Hi all,

This is kind of an offshoot of another thread I started regarding chaining a 64 bit installation to a 32 bit installation.  What I actually had to do is install a native 64 bit installer with my 32 bit app and run the 64 installer on 64 Bit systems via a Custom Action that monitors the closing of of the initial 32 bit install process.  But I digress...

At times, when this 64 bit install is running, I get the MsiRMFilesInUse dialog displayed with Windows Explorer listed as the running program.  If a user chooses the automatically close option, Windows Explorer stops, the installer completes, but it appears Windows Explorer does not restart and a hard reboot is needed - not good.

If the do not close apps choice is made on the dialog, the installation completes and a reboot is required, which is not the end of the world and of course would be the preferable behavior.

My first thought was to just disable the close and restart option so they could only pick the second option, but I don't know that I like that.

Another approach would be to find out what is causing the hangup with Windows Explorer.  Does anyone know of any way to do this?  My 64 bit installer is basically a shell with a few registry entries added that encapsulates Merge Module components from a third party.

Any help in tracking the trigger for this dialog or another approach to force past the attempt to close and restart explorer would be greatly appreciated.  Again a reboot would not be the end of the world and I really don't want to just skip past this dialog if something is tied up.


UPDATE:  Our 32 bit installer now seems to require a reboot in some cases and the only difference with this release is the addition of third party Merge Modules.

How can I tell what component is running up against Windows Explorer causing the need for reboot?  Will logging show me that information?

0 Comments   [ + ] Show Comments


Please log in to comment

Community Chosen Answer


In Windows Vista or later, Restart Manager can detect processes that have files in use and stop and restart them without requiring a restart of the computer. By default this option is checked in all setup captured msi and most of the vendor msi... If you are using Wise Package Studio then go to Installation Expert->Windows Installer Option and uncheck the following check boxes

  • Use Restart Manager
  • Restart Registered applications that were shutdown by Restart Manager

This should reslove your issue...

Answered 07/31/2012 by: jagadeish
Red Belt

  • I am using InstallShield2012. Do you know what bits are flipped by changing the Wise options?
  • Add the following properties in property table

  • My only concern at this point would be, if I disable the restart/manager, what if the need for reboot is valid? Like I said I think I have the tie up linked to the third party components added via Merge Module but not absolutely sure at this point.

    Using the above props, is it possible to disable the restart manager so that if a reboot is needed, it occurs at the end fo the installation as it would on lets say XP?
  • My guess would be in silent mode that's what should happen
  • I'm running the install that is generating the need for reboot with /qb!. I think I might try /qb-! as that seems to work in limited testing. I'll turn that over to QA so they can beat it up.
  • It seems as though the problem with the restarting of a busy app during install may lie with the MsiRMFilesInUse dialog and/or InstallShiled.

    I was calling the install that prompted for reboot/app restart with /qb!, which does not suppress modal dialogs.

    If I changed the parameters to /qb-!, the busy app was closed, the installation completed and the app was restarted without hesitation or problem.
Please log in to comment


  • My concerns are listed above. Thanks for the information!
Please log in to comment
Answer this question or Comment on this question for clarity