My InstallScript MSI Project is unable to uninstall files from System64Folder

JEichenberger · ‎Aug 12, 2019

I am using basically the general design for an installation kit on Windows 7 and Windows 10. I am using InstallShield 2018 (not R2), as that is what I have current licenses to use. Correct me if I am wrong, but for our multiple builds machines we would have to pay to upgrade to R2, right?

On Windows 7 I have enough issues to deal with, but at least when I uninstall or upgrade I can get old files to be removed from the System64Folder. On Windows 10, however, all attempts to replace or remove those files have failed.

One of the things that I have tried is to use a custom function, shown here:

//---------------------------------------------------------------------------
function void DeleteInstalledFile(szFolder, szFilename)
     // Delete the file from the specified folder and log the results.
     STRING svResult;
begin
     if (DeleteFile (szFolder ^ szFilename) == 0) then
         SprintfMsiLog("###> DeleteInstalledFile: %s\%s deleted", szFolder, szFilename);
     else
         DeleteFile(TempFolder ^ szFilename); // Make sure rename destination is removed
          if (RenameFile(szFolder ^ szFilename, TempFolder ^ szFilename) == 0) then
              SprintfMsiLog("###> DeleteInstalledFile: %s\%s renamed %s\%s",
                 szFolder, szFilename, TempFolder, szFilename);
              BATCH_INSTALL = TRUE;
          else
              if (FindFile(szFolder, szFilename, svResult) != 0) then
                  SprintfMsiLog("###> DeleteInstalledFile: cannot find %s\%s", szFolder, szFilename);
              else
                  SprintfMsiLog("###> DeleteInstalledFile: cannot rename %s\%s", szFolder, szFilename);
              endif;
          endif;
     endif;
end;

The DeleteFile operation fails. Then the RenameFile operation fails. Even the FindFile operation fails. And yet the file persists.

I have the Required Execution Level set to Administrator.

Using a command shell launched as administrator I can clean up these things manually. But of course I cannot ask our customers to use a batch script to make up for what the install kit will not do.

Varaprasad · ‎Aug 13, 2019

You can upgrade to InstallShield 2018 R2 with the same license (free minor upgrade).

I think something went wrong with your installer package. Is your application package a true 64-bit application or a 32-bit application being run on x64?

In order for Windows Installer to install to a 64-bit location on a 64-bit system, the component in the 64-bit Windows Installer package that contains the data for the 64-bit location must be marked as 64 bit. If a component in a 64-bit Windows Installer package is not marked as 64 bit, its data is installed to 32-bit locations.

JEichenberger · ‎Aug 13, 2019

Oh, there is something wrong alright. But it beats me what it could be.

Here are the check boxes that I can check as to what why I think it should work.

Installation Information: General Information: Template Summary = x64;1033
Installation Information: Organization: Setup Design: Default Feature: all components are listed under this feature which installs to [INSTALLDIR]. INSTALLDIR = ProgramFiles64Folder.
Some of the individual components have Destination = [System64Folder].
Every component has 64-Bit Component = Yes.
No warnings occur except for:
ISDEV : warning -6245: One or more of the project's components contain .NET properties that require the .NET Framework. It is recommended that the release include the .NET Framework.
Every 64-bit component gets installed and runs okay. They just don't get uninstalled.
Only one of those components is still actively busy during the uninstall process. I am willing to rename that one to move it out of the way, but even that fails.
An installer just like this one is also built for 64-bit Windows 7. It does not have the same issue.

JEichenberger · ‎Aug 15, 2019

I think I have found my own solution. I added calls to disable and enable WOW64FSREDIRECTION to DeleteInstalledFile. Disable at the start, enable at the end.

Disable(WOW64FSREDIRECTION);

Enable(WOW64FSREDIRECTION);

JEichenberger · ‎Aug 15, 2019

I am still missing the reason why I must force the issue with script files. These files should automatically get replaced and removed without my forcing the issue.

JEichenberger · ‎Aug 15, 2019

Wow! Nope. On Windows 10 this redirection crap adds a whole new annoying factor: windows\sysnative.

When running as a 32-bit application the application has to jump through a new hoop. It has to translate "%windir%\system32" to "%windir%\sysnative" manually.

Thank you Microsoft for one of the most confusing file systems ever.