Share via

Windows 11 24/25H2 : When our application is reinstalled VCruntime140.dll, msvcp140.dll and some other dlls are not getting copied.

Gandla, Manjunath 20 Reputation points
2026-06-02T06:49:13.5166667+00:00

Hi All,

When our application is reinstalled VCruntime140.dll, msvcp140.dll and some other dlls are not getting copied under c:\windows\system32\ as expected.
our installer is using merge modules internally to copy these dlls.

when the application launches, checks for the server version and triggers an update if new version detected.

internally we uninstall the current version of the application and reinstall the new version of msi downloaded from the server
This issue is not observed in windows 11 22H2 for the same update flow.

Note: This issue does not occur when the application is clean installed. with out the mentioned above update path.

Require some help in understanding the root cause and possible workarounds from windows.

Windows development | Windows API - Win32

Answer accepted by question author

Taki Ly (WICLOUD CORPORATION) 2,225 Reputation points Microsoft External Staff Moderator
2026-06-02T09:29:03.4566667+00:00

Hello @Gandla, Manjunath ,

Thanks for reaching out and providing details of your update flow.

From my research, this issue is likely caused by how Windows Installer (MSI) handles file reference counting in modern Windows 11 builds during a rapid uninstall/reinstall cycle. When the old app is uninstalled, the OS marks the merge module DLLs in System32 for deletion. If your updated MSI starts its "File Costing" phase before the OS finishes physically deleting those files, the installer assumes the DLLs are already present and skips copying them. Once the delayed deletion completes, your app is left without its dependencies.

Additionally, Microsoft has officially deprecated the use of Merge Modules for Visual C++ components precisely because they cause these types of reference-counting issues.

So, I suggest these approaches below:

  1. App-Local Deployment: Stop installing the DLLs into System32. Instead, deploy VCruntime140.dll and msvcp140.dll directly into your application's installation folder (alongside your .exe). This isolates your app from OS-level changes and completely bypasses MSI reference counting bugs. See Redistributing Visual C++ Files for details.
  2. Use a Bootstrapper/Chainer: If a system-wide install is strictly required, remove the merge modules from your MSI package entirely. Instead, use a bootstrapper (like WiX Burn) to run the official vc_redist.x64.exe /quiet installer just before your main MSI runs.
  3. Temporary Workaround: If you must keep your current "uninstall -> install" flow, add a 5-10 second sleep delay in your client code between the uninstallation of the old version and the installation of the new one. This gives the OS time to finish purging the old files.

Hope these approaches help! If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Was this answer helpful?

2 people found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.