- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: My InstallScript MSI Project is unable to uninstall files from System64Folder
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
My InstallScript MSI Project is unable to uninstall files from System64Folder
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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);
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/8C9D13A71C7F7695F3262372C0172D68/responsive_peak/images/icon_anonymous_message.png)