Debug Installshield pendingfilerenameoperations that cause a reboot

Question

Hi,

Starting with a already existing installscript 11.5 installer, we created a update installer (differential installer).

Given:

• V1 (first version of the software)
• V2 (second version of the software)
• V2P (differential installer between V1 and V2

If I install V1 and deinstall it, no reboot is required

If I install V2 and deinstall it, no reboot is required

If I install V1, V2P and then deinstall it, I'm asking to reboot!

I checked with different registry and disk monitoring tools and it seem that the combination of V1 + V2P is equal to V2.

Given another tool, it seems that "pendingfilerenameoperations" forces the reboot. I assume this is du to my differential installer.

Does anyone know what can be the cause or at least, how to find it?

Edit : I know the the cause of the reboot (pending file rename operation) and I know the files that are in there, but I want to find an explanation of why installshield write these pending file rename operation.

Edit 2 : I found that this is InstallShield that is putting all the files of his runtime in pending file rename operation. This can leave to unexpected errors ... does any one know how to solve that?

Any help would be greatly appreciated,

Regards,

Nic

Answer 1

Have you tried running PendMoves from Sysinternals/Microsoft? According to the documentation, it should list the particular file(s) being moved or deleted. I'm assuming this will work for file renames as well

http://technet.microsoft.com/en-us/sysinternals/bb897556.aspx

Edit: If you know which files need to be renamed, you might try running Process Explorer (also from Sysinternals) and searching the file handles for references to the file(s) in question. It's possible something has them locked - either the installer never closed, or the app/service is running in the background.

Answer 2

Have you created a log file when uninstalling to see what file rename operation is being performed? I would strongly suggest using verbose logging for this problem.