c:\Windows\system32\MSVCP140.dll keeps getting overwritten with old version post MS updates

Question

We have been observing a problem with the msvcp140.dll file in the c:\Windows\System32 folder getting overwritten with an outdated version usually following, but not necessarily, the monthly Win11 cumulative update patch. The file gets overwritten with version 14.13.26020, and this causes issues on our Windows11 VDI machines which have the Citrix Virtual Apps and Desktops 7 2507 LTSR VDA. The VDA 2507 requires a newer version of msvcp140.dll and the version that deploys with the VDA 2507 LTSR is 14.42.34438. When the file gets overwritten with the older version, our VDI machines become Unregistered, and our users cannot connect and initiate an ICA session to the VDI from the Citrix Storefront.

We have researched this issue with Citrix and found Article ID CTX695909 which provides steps to resolve the problem so that the VDI machine is able to register again, but this is only a band-aid and when the next patch cycle rolls around our VDI machines with VDA 2507 LTSR are once again susceptible to the file getting overwritten.   We have not been able to find a root cause for the event that overwrites the msvcp140.dll file.

Answer 1

Hi Duran, Peter,

How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VP

Answer 2

Hi Duran, Peter,

The recurring downgrade of your msvcp140.dll file is caused by a Windows Installer self-repair process triggered by a legacy application, rather than the Windows cumulative update itself. When a monthly update applies changes and reboots your VDI master image, a poorly authored third-party application on that image detects a perceived inconsistency with its own installation state. This triggers a silent background repair where the older application forcefully restores its bundled 2017 Visual C++ runtime, overwriting the newer file at c:\Windows\System32\msvcp140.dll that is required by your Citrix VDA.

To pinpoint the specific application causing this conflict, you need to inspect the Windows Event Viewer immediately after a cumulative update and reboot on a test machine. Filter the Application log for MsiInstaller events, specifically focusing on Event ID 1004 and Event ID 1001, which log whenever an application requests and executes a self-repair. Correlating the exact timestamps of these events with the modification time of the DLL file will reveal a specific Product Code or GUID initiating the downgrade.

You can identify the actual name of the software by taking that alphanumeric Product Code from the event log and searching for it within the Windows Registry. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products using the Registry Editor. Searching for the code within this key will reveal the ProductName string value, identifying the exact legacy application causing the headache. Once identified, you can resolve the issue permanently by updating that specific software to a modern version, removing it entirely, or repackaging its installer to exclude the outdated Visual C++ runtime components.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Answer 3

The behavior is consistent with older or conflicting Visual C++ Redistributables or applications dropping outdated C runtime DLLs back onto the system, rather than Windows Update itself being the root cause.

A more durable mitigation is to standardize and control the Visual C++ runtime environment across the VDI image and prevent older components from being reintroduced, instead of repeatedly repairing after each patch cycle. In particular:

1. Standardize on a single, current VC++ 2015–2022 Redistributable
   • Ensure that only the latest supported 2015–2022 x64 redistributable is installed on the base VDI image.
   • Remove older VC++ redistributable packages that may deploy the 14.13.26020 version of msvcp140.dll.
   • Rebuild or re-seal the VDI base image after this cleanup so all pooled/ephemeral VMs inherit the same consistent runtime.
2. Identify and control installers that deploy older runtimes
   • Review application installers used in the VDI image (including CAD, Adobe, rendering, or other line-of-business apps) for bundled VC++ runtimes.
   • Where possible, use installer options that skip installing bundled VC++ components, or update to versions of those applications that depend on the newer 2015–2022 redistributable.
   • Block or replace any legacy installer that drops msvcp140.dll 14.13.26020 into system locations.
3. Use configuration management to enforce the correct DLL version
   • Use deployment tools or scripts (for example, as part of post-patch maintenance) that verify the presence and version of the required VC++ 2015–2022 runtime and msvcp140.dll, and remediate only if a regression is detected.
   • This verification approach is more reliable than blind reinstallation and helps detect which event or installer is reintroducing the old DLL.
4. Align with Citrix VDA requirements
   • Since Citrix VDA 2507 LTSR requires a newer msvcp140.dll, ensure that the base image is built with the VDA-installed runtime as the authoritative version and that no subsequent application or script in the image customization pipeline overwrites it.
5. Rust transition has no direct impact
   • Any internal move by vendors toward Rust does not change current dependencies on the Visual C++ runtime. Existing CAD, Adobe, and rendering software will continue to rely on the correct VC++ redistributables until those vendors explicitly ship Rust-based components that no longer depend on msvcp140.dll.

By enforcing a single, current VC++ 2015–2022 redistributable across the environment, removing legacy redistributables, and controlling application installers that deploy outdated runtimes, the recurring overwrite of msvcp140.dll can be minimized and Citrix VDA registration stability improved.

---

References:

• MVC140.DLL Error after Windows OS Updates - Microsoft Q&A