Windows Installer: built-in FilesInUse detection is extremely slow when Restart Manager is disabled (minutes vs. seconds in InstallValidate)

Question

When Restart Manager is disabled either via the MSIRESTARTMANAGERCONTROL property or the Prohibit use of Restart Manager group policy, Windows Installer falls back to its built-in FilesInUse mechanism. We are seeing that this fallback makes InstallValidate dramatically slower whenever a file being removed/replaced is held in use by a running process: minutes with the built-in mechanism vs. seconds with Restart Manager, for the same operation on the same machine.

We can reproduce this with Microsoft's own .NET Desktop Runtime installers, and we see the same behavior in our own MSI packages. Verbose MSI uninstallation logs for .NET Desktop Runtime 8.0.28 are attached for both cases.

Slow FilesInUse windowsdesktop_runtime_8_0_28_win_x64_msi_SANITIZED.log

Fast RestartManager_windowsdesktop_runtime_8_0_28_win_x64_msi_SANITIZED.log

• RM prohibited by policy: InstallValidate takes 7 min 24 s (20:09:12 to 20:16:36), all in the files-in-use scan between the Note: 1: 2727 markers. The log confirms the fallback: RESTART MANAGER: Disabled by DisableAutomaticApplicationShutdown system policy; Windows Installer will use the built-in FilesInUse functionality.
• Policy reverted (RM enabled), same machine, same operation: InstallValidate takes ~7 seconds.

We deliberately disable Restart Manager in our company's MSI packages by setting MSIRESTARTMANAGERCONTROL=Disable because RM's automatic shutdown/restart of applications has caused problems for our users in the past. But disabling RM is now costing us multi-minute delays in our uninstalls and upgrades. On some systems, these delays reach 20–30 minutes per MSI, degrading the installation experience for our customers.

Other observations (details in the logs):

• The delay is far worse on busy dev machines than on clean VMs and appears to scale with the number of running processes; the built-in scan reported 8 processes including background services but only one process (NipbEditor) was holding the files being removed in use.
• The delay is caused by the amount of time spent in the detection of processes that are holding files in use. If no file being removed or replaced is held in use, no delay occurs.

The only description of the FilesInUse mechanism we found is the Windows Installer team's "MSI Files-In-Use V2" post: it enumerates HKEY_PERFORMANCE_DATA for all processes and their PE images, consistent with a whole-system scan whose cost grows with process count.

Questions

1. Is the built-in FilesInUse mechanism expected to be this slow, and to scale with the number of running processes? Any insight into how it works on modern Windows?
2. For packages that must never shut down/restart applications: is MSIRESTARTMANAGERCONTROL = 2 the recommended fix? The docs say value 2 keeps RM for detection but disables restart mitigation. Does it guarantee no process shutdown/restart, while giving us RM's fast detection? Same question for the policy equivalent, DisableAutomaticApplicationShutdown = 2.
3. Could the built-in FilesInUse path be made efficient (or its cost documented)?

Answer 1

Hello @Bhogaraju, Praneeth ,

Thank you for the detailed repro and for sharing the comparison logs.

Based on the documentation currently available, I could not find any Microsoft documentation that describes the performance characteristics or scaling behavior of the built-in FilesInUse detection mechanism when Restart Manager is disabled. The documentation explains what the FilesInUse mechanism does, but not how its detection algorithm is implemented or whether increased execution time with a larger number of running processes is expected behavior.

Regarding your second question, the documented setting that keeps Restart Manager detection while disabling Restart Manager's shutdown/restart mitigation is MSIRESTARTMANAGERCONTROL="DisableShutdown", or the equivalent policy setting DisableAutomaticApplicationShutdown = 2.

According to the documentation you referenced, these settings disable Restart Manager's attempts to mitigate restarts while still allowing Windows Installer to use Restart Manager to detect files in use by applications. As a result, this configuration may provide the benefits of Restart Manager-based detection without automatically shutting down or restarting applications.

As for whether the built-in FilesInUse path could be optimized or whether its cost could be formally documented, I was unable to find any public statement, documentation, or known issue that addresses this specific behavior.

Given your findings (7+ minutes with the built-in mechanism versus a few seconds with Restart Manager enabled), it would be valuable to test with MSIRESTARTMANAGERCONTROL="DisableShutdown" to determine whether it restores the faster detection path while avoiding automatic application shutdown/restart.

If you are able to test this configuration, please let me know the results. It would help determine whether this documented mode addresses your scenario. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Answer 2

Hi @Bhogaraju, Praneeth ,

We are currently working the issue and will provide an update soon. Thank you for your patience.