MSI卸载时文件/组件移除机制及留存场景技术问询

Great question—this is one of those MSI behaviors that's surprisingly under-documented compared to install/upgrade flows, so I'm glad you're digging into the details. Let's break this down clearly:

Scenarios Where Files/Components Persist After Uninstall (Beyond permanent & SharedDLLRefCount) #

Outside the explicit permanent component attribute and the classic SharedDLL reference count, here are the most common cases where files stick around post-uninstall:

• Component reference count > 1: MSI tracks component-level reference counts independent of SharedDLL. If multiple MSI packages share the same component GUID (a valid practice for shared components), uninstalling one package won't drop the count to 0—so the file stays until the last referencing package is removed.
• Post-install file modifications: If a file was edited, replaced, or modified by the user or another program after installation, MSI will retain it by default. This is a safeguard to avoid overwriting user changes; the installer checks the file's hash against the original installed version, and skips deletion if they don't match.
• Locked files/pending operations: If the file is in use by a running process during uninstall, Windows Installer can't delete it immediately. It queues the deletion for the next system reboot—so the file will persist until the user restarts their machine.
• Custom uninstall logic: Some packages include custom actions that explicitly prevent certain files from being deleted. This is a package-specific customization, but it's a common reason for unexpected retention.
• User-added files in component directories: MSI only removes files it originally installed. Any new files added manually to the component's target folder after setup will be left behind.

Hotpatched DLLs: Safe to Remove During Uninstall? #

Your test result is correct—this is absolutely a reliable, expected behavior of Windows Installer.

When you apply a hotfix (MSP) that upgrades a DLL to a higher version, the installer still associates that updated file with the original component's GUID. MSI's component tracking is tied to the GUID, not the file version. As long as the component's reference count has dropped to 0 (no other packages depend on it) and it's not marked as permanent, the uninstall process will safely remove the higher-version DLL.

The key point here is that hotfixes don't alter the component's core identity—they just update the files within it. Windows Installer maintains a full history of the component's installation and updates, so it knows to remove the current (patched) version when the parent product is uninstalled.

Just note: This assumes the hotfix follows standard Windows Installer patch conventions. If the patch explicitly modified component attributes (like marking it permanent) or altered reference counting logic, that could change things—but those are edge cases, not the default behavior.

内容的提问来源于stack exchange，提问作者BudBrot