Visual C++ runtime DLLs installed in the Python directory force native code to use an older runtime

[mfoco]

Official CPython Windows packages install vcruntime140.dll and vcruntime140_1.dll in the same directory as python.exe. Windows loads these directory-local DLLs when Python starts. When native code is later loaded into the same process, Windows reuses the runtime modules already loaded from the Python directory.

Native code loaded into Python is therefore forced to use the older runtime installed in the Python directory instead of the newer Microsoft v14 runtime installed system-wide. In our case, the extension uses ctypes to load its native DLL. That DLL was built and tested with the newer runtime and crashes when the process is bound to the older copy from the Python directory.

For example, Python 3.14.6 bundles 14.42.34438.0, while the current Microsoft x64 v14 Redistributable measured on 21 July 2026 is 14.51.36247.0.

All Python 3.10–3.14 releases with official Windows x64 binaries were inspected.

Microsoft states that the installed Visual C++ runtime must be the same version as or newer than the MSVC build tools used to build the application. The current v14 Redistributable is binary compatible with applications built using the Visual Studio 2017–2026 v14 toolsets.

The older runtime DLLs installed in the Python directory defeat that compatibility model for native code loaded into the Python process because Windows reuses them instead of loading the newer system-wide runtime.

We propose to stop adding a local Visual C++ runtime to the Python installation directory. For normal installed runtimes, use the Microsoft v14 Redistributable as a centrally installed prerequisite and omit App-local vcruntime140*.dll files. The system-installed runtime is usually maintained up-to-date from Windows Update, and thus have more chances to be updated to the latest version (with latest security patches too).

As a sidenote, during this analysis we also realized that some patch version include a version of runtime that is older than those provided with the previous versions, which is another problem (e.g. 3.10.9 had VC runtime version 14.34.31931.0, while 3.10.10 and 3.10.11 had version 14.29.30139.0, and a similar issue happened more recently with version 3.11.5 and 3.11.6). This highlights the importance of this issue.

CPython versions tested on:

3.10

Operating systems tested on:

Windows

[picnixz]

cc @zooba

[mfoco]

I removed the "bug" in the description text too.

The reason why I initially reported as bug is that it can make a clean C++ library with C interface (like ours) crash, while testing the same functions tested with a different executable won't crash.

We also tested the proposed solution by removing vcruntime140*.dll from Python directory: that solves the crash (by using the system-installed vc runtime).

[zooba]

Yes, there was an issue back then. Newer versions shouldn't suffer from this anymore, though they likely are on an older version now - I'll go put the latest one into our redist copy.

The issue was discovered with a known backwards-incompatibility in the C++ side of things. The best I can suggest is for you to statically link libvcruntime.lib into your code, and our next round of binary releases will have the later version. Nothing we can do for the versions that no longer get releases, I'm afraid, but as you've noted the libraries are perfectly compatible with each other - there's just that one version of vcruntime that's incompatible with newer msvcp140/libcp.

[zooba]

Our next releases should have 14.51.36247 of the redist files.

[mfoco]

@zooba I would prefer not to have to hope that mistakes won't happen again, and past experience shows that the status quo is brittle.

For this, and for security reason, Microsoft itself discourages local deployment and is more in favor of using of redistributable packages. These are the passages I've found where this suggestion is done:

In Deployment in Microsoft C++ they say For continued security and functionality, we recommend that you [...] use Redistributable packages and central deployment instead of local deployment.

In Choosing a deployment method they say Local deployment. Local deployment isn't recommended in most situations. and Because Microsoft can't automatically update locally deployed Microsoft C++ libraries, we don't recommend local deployment of these libraries. If you decide to use local deployment of the Redistributable libraries, we recommend that you implement your own method of automatically updating the locally deployed libraries. (no automatic mechanism for updating VCRUNTIME is currently provided in Python)

In Redistribute Visual C++ Files they say It's also possible to directly install the Redistributable DLLs in the application local folder. [...] For servicing reasons, we don't recommend that you use this installation location.

I'll try to find out a compelling realistic example - our crash would've been a good candidate, but it was too complex to reduce in a simple example.

[zooba]

I'm familiar with the guidance, and we can't feasibly rely on it. If you're willing to use an alternative deployment method besides our installer to put vcruntime140.dll on a system (ours can't, since we don't require admin) then you can delete the vcruntime140.dll from any Python install. We can't statically link it because there is shared state that breaks for extension modules if we do that.

Our previous method of using the same runtime that was used to build is what led to the downgrade issue. At that point, we moved to a stable pin on redistributables (by committing them to one of our repositories that we use for such things), but it does still require manual updating. We failed to do that, but it also wouldn't have helped because we don't release binary updates for old versions.

I'm afraid if you have such strict requirements around your Python install, you may need to distribute the runtime yourself as part of whatever application you're releasing. It's very easy to redistribute Python (check out the embeddable package), and you can omit vcruntime140.dll entirely if you've ensured that it's otherwise available. But we cannot ensure that, so we don't.