Debug Installshield pendingfilerename operations that cause reboots

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

Given:

  • V1 (first software version)
  • V2 (second software version)
  • V2P (differential setter between V1 and V2

If I install V1 and uninstall it no reboot is required

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

If I install V1, V2P and then uninstall it, I ask to reboot!

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

Considering another tool, it seems that "pendingfilerenameoperations" is causing it to reload. I assume this matches my differential installer.

Does anyone have any idea what might be causing it, or at least how to find it?

Edit . I know the reason for the reboot (pending file rename operation) and I know the files that are there, but I want to find an explanation why installshield is writing this pending file to rename operation.

Edit 2 . I found it was InstallShield, which puts all of its runtime files in a pending file rename operation. This can lead to unexpected errors ... does anyone know how to solve this?

Any help would be greatly appreciated,

Hello,

Nick

0


source to share


2 answers


Have you tried running PendMoves from Sysinternals / Microsoft? According to the documentation, it should indicate which files (files) are being moved or deleted. I assume this will work for renaming files as well.

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



Edit: If you know what files need to be renamed, you can try starting Process Explorer (also from Sysinternals) and searching for files for links to the file (s) in question. It is possible that something is blocked - either the installer never closes, or the app / service is running in the background.

+1


source


Did you create a log file when uninstalling to see what file rename operation is in progress? I would highly recommend using a verbose log for this problem.



0


source







All Articles