Issues with files being removed after reboot.

[bagofgloom]

In the past month the installer we have been using for years started writing files out to PendingFileRenameOperations to be renamed. Outside of adding a new side image no other changes have been done. No message to reboot was displayed. To my knowledge we do not hide this message because we rely on the installer to tell the user. The files being locked didn't make any sense because I was testing on a closed system and the application has never been ran on any of these VM's. With it being a closed environment there was no chance the application would be started by anyone else. I added multiple reboot tests to the SetupBuilder script. I tested right after the uninstall and before the installer finished. $SB_RESTARTFLAG$ flag was never set. I tested on multiple OSes. I tested on 2008 R2, 2012 R2, 2016 R2, Windows 7, Windows 8.1 and Windows 10. I am on SetupBuilder Developer Edition 2019.5 Version: 10.0.6275. My script version has been upgraded but was originally SB7 and still says SB7. The text at the top says Created with build: 7.0.2680. I realize that just because the script worked for years does not mean it will always work. I guess I am looking for something else I can test to see why this is happening all of a sudden.

I tested this issue two different ways and in both cases I made sure there were no files in PendingFileRenameOperations. None of these installs or uninstalls set the $SB_RESTARTFLAG$ flag.

1. I tested by just uninstalling the program. When the uninstall finished PendingFileRenameOperations had 72 lines of files that needed to be renamed or removed. All of the files were in groups of three. However the directory no longer existed because the uninstall was successful. I would have expected the files to still be in the directory if they were locked.

2. I ran the installer. The installer uninstalls the program then reinstalls it. This removed the directory and then reinstalled to the same directory. No errors. The same files were in PendingFileRenameOperations. Now when I reboot after the install even thou I was not instructed to those 24 files get removed. I have no idea whether this is because the BACKUP directory does not exist or if it is because there are three lines instead of two. Either way the files get removed and the application will not start.

Below is three of the files that were in PendingFileRenameOperations.

\??\C:\Program Files (x86)\CompanyName\ProductName\Infragistics4.Win.v1 9.1.dll
\??\C:\Program Files (x86)\CompanyName\ProductName\BACKUP\Infragistics4 .Win.v19.1.0001
\??\C:\Program Files (x86)\CompanyName\ProductName\Infragistics4.Win.v1 9.1.dll

\??\C:\Program Files (x86)\CompanyName\ProductName\Infragistics4.Win.Ul traWinTree.v19.1.dll
\??\C:\Program Files (x86)\CompanyName\ProductName\BACKUP\Infragistics4 .Win.UltraWinTree.v19.1.0001
\??\C:\Program Files (x86)\CompanyName\ProductName\Infragistics4.Win.Ul traWinTree.v19.1.dll

\??\C:\Program Files (x86)\CompanyName\ProductName\Infragistics4.Win.Ul traWinToolbars.v19.1.dll
\??\C:\Program Files (x86)\CompanyName\ProductName\BACKUP\Infragistics4 .Win.UltraWinToolbars.v19.1.0001
\??\C:\Program Files (x86)\CompanyName\ProductName\Infragistics4.Win.Ul traWinToolbars.v19.1.dll

[linder]

Hello,

it's not really the installer that is writing to "PendingFileRenameOperations". The installer detects "locked" (in-use) files and as a result, Windows logs them for being renamed at the next reboot. But by default, there should be a "Restart" message at the end of the installation (if the installer replaced in-use files). If it is a silent installation, I would suggest to check the status of General Information -> Advanced Settings -> Reboot Message at Silent Install

BTW, using a .sb7 extension in SB10 is not a problem. All (upgraded) project files formats are fully backward compatible. The text at the top (created with 2680) is just a script comment.

Friedrich

[bagofgloom]

This is not a silent installation. Even if a reboot was required it still would not put the files back correctly. The "BACKUP" path does not exist. In the case of an uninstall only the whole directory no longer exists. If the program has never been loaded then I wonder what is locking the files. The installer? Windows? Anti-Virus software? I installed dozens of times at some point I would think these files would not be locked especially right after a reboot.

Here are my generator and advanced settings.
4955

[linder]

If there are files in PendingFileRenameOperations then the installer had to replaced locked (in-use) files. The Windows API to check for write permission returned FAILED. By default, the un-/installer always asks for a reboot if it replaced in-use files. If you are interested, send me your project file (including custom .sbi files) and I'll review your script. It would be cool if you could give me access to your setup.exe. Then we can debug it in real-time.

Friedrich

[bagofgloom]

I received permission to send the script and the exe. Where do I send it?

[linder]

Could you please send it to support@lindersoft.com

If the .exe is too large, it would be great if you could send us a download link.

Thank you!

Friedrich

[bagofgloom]

I emailed the files and a link to the installer. On Nov. 5th. I have not received a response yet.

[linder]

Sorry for the delay. There's too much going on here at the moment. Testing a hotfix for a Windows 10 update right now.

We'll check your project tomorrow.

Friedrich

[linder]

Hello,

unfortunately, we were unable to reproduce it here on our test machines (VMs).

What steps are required to see this issue? Do we need a previous version and the new TVInstaller.exe? We do not get an uninstall prompt when doing a reinstall with the same TVInstaller.exe

Thank you!

Friedrich

[linder]

Hello,

okay, it took some time to find out what causes the issue in your project. It's caused by your Line 302 (see attached screenshot). Why do you remove this BACKUP folder?

Our debugging process found out that you install several files multiple times. For example:

Infragistics4.Documents.Core.v19.1.dll
Infragistics4.Documents.Excel.v19.1.dll
Infragistics4.Documents.IO.v19.1.dll
… and more ...

Installing the same file multiple times creates backup copies in the BACKUP folder. The main problem here is that you remove the backup folder after your installation.

To fix your problem:

1. Do not install the same files multiple times (I think it's caused by our wildcards *.*)
2. Do not remove the BACKUP folder

And as a side note, the registry manipulation in lines 210 and 211 is not allowed in Windows. Please remove the "Wow6432Node" entries.

Does this help? After you have fixed this, your install and uninstall should work again as expected.

Friedrich

[bagofgloom]

Sorry for the delay I needed to research log files from source control to see when and why we removed the backup folder. The decision to delete the backup folder was done in 2013 when we changed the company name. The installer had issues with uninstalling from the previous install directory to a new directory. A backup folder with information that was no longer useable was created and eventually restored when the end user rebooted. The end user was never alerted to reboot so an unusable install directory had large files in a backup folder that were never going to be used or needed. This prevented the folder from being removed completely like an uninstall should have done., When the end user eventually did restart these files would be put back into the old install directory and stay there forever or until the end user manually deleted them. Additional issues thou similar to the above issue. If the end user simply decided to uninstall product and not reinstall it. The backup folder was created with install files that were no longer needed. Same result the end users did not like the files being left behind that were not being used. Nor would I. The final issue is also related to the first but caused many more issues. If the end user upgraded the product it would also create a backup folder. This backup folder would get bigger and bigger because the end user was never told to reboot. 3-6 months later they would reboot and the backup folder would put the old files back into place while leaving many of the new files. This caused many issues. Restoring 3-6 month old files that were no longer compatible not to mention files that may or may not even be useable. At one point we had multiple versions Infragistics DLL’s and other version specific DLL’s. Simply uninstalling the product would not clean up the issue because the uninstall was not aware all of these files were in the install directory. Looking back if we had known we were installing the Infragistics files multiple times some of these issues may have been resolved. Hard to really say that was almost 7 years ago.

I don’t believe previous install directory has ever worked correctly for us. If the product is currently installed in directory A and we want to install to directory B. The uninstall does nothing to directory A but it does install correctly to directory B. Not sure why that is or what is wrong with the script. I am open to any suggestions to improve our install script.

I added Infragistics*.* to the exclude, removed the backup delete line, and the WOW registry edits. This appears to have fixed our issue. Hard to say until it goes live but I no longer have the issues on our QA machines.

Is there a way we can see which files are being installed multiple times?
Is it as simple as reviewing the uninstall log?

[linder]

Hello,

to see which files are being installed multiple times, please check the compiler .htm report. Or send the .htm file to support [at] lindersoft [dot] com and we can tell you exactly which files are being installed (at least two times).

Friedrich

[bagofgloom]

Thanks. Can you see anything wrong with how I am using %PREVIOUSVERSION%? It does not work for us. If the product is currently installed in directory A and we want to install to directory B. The uninstall does nothing to directory A but it does install correctly to directory B.

[linder]

As far as I can see, you check for a previous version in Line 176. Are you sure that this code is executed at all and what is the value of %PREVIOUSVERSION% in your test? And are you sure the uninstall is executed in your Line 194? Does your command line /U "[PREV_UNINSTALL_LOG]" /S passes the correct and expected values to the uninstaller? If the uninstall does nothing, then I think it does not even execute and that's why it does nothing.

BTW, I would not do all these uninstall actions from within the LOOP WIZARD. If I were you I would do it after the Progress Dialog: Display () command.

And your use of "Wow6432Node" in your registry manipulation is incorrect. Not sure if this already makes a difference if you fix this and then run the deinstallation procedure.

Friedrich

[bagofgloom]

If you are referring to the "Wow6432Node" delete of the registry entry that was removed like I stated in a previous reply.

It does get into the code because %PREVIOUSVERSION% is correct and the wait dialog pops up to tell the end user it is uninstalling the previous version. I believe the issue is with the name of the log file and exe. The current program name is different and it tries to use the new name instead of the old name. If the old program was named Help and the new one is named HelpMe. It is using Uninstall_HelpMe.exe instead of Uninstall_Help.exe. I see why it does not work but I have no idea how to tell it to use the previous name instead of the new one. Plus this is a single installer so only one time would the name be incorrect the rest of the time it would be correct. Maybe it isn't possible. I suppose I could make the uninstall exe and log name generic.

The only reason the uninstall and .Net framework install is in the dialog loop is because it is the only way to alert the user that something is happening and the installer is still going. Without the wait dialogs the end user wonders what is taking so long.

I will figure it out thanks for your time.