2

Found a similar question, but the the accepted "answer" is not actually an answer at all: MSIEXEC: "Executing op: ShortcutRemove" step is very slow

Is there a know issue with Wix / Windows Installer being very slow when uninstalling shortcuts?

I have a msi project that creates a lot (85+) of shortcuts in my installation folder. When I install, all goes very quickly and completes successfully in under a minute. However, when I uninstall, it takes in excess of 6-8 minutes. Computer is physical machine with a fast SSD. tested on Windows 10 Pro and Windows Server 2019.

All shortcuts are created on the local C: drive and target files on that same drive.

I am not very experienced with Wix and the Windows Installer, but the uninstall log looks clean to me. Only the ShortcutRemove operations taking longer then expected and every one has "Note: 1: 2318 2: C:\Config.Msi\??????.rbf" (File does not exist). Each ShortcutRemove operation takes 4 to 5 seconds, which obviously adds up because of the (admittedly high) number of shortcuts that I need to create.

From the log, there is about 3 seconds delay between every line showing error "Note: 1: 2318" and the following "Executing op: SetTargetFolder" line.

The project has had this many shortcuts for many years, but I only started noticing the slow down for uninstalls in mid 2019.

Build Environment / Tools

Visual Studio Pro 2017

Wix version 3.11.2.4516

Windows Installer. V 5.0.19041.1

UPDATE 1 - 28-Aug-2020

I suspect that this may be an issue with a Windows o/s patch or new security policy, because I have been using the same .msi and Wix project for a few years and did not see the slow down on Windows 10 prior to mid 2019 - the related post I referenced at the top is from that period as well. I also suspect that this may be happening to many other .msi projects, but the developers are not noticing because they only have a very small (normal) number of shortcuts.

Additionally, I just tested on Windows Server 2016 and found that uninstall is NOT slow on that o/s at all!

FAST: Microsoft Windows Server 2016 Datacenter, Version 1607 (OS Build 14393.3564)

Slow: Microsoft Windows Server 2019 Datacenter, Version 1809 (OS Build 17763.1397)

Slow: Microsoft Windows 10 Pro, Version 2004 (OS Build 19041.450)

This is an extract of the uninstall log:

MSI (s) (98:54) [13:09:59:071]: Using source file security for destination.
MSI (s) (98:54) [13:09:59:073]: Note: 1: 2318 2: C:\Config.Msi\13a736b0.rbf 
MSI (s) (98:54) [13:10:01:503]: Executing op: SetTargetFolder(Folder=23\My Tiny Utilities\)
MSI (s) (98:54) [13:10:01:508]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs
MSI (s) (98:54) [13:10:01:509]: Executing op: ShortcutRemove(Name=lddyopzj|Touch)
MSI (s) (98:54) [13:10:01:513]: Verifying accessibility of file: Touch.lnk
MSI (s) (98:54) [13:10:01:515]: Using source file security for destination.
MSI (s) (98:54) [13:10:01:516]: Note: 1: 2318 2: C:\Config.Msi\13a736b1.rbf 
MSI (s) (98:54) [13:10:03:964]: Executing op: SetTargetFolder(Folder=C:\MyTinyUtilities\Shortcuts\)
MSI (s) (98:54) [13:10:03:966]: Executing op: ShortcutRemove(Name=n5w0rmgl|Touch)
MSI (s) (98:54) [13:10:03:970]: Verifying accessibility of file: Touch.lnk
MSI (s) (98:54) [13:10:03:974]: Using source file security for destination.
MSI (s) (98:54) [13:10:03:977]: Note: 1: 2318 2: C:\Config.Msi\13a736b2.rbf

This is an extract of my shortcut creation script/code:

  <!--Start Menu Shortcuts-->
  <Fragment>
    <DirectoryRef Id="DirShortcutsStartMenu">
      <Component Win64="no" Id="CMP_Shortcuts_StartMenu" Guid="86F485AE-B257-4E8A-8D06-59EE9161B8F9">

        <RegistryValue Root="HKCU" Key="Software\MyTinyUtil" Name="Start Menu Created" Type="string" Value="Yes" KeyPath="yes" />
        <Shortcut Id="SM_Touch" Name="Touch" Description="Update file modified date" Target="[MTUINSTALLROOT]Touch.exe" />
        ...
        I create about 10 shortcuts on the Start menu path
        ...
        <RemoveFolder Id="Remove01" On="uninstall" />

      </Component>
    </DirectoryRef>
  </Fragment>

  <!-- Shortcut in installation Folder-->
  <Fragment>
    <DirectoryRef Id="DirShortcutsInstallFolder">
      <Component Win64="no" Id="CMP_Shortcuts_InstallFolder" Guid="102EC0F4-03BD-48E9-8086-6D5DA4624FA3">
      
        <RegistryValue Root="HKCU" Key="Software\MyTinyUtil" Name="Duplicate Shortcuts" Type="string" Value="yes" KeyPath="yes" />
        <Shortcut Id="IF_Touch" Name="Touch" Description="Update file modified date" Target="[MTUINSTALLROOT]Touch.exe" Directory="Dir_C_Shortcuts_File_Utils" />
        ...
        I create in excess of 85 shortcuts in a sub-folder of my installation folder.
        ...
        <RemoveFolder Id="Remove02" On="uninstall" />

      </Component>
    </DirectoryRef>
  </Fragment>
Tech-On-the_Beach
  • 461
  • 3
  • 9
  • Have you tested on a clean virtual and you see the same result? Is this a fast disk or a snail disk of old? I have seen slow response with shortcuts pointing to network resources and such things - particularly if they are unreachable. – Stein Åsmul Aug 26 '20 at 01:19
  • All shortcuts are created on the local C: drive and point to files on that same drive. I have tested and recreated the issue on multiple computers and o/s. It happens on physical SSD-based machines as well as hosted virtual machines, on Windows 10 Pro and Windows Server 2019. My report of uninstall taking 6-8 minutes while install was under 1 minute was on Win10 Pro running on physical i7-6700, 16GB RAM, with SSD disk. It takes longer on virtual machines. – Tech-On-the_Beach Aug 26 '20 at 10:27
  • Is the MSI possible to see? That helps a lot to eliminate "the worst theories" - as in you try to think of anything and it is usually something simple. Perhaps a directory resolution issue or an issue with rollback. Speaking of rollback. Try to disable it and test again? [DisableRollback](https://docs.microsoft.com/en-us/windows/win32/msi/disablerollback) and [DISABLEROLLBACK property](https://docs.microsoft.com/en-us/windows/win32/msi/-disablerollback). Rollback files are saved to allow the setup to cancel and then put files back in place (and a few things more). Hence slowing things. – Stein Åsmul Aug 26 '20 at 13:56
  • Unfortunately the MSI is for internal use and not publicly available. Thank you for taking the time to comment on this. I will look into and test disabling rollback and report back. – Tech-On-the_Beach Aug 26 '20 at 19:34
  • I honestly don't think it will do much, but maybe try to add all debugging information to your uninstall log using the `x` switch: `msiexec.exe /x {PRODUCT-GUID} /L*vx! C:\Your.log` ([MSI logging](https://stackoverflow.com/a/54458890/129130), [uninstalling](https://stackoverflow.com/a/1055933/129130)). – Stein Åsmul Aug 27 '20 at 16:31
  • The `x` switch writes the log continuously so no log buffer is lost if there are crashes. [See this answer](http://www.installsite.org/pages/en/msifaq/a/1022.htm). This continuous writing makes the uninstall process (even) slower, but you get all the logging that is possible to get - barring anything in the event viewer. – Stein Åsmul Aug 27 '20 at 16:37
  • Just off the top of my head - maybe check if the files pointed at have the *`"Downloaded from the Internet"`* flag enabled - or some other flag: [see this answer](https://stackoverflow.com/a/51433150/129130). If so unblock the file and also try other combos of flags. Also: do you do any custom ACL permissioning? – Stein Åsmul Aug 28 '20 at 00:18
  • @SteinÅsmul thanks for the pointers and trying to help. I read about DisableRollback and decided not to try it in the end. I was already generating the log with the /L*vx! switches. Files are not flagged as Downloaded. I just updated the post again because I suspect more strongly now that this is to do with an o/s update sometime last year, because I did more tests and found that the uninstall is NOT slow on Win 2016. I am trying to get access to more o/s version to test on. – Tech-On-the_Beach Aug 28 '20 at 16:04
  • I would try [Procmon.exe](https://stackoverflow.com/a/47792474/129130) or [Process Explorer](https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer) to try to figure out what is happening. [More on debugging](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debuggers-in-the-debugging-tools-for-windows-package) - I just try to use Visual Studio most of the time. – Stein Åsmul Aug 28 '20 at 16:51
  • *The problem is probably just a shortcut or two pointing to a non-existing file* - or a file that is actually [a link itself of some sort](https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions). [Symbolic links](https://docs.microsoft.com/en-us/windows/win32/fileio/symbolic-links). – Stein Åsmul Aug 28 '20 at 16:58
  • 1
    Too many comments, but there is also [DebugView from Sysinternals](https://docs.microsoft.com/en-us/sysinternals/downloads/debugview). – Stein Åsmul Aug 29 '20 at 00:55
  • I would build a new MSI with all identified problem shortcuts removed - if possible - and test that the problem still exists. You can also remove half of them - binary search-style - and see if the problem still strikes? Then half and half and half till you narrow it down. There are some properties you can try to set [DISABLEADVTSHORTCUTS](https://docs.microsoft.com/en-us/windows/win32/msi/disableadvtshortcuts) - I don't see how that will help to be honest, but worth a mention. Maybe the fast computer just had a fast disk and the shortcut resolution was done quicker? – Stein Åsmul Oct 20 '20 at 14:37
  • The issue of [Win32 long-paths](https://superuser.com/a/1119980/11906) - I doubt it has impact, but maybe try to look at system policy differences? Probably the first thing you did? – Stein Åsmul Oct 20 '20 at 14:40
  • @SteinÅsmul thanks for trying to help with this once again. I have moved on to another project and put this on hold for now. FYI, before I did, I had gone as far as creating a totally new demo wix project from scratch that installs only simple .txt files and created simple shortcuts to those files. Even the wix code was very basic stuff copied from the reference docs. Still I found that the shortcut removal process was just as slow as my original production project. – Tech-On-the_Beach Oct 20 '20 at 16:25
  • If you check that project into github.com or something similar, maybe we can have a look. I seem to recollect this issue and a fix, but I can't remember what it was. Goldfish memory. – Stein Åsmul Oct 20 '20 at 18:56

0 Answers0