2 reproducable bugs related to Windows System Restore

wolbrink · Post by **wolbrink** » Fri Jan 27, 2006 10:00 am

I have discovered a bug with InstallAware setups related to using System Restore.

1. I installed a version of my product, TntMPD 2.0 r6:
http://download.tntware.com/tntmpd/2.0. ... TntMPD.exe

2. I create a system restore point named "My Test".

3. I install a new version of my product, TntMPD 2.0 r8
http://download.tntware.com/tntmpd/2.0. ... TntMPD.exe

4. I restore the system restore point named "My Test".

5. I go to Add/Remove Programs, and select TntMPD and click "Change".
--> An InstallAware dialog appears, then a message box saying:
"Setup resource not found"

6. I try to install the new version of my product, TntMPD 2.0 r8.
--> At the point in the install wizard where the actual installation is about to take place, I get a message box saying:
"Error reading from file: C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{2800B~1\\OFFLINE\\IFDEBITNMPEXFTRGETDIRFFFFFFFFF0\\TntMPD.exe. Verify that the file exists and that you can access it."

--Troy

MichaelNesmith · Post by **MichaelNesmith** » Fri Jan 27, 2006 11:02 am

Hi Troy!

I would guess this is naturally occuring, because Windows is rolling back changes as part of its System Restore process.

wolbrink · Post by **wolbrink** » Fri Jan 27, 2006 11:31 pm

But shouldn't I be able to install the newer version of my program from the original setup.exe over again?

When I run my newer setup exe (TntMPD 2.0 r8 ), after it extracts its files and starts and I get that error, I noticed that the:
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{2800B~1\\OFFLINE
folder was incomplete.

I deleted that folder and then re-ran the setup. After this it worked.

Could InstallAware be corrected to detect this situation and work automatically.

I'd much rather tell my users to just run the latest version of my program to fix this situation than to tell them to delete the:
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{2800B~1\\OFFLINE
folder.

--Troy

wolbrink · Post by **wolbrink** » Fri Jan 27, 2006 11:44 pm

MichaelNesmith wrote:I would guess this is naturally occuring...

When you say "this" are you referring to the issue described in my step #5 or step #6 or in both?

--Troy

MichaelNesmith · Post by **MichaelNesmith** » Sat Jan 28, 2006 8:17 am

System Restore is in both cases breaking the consistency of the setups installed on the system. Therefore "this" is to both.

While we cannot account for every case in which files are randomly removed from the system, you have already found a suitable workaround in this case. I'd suggest you rename that folder using the MoveFileA Win32 API in kernel32.dll from your setup.

Post by **sinan** » Sat Jan 28, 2006 9:14 am

Hi Troy!

Great to hear from you, as always

Michael asked me to review this case and I think I agree with him here. As far as I know System Restore is not even supposed to touch the folders InstallAware uses internally. Am I wrong about that?

Please let us know if you find more information on this one...

wolbrink · Post by **wolbrink** » Mon Jan 30, 2006 1:03 pm

sinan wrote:Hi Troy!

Hi Sinan!

sinan wrote:Great to hear from you, as always

Same here.

sinan wrote: Michael asked me to review this case and I think I agree with him here. As far as I know System Restore is not even supposed to touch the folders InstallAware uses internally. Am I wrong about that? Please let us know if you find more information on this one...

System Restore was working as designed and documented. System Restore scans every folder not specifically excluded in "c:\\windows\\system32\\restore\\filelist.xml". This includes "C:\\Documents and Settings\\All Users\\Application Data" and all subfolders (the ones created and used by InstallAware generated setup programs). The list of file extensions it checks for is also included in filelist.xml. When you do a restore it restores protected files that were originally present and deletes protected files that were not originally present.

So let's say I install version A, and take a system restore snapshot, then I install Version B and restore my snapshot. Now... The registry is restored so that the Add/Remove control panel for the app is pointing to the partially restored folder for A which only includes *.exe, *.dll and *.msi. It's partially restored because not every original file was included in the protected file extension list. The folder for B is partially deleted because System Restore deleted the *.exe, *.dll and *.msi files (leaving the rest). Ultimately it would be nice if InstallAware only put files with protected file extensions into these folders, because then everything would either be restored or everything would be deleted. This would cause the state of the entire folder to be consistent.

MichaelNesmith wrote:While we cannot account for every case in which files are randomly removed from the system...

If the user was randomly deleting files, I'd agree that they are on their own. But this is far from "random", it was a result of the user using a known feature of the underlying platform.

MichaelNesmith wrote:you have already found a suitable workaround in this case. I'd suggest you rename that folder using the MoveFileA Win32 API in kernel32.dll from your setup.

I'd much rather keep my scripts focused purely on installing my application and not on working around fragility in the underlying engine. Before I started using InstallAware I hand-built my installation program from the ground up. I made the move to InstallAware to avoid having to maintain special code for exactly these kinds of things.

--Troy

Post by **sinan** » Mon Jan 30, 2006 7:38 pm

Dear Troy

You reported above that the OFFLINE folder is incomplete...which is why I am lead to conclude System Restore is not working properly. If System Restore is deleting new additions, and restoring old versions, that folder should be complete - either for the old version of the product, or for the new version. Apparently System Restore is mixing the state of both products, and I believe this to be the root cause of this evil.

Any ideas why its leaving that folder in an inconsistent, undefined state?

wolbrink · Post by **wolbrink** » Mon Jan 30, 2006 10:41 pm

sinan wrote:If System Restore is deleting new additions, and restoring old versions, that folder should be complete - either for the old version of the product, or for the new version. Apparently System Restore is mixing the state of both products, and I believe this to be the root cause of this evil. Any ideas why its leaving that folder in an inconsistent, undefined state?

System Restore is not mixing the state of both products, because each product revision has its own folder. The folders are not left in a mixed state but rather each is in a partial state. This is because of the way System Restore is designed to work (for better or worse).

Let me try to explain this again with an example. Let's say I install my product with revsion code {A}. This leaves the following example files for future maintenance:

C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\setup.msi
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\setup.exe
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\setup.dat
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\OFFLINE\\IFDEB123\\myapp.exe
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\OFFLINE\\IFDEB125\\myfile.txt

Now I create a system restore point (called "After {A}"), and then install my product with revision code {B}. This deletes all the files for {A} and leaves me with these files for future maintenance:

C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\setup.msi
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\setup.exe
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\setup.dat
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\OFFLINE\\IFDEB123\\myapp.exe
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\OFFLINE\\IFDEB125\\myfile.txt

Now at this point I perform a system restore to "After {A}". System restore doesn't protect .txt or .dat files, but it does .exe and .msi files. After the protected files are restored for {A}, you see this:

C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\setup.msi
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\setup.exe
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{A}\\OFFLINE\\IFDEB123\\myapp.exe

And the protected files that didn't exist when "After {A}" was created are removed. This leaves the following files for {B}:

C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\setup.dat
C:\\DOCUME~1\\ALLUSE~1\\APPLIC~1\\{B}\\OFFLINE\\IFDEB125\\myfile.txt

Now at this point you can't uninstall {A} and you can't reinstall {B}. It's somewhat understandable to me that you can't uninstall {A} without the original media. But I'd prefer if I could tell my user to install the latest version of my product to get back on track. But if that latest version is {B} this won't work because of the bug I reported. I'd prefer if the setup engine didn't give up so easily when extracting files and checked for the existence of just one protected (ie. .exe) file before assuming the whole payload is there.

--Troy

Gizm0 · Post by **Gizm0** » Tue Jan 31, 2006 5:27 am

I don't think that InstallAWARE is scanning or is actually depending on the extract folders, but it uses the GUID and revision codes from the Windows Installer Engine..If Windows Installer Engine get's screwed (registry is restored, therefore screwed) then i guess InstallAWARE will get screwed and not work ok..

wolbrink · Post by **wolbrink** » Tue Jan 31, 2006 9:29 am

Gizm0 wrote:I don't think that InstallAWARE is scanning or is actually depending on the extract folders, but it uses the GUID and revision codes from the Windows Installer Engine..If Windows Installer Engine get's screwed (registry is restored, therefore screwed) then i guess InstallAWARE will get screwed and not work ok..

Actually, I asked Sinan about this quite awhile ago, because I was concerned about having these "extra" folders on my end user's hard drives taking up unnecessary space. He said, "It should keep only the last copy. It occurs only if you use Web builds. The downloaded media blocks are placed into this folder. They are then used to install the product. If the user later wants to repair/modify the installation, no re-download occurs this way. I could have it delete the folder after the install occurs, but then this would be very frustrating for users - needing to redownload everything. They already cannot do repair/modify on the SFX/CD builds without having the original media handy, so I thought it would be a good idea to have the Web builds behave differently."

These folders are created by InstallAware, and not by the Windows Installer Engine. They are created (by InstallAware) when installing "Compressed Web-based EXE" installations because the assumption is you won't keep the original media around (ie. the original CD).

Again, let me say that it's understandable that you can't uninstall the old version with the partially reconstructed folder generated by System Restore. But I should be able to tell my user to re-download the latest version of my setup (which is self-contained and complete) and install it to get back on track.

--Troy

CandiceJones · Post by **CandiceJones** » Tue Jan 31, 2006 9:52 am

Hi Troy!

It seems System Restore is indeed leaving around partially restored files and folders and confusing our setup engine. To make matters worse, System Restore can also be customized by end-users, before or after running an InstallAware setup, so the list of files it preserves changes, before and/or after running an install.

What remedy would you suggest in this case, given the complete unpredictability of which files may remain and which may not? We understand you perceive this as underlying fragility of the setup engine, so please let us know how you would fix the engine, and we'll have our developers take a good look at this.

wolbrink · Post by **wolbrink** » Tue Jan 31, 2006 10:38 am

CandiceJones wrote:It seems System Restore is indeed leaving around partially restored files and folders and confusing our setup engine. To make matters worse, System Restore can also be customized by end-users, before or after running an InstallAware setup, so the list of files it preserves changes, before and/or after running an install.

Yes, I totally agree.

CandiceJones wrote:What remedy would you suggest in this case, given the complete unpredictability of which files may remain and which may not? We understand you perceive this as underlying fragility of the setup engine, so please let us know how you would fix the engine, and we'll have our developers take a good look at this.

For the first issue I reported (not being able to uninstall/repair the restored installation given the partially restored maintenance files), instead of the "Resource not found" error, I'd like to see a better message that tells the user they need to obtain the original setup.exe.

For the second issue I reported (not being able to install the latest version with the original installation setup.exe), I'd suggest that when running the original (outer) setup.exe that the "OFFLINE" folder always be deleted and rebuilt. Also the files above the "OFFLINE" folder should be restored if missing (it may already do this). (An alternative would be to verify the complete contents of the "OFFLINE" folder and the files above it and add them back as necessary.)

For any folders next to the "OFFLINE" (web media blocks) the IA script engine should verify that the files inside the web media block folder are all present. If the files are not all there the partially complete folder should be deleted forcing a re-download of the web media block if it is needed.

When this is done, InstallAware installations will be less assuming and more robust, and won't be caught off guard by users doing a System Restore. It may prompt the users to redownload the original setup.exe or web media, but that's alot better than giving the users error messages that are hard for them to understand. Ultimately this will empower the end user to get their job done, and will reduce tech support hassles.

--Troy

Tiago · Post by **Tiago** » Wed Oct 07, 2009 11:11 am

Is this fix already implemented on version 9?

Tiago · Post by **Tiago** » Fri Nov 27, 2009 8:58 am

Candice? Is anybody there?