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.
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?
