My InstallScript MSI Project is unable to uninstall files from System64Folder

[JEichenberger]

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]

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]

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.

1. Installation Information: General Information: Template Summary = x64;1033
2. Installation Information: Organization: Setup Design: Default Feature: all components are listed under this feature which installs to [INSTALLDIR].  INSTALLDIR = ProgramFiles64Folder.
3. Some of the individual components have Destination = [System64Folder].
4. Every component has 64-Bit Component = Yes.
5. 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.
6. Every 64-bit component gets installed and runs okay.  They just don't get uninstalled.
7. 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.
8. An installer just like this one is also built for 64-bit Windows 7.  It does not have the same issue.

[JEichenberger]

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]

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]

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.