Supported five-DLL VCLibs deployment contract for a PyInstaller/PySide6 desktop MSIX

Question

Supported five-DLL VCLibs deployment contract for a PyInstaller/PySide6 desktop MSIX

Prosanta Roy 0

Hello,

What is Microsoft's supported deployment contract for these five runtime DLLs in an x64, full-trust desktop MSIX containing two PyInstaller executables?

msvcp140.dll

msvcp140_1.dll

msvcp140_2.dll

vcruntime140.dll

vcruntime140_1.dll

Our proposed build inputs are CPython 3.12.10 AMD64, PyInstaller 6.22.2 and PySide6/Shiboken6 6.10.2. Main uses the windowed runw.exe bootloader; Helper uses console run.exe. Both have Python runtime hooks registering bundle, _internal/PySide6 and _internal/shiboken6 directories. Private MSVC runtime candidates exist, but final collection and provider selection are not established.

The framework under consideration is Microsoft.VCLibs.140.00.UWPDesktop, publisher CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US, family Microsoft.VCLibs.140.00.UWPDesktop_8wekyb3d8bbwe. Our preserved comparison package is 14.0.33321.0 x64; this PC currently has 14.0.33728.0 x64 and x86 registered. The application manifest currently has no VCLibs PackageDependency and declares Windows.Desktop minimum 10.0.19045.0.

Please clarify:

Dependency and minimum version: Is the UWPDesktop identity/publisher above the appropriate framework dependency for both executables? How should we determine its supported MinVersion from the compiler/toolset requirements of Python, Qt, bootloaders and native extensions? What authoritative mapping relates framework package versions to their contained runtime DLL versions and supported toolsets?

Framework versus private copies: For all five DLLs, what supported rules govern retaining, excluding or coexisting with privately collected copies? Does Desktop Bridge require framework-provided versions throughout this application, or are specific app-local configurations supported? We are not proposing removal or retention until that policy and early-startup requirements are established.

Both startup paths: Do the same rules cover Main and a separately launched Helper, including native dependency loading before Python hooks execute? What package-identity, helper-launch and package-graph conditions must hold?

Verification: Which supported Microsoft diagnostics should establish the actual loaded provider path, file identity/version and framework package identity for each executable, including early startup and transitive loads? How should we detect unintended private/system fallback and distinguish package-graph membership from actual loader binding?

We distinguish framework package version, individual DLL file version, compiler/toolset version and Windows minimum version. We do not assume that matching version suffixes, exports, signatures or DLL-directory registration order establishes compatibility.

Historical import matches concern binaries associated with an older 789-file source revision. They do not qualify our current frozen 791-file revision, whose executable artifacts are not yet authenticated. Actual packaged loader binding remains unverified.

We have consulted Microsoft's Desktop Bridge C++ runtime guidance, supported runtime guidance and DLL search-order documentation. Please identify the applicable supported configuration and any additional authoritative references.

Qt ICU deployment closure and target-Windows API-set/export/forwarder closure remain separate unresolved issues; a VCLibs answer will not be treated as resolving them.

Thank you.Hello,

What is Microsoft's supported deployment contract for these five runtime DLLs in an x64, full-trust desktop MSIX containing two PyInstaller executables?

msvcp140.dll

msvcp140_1.dll

msvcp140_2.dll

vcruntime140.dll

vcruntime140_1.dll

Our proposed build inputs are CPython 3.12.10 AMD64, PyInstaller 6.22.2 and PySide6/Shiboken6 6.10.2. Main uses the windowed runw.exe bootloader; Helper uses console run.exe. Both have Python runtime hooks registering bundle, _internal/PySide6 and _internal/shiboken6 directories. Private MSVC runtime candidates exist, but final collection and provider selection are not established.

The framework under consideration is Microsoft.VCLibs.140.00.UWPDesktop, publisher CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US, family Microsoft.VCLibs.140.00.UWPDesktop_8wekyb3d8bbwe. Our preserved comparison package is 14.0.33321.0 x64; this PC currently has 14.0.33728.0 x64 and x86 registered. The application manifest currently has no VCLibs PackageDependency and declares Windows.Desktop minimum 10.0.19045.0.

Please clarify:

Dependency and minimum version: Is the UWPDesktop identity/publisher above the appropriate framework dependency for both executables? How should we determine its supported MinVersion from the compiler/toolset requirements of Python, Qt, bootloaders and native extensions? What authoritative mapping relates framework package versions to their contained runtime DLL versions and supported toolsets?

Framework versus private copies: For all five DLLs, what supported rules govern retaining, excluding or coexisting with privately collected copies? Does Desktop Bridge require framework-provided versions throughout this application, or are specific app-local configurations supported? We are not proposing removal or retention until that policy and early-startup requirements are established.

Both startup paths: Do the same rules cover Main and a separately launched Helper, including native dependency loading before Python hooks execute? What package-identity, helper-launch and package-graph conditions must hold?

Verification: Which supported Microsoft diagnostics should establish the actual loaded provider path, file identity/version and framework package identity for each executable, including early startup and transitive loads? How should we detect unintended private/system fallback and distinguish package-graph membership from actual loader binding?

We distinguish framework package version, individual DLL file version, compiler/toolset version and Windows minimum version. We do not assume that matching version suffixes, exports, signatures or DLL-directory registration order establishes compatibility.

Historical import matches concern binaries associated with an older 789-file source revision. They do not qualify our current frozen 791-file revision, whose executable artifacts are not yet authenticated. Actual packaged loader binding remains unverified.

We have consulted Microsoft's Desktop Bridge C++ runtime guidance, supported runtime guidance and DLL search-order documentation. Please identify the applicable supported configuration and any additional authoritative references.

Qt ICU deployment closure and target-Windows API-set/export/forwarder closure remain separate unresolved issues; a VCLibs answer will not be treated as resolving them.

Thank you.

Prosanta Roy 0 Reputation points

2026-10-31T16:59:51.5766667+00:00

Thank you for the guidance on using FrameworkIdentity-Retail. Since the existing response is AI-generated, could Microsoft clarify the supported acquisition and authentication route for this specific file?

%ProgramFiles(x86)%\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\SDKManifest.xml

Which exact supported Visual Studio Build Tools component ID, installer package or workload component supplies it? Is Microsoft.VisualStudio.ComponentGroup.UWP.VC.BuildTools sufficient, or is another component required?

Is there a supported way to obtain or inspect this manifest without installing the full Visual Studio IDE?

Which official signature, catalog or installer evidence authenticates the manifest and links its FrameworkIdentity-Retail values to the supplied Microsoft.VCLibs.140.00.UWPDesktop framework package?

This follow-up concerns acquisition and provenance only; it does not assume that any particular SDK, toolset or MinVersion is suitable for our application.

2 answers

Your answer

Prosanta Roy 0 Reputation points

2026-10-31T16:59:51.5766667+00:00

Thank you for the guidance on using FrameworkIdentity-Retail. Since the existing response is AI-generated, could Microsoft clarify the supported acquisition and authentication route for this specific file?

%ProgramFiles(x86)%\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\SDKManifest.xml

Which exact supported Visual Studio Build Tools component ID, installer package or workload component supplies it? Is Microsoft.VisualStudio.ComponentGroup.UWP.VC.BuildTools sufficient, or is another component required?

Is there a supported way to obtain or inspect this manifest without installing the full Visual Studio IDE?

Which official signature, catalog or installer evidence authenticates the manifest and links its FrameworkIdentity-Retail values to the supplied Microsoft.VCLibs.140.00.UWPDesktop framework package?

This follow-up concerns acquisition and provenance only; it does not assume that any particular SDK, toolset or MinVersion is suitable for our application.

Answer 1

Harry Nguyen (WICLOUD CORPORATION) 525 Microsoft External Staff Moderator

Hi @Prosanta Roy ,

Sorry for the delayed response, and thank you for taking the time to provide such a detailed follow-up. I've reviewed the additional questions you raised.

For the original Win32/Desktop Bridge question, Microsoft documents Microsoft.VCLibs.140.00.UWPDesktop as the v14 Desktop C++ Runtime framework dependency, rather than relying on runtime DLLs copied from Visual Studio or the Visual C++ Redistributable. The VCLibs Desktop Extension SDK is installed under:

%ProgramFiles(x86)%\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

You can find more details in the C++ Runtime framework packages for Desktop Bridge documentation.

Regarding Microsoft.VisualStudio.ComponentGroup.UWP.VC.BuildTools, it is documented as C++ Universal Windows Platform tools (Latest MSVC). However, the Build Tools component documentation does not explicitly establish that this component owns the specific SDKManifest.xml file you mentioned, so I wouldn't want to give you an unsupported Yes/No answer here.

I think the remaining questions around the exact Visual Studio Installer component/package that owns SDKManifest.xml, standalone acquisition without the Visual Studio IDE, and installer/catalog provenance would fit better in a separate Visual Studio setup discussion.

You can create a new question about Visual Studio Installer/Build Tools component ownership and SDKManifest.xml provenance on Microsoft Q&A, and my team can help you further there.

If you found this helpful, you can refer to this guidance to confirm it and help others with similar questions.

Thank you.

Prosanta Roy 0 Reputation points

2026-11-02T04:24:25.2033333+00:00
Thank you for considering this clarification.

Microsoft’s binary-compatibility documentation states that the VC++ Redistributable must be at least as new as the latest build tools used by any application component. How should this requirement be translated into the supported MinVersion for the Microsoft.VCLibs.140.00.UWPDesktop MSIX framework dependency?

The related Developer Community report was Under Consideration, with no engineering resolution, when reviewed. We are not treating its community-reported compiler/runtime version mappings as verified.

Could Microsoft clarify:

Given authenticated build-toolset provenance for each native component, what supported mapping or procedure determines the framework package MinVersion, distinguishing it from compiler and individual runtime DLL versions?

Does that procedure cover both our packaged Main executable and Helper executable, and what Helper launch/package-context conditions must be verified?

Which official documentation or Microsoft engineering guidance establishes this relationship?

This follow-up concerns version determination only. Our existing questions about actual loader binding and private-versus-framework deployment of the five runtime DLL families remain open.
Harry Nguyen (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff Moderator

2026-11-02T07:07:27.1933333+00:00
Hi @Prosanta Roy

Thank you for the follow-up. I went back through the relevant documentation in full for this part.

MinVersion and build-toolset versions

Microsoft does document a procedure for obtaining the MinVersion value. Prepare to package a desktop application (section "Your app uses a VCLibs framework package") says to:

Go to the framework package folder for the version of the Visual C++ Runtime your app uses (for v14: C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0).)

Open SDKManifest.xml, locate FrameworkIdentity-Retail (or FrameworkIdentity-Debug), and copy the Name and MinVersion values.

Use those values in the PackageDependency element of your package manifest.

For reference, on my test machine, SDKManifest.xml in that folder declares FrameworkIdentity-Retail with MinVersion = 14.0.33728.0.

The procedure selects the framework package by Visual C++ Runtime version (11.0, 12.0 or 14.0). However, in the documentation I reviewed, I couldn't find a mapping from specific MSVC build-toolset versions to framework package versions. In particular, nothing explicitly translates the Redistributable rule into a VCLibs MinVersion:

The requirement that the runtime be at least as new as the build tools is documented for the Visual C++ Redistributable. The Lifecycle FAQ says each Redistributable release is compatible with programs built using MSVC Build Tools v14.00 and later, provided the Redistributable version is equal to or higher than the version of the build tools used to build the application. Its version tables map MSVC releases to Redistributable/runtime versions and don't include the VCLibs framework package. (Lifecycle FAQ, C++ binary compatibility 2015-2026)

In the manifest schema, MinVersion is defined as the minimum version of the dependency package, and the version of the dependency package must be greater than or equal to it. (PackageDependency)

Main and Helper

The dependency is declared at the package level, not per executable. The documentation explains that every process has a package graph listing the packages available to it, and that packaged apps add static framework dependencies through the PackageDependency element in the manifest. (MSIX framework packages and dynamic dependencies) Package identity applies to processes, not only to applications, so I'd recommend confirming it separately for Main and Helper when they're launched through their production paths, for example with GetCurrentPackageFullName. (Detect package identity and runtime context) I couldn't find official documentation listing the required helper-launch conditions, so I'd treat this as something to verify rather than assume.

For an authoritative statement on how VCLibs framework package versions relate to specific MSVC toolset and Redistributable versions, you may want to upvote and add your details to the existing report you mentioned on the C++ Developer Community. You could also submit feedback directly on the documentation pages above using the feedback option at the bottom of each page.

If you found this helpful, you can refer to this guidance to confirm it and help others with similar questions.

Thank you.
Prosanta Roy 0 Reputation points

2026-11-02T16:38:39.6433333+00:00
Thank you, Harry, for the November 2 clarification and for distinguishing the documented SDKManifest procedure from the unresolved compatibility mapping.

Could Microsoft clarify these three remaining questions?

What supported method establishes a sufficient Microsoft.VCLibs.140.00.UWPDesktop framework version for an x64 Desktop Bridge application containing native components built with potentially different, authenticated MSVC toolsets? We understand how to read FrameworkIdentity-Retail; the unresolved step is determining whether that framework version satisfies all native consumers.

When a packaged full-trust Main executable launches an adjacent PyInstaller Print Helper through subprocess.run, what documented conditions establish the Helper’s package identity and framework dependency availability before native startup? What supported diagnostics establish actual DLL provider binding, separately from package-graph availability?

What supported deployment policy governs msvcp140.dll, msvcp140_1.dll, msvcp140_2.dll, vcruntime140.dll and vcruntime140_1.dll in this configuration—particularly retaining, excluding or coexisting with private copies, including pre-Python imports and explicit-path loading?

The exact Visual Studio Installer component supplying the Desktop SDKManifest.xml also remains unresolved; we will address that through a separate Visual Studio Setup question.

We have not established a supported MinVersion or runtime compatibility. Official documentation or clarification from the responsible Microsoft engineering team would help resolve these points.
Harry Nguyen (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff Moderator

2026-11-03T03:18:56.8766667+00:00
Hi @Prosanta Roy ,

Thank you for narrowing down the remaining questions. I reviewed the Microsoft documentation further, particularly around VCLibs compatibility, package context, DLL loading, and runtime deployment.

1. Determining a sufficient VCLibs framework version

Microsoft documents how to obtain MinVersion from FrameworkIdentity-Retail in the selected VCLibs Extension SDK's SDKManifest.xml. The PackageDependency schema defines MinVersion as the minimum version of the dependency package. (Prepare to package a desktop application, PackageDependency)

Separately, the C++ compatibility documentation defines compatibility requirements between MSVC build tools and the Visual C++ Redistributable. (C++ binary compatibility 2015-2026, Microsoft C++ Build Tools, Redistributable, and runtime libraries FAQ)

However, those documents do not provide an equivalent mapping from the authenticated MSVC toolsets of multiple native components to a specific Microsoft.VCLibs.140.00.UWPDesktop framework version.

Therefore, the documented SDKManifest.xml procedure provides the MinVersion to declare for the selected VCLibs framework package, but the reviewed documentation does not establish that this value alone proves runtime compatibility for every native consumer built with potentially different toolsets. I would avoid extending the Redistributable compatibility rule to VCLibs framework versions without an explicitly documented relationship.

2. Helper package context and actual DLL binding

For the Helper, I would verify its runtime context directly rather than infer it from the Main process.

GetCurrentPackageFullName can verify the Helper's package identity.

GetCurrentPackageInfo, together with the documented PACKAGE_FILTER_* constants, can retrieve package information from the dependency graph for the calling Helper process.

ListDLLs can inspect the DLLs actually loaded by the running Helper and provide version/signature information.

These are separate checks. Package-graph availability does not by itself establish which physical DLL provider was ultimately loaded.

The Dynamic-link library search order documentation shows that resolution can also depend on the package dependency graph, modules already loaded, Known DLLs, explicit paths, and APIs that modify DLL search behavior.

The process creation documentation describes child-process creation and related inheritance behavior, but it does not establish subprocess.run() itself as a guarantee of package identity or VCLibs framework availability. For that reason, verifying the Helper directly is the safer approach.

3. Deployment of the five runtime DLLs

For Desktop Bridge applications that depend on the C++ Runtime, Microsoft documents the corresponding VCLibs framework package as the deployment mechanism rather than simply redistributing the Visual Studio/VCRedist runtime libraries. (C++ Runtime packages for Desktop Bridge)

Microsoft also documents application-local deployment of C++ runtime files and the Windows DLL resolution rules.

Those documents explain the deployment and loader mechanics, but they do not define a PyInstaller-specific support policy covering all the cases you listed, such as pre-Python imports, retaining or excluding private copies of these five DLLs, explicit-path loading, or mixed private/framework providers.

Because of that distinction, I would not derive a blanket rule from the loader documentation that all private copies must always be removed, or conversely that every private-copy/coexistence configuration is supported.

Based on the published documentation, the package-context and runtime-binding checks above can be verified directly. The remaining toolset-to-VCLibs compatibility mapping and PyInstaller-specific deployment policy go beyond what the current documentation establishes. If you need an authoritative supportability determination for these two points, you may consider contacting Windows Developer Support for a more detailed review of your specific configuration.

I hope this helps clarify both the documented behavior and the boundaries of what can be concluded from it.

If you found this helpful, you can refer to this guidance to confirm it and help others with similar questions.

Thank you.
Harry Nguyen (WICLOUD CORPORATION) 525 Reputation points Microsoft External Staff Moderator

2026-11-05T03:22:42.81+00:00

Hi @Prosanta Roy ,

I’ve provided an update on your questions. Whenever you have a moment, please take a look and let me know if you’d like any further help.

Thank you.

Answer 2

Declare Microsoft.VCLibs.140.00.UWPDesktop as a required x64 framework dependency, source its exact MinVersion from the selected VCLibs Extension SDK’s SDKManifest.xml, and exclude the five private runtime DLLs from the final PyInstaller payload unless Microsoft confirms a separate app-local deployment design for this packaged scenario.

Supported package configuration

For a Desktop Bridge application dependent on the dynamic VC++ runtime, Microsoft’s documented contract is to reference the corresponding Desktop C++ Runtime framework package rather than merely redistribute the Visual Studio/VCRedist DLLs. The documented v14 identity and publisher match those in the question.^1^

Add this under the existing manifest <Dependencies> element:

<PackageDependency
    Name="Microsoft.VCLibs.140.00.UWPDesktop"
    Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
    MinVersion="REPLACE_FROM_SDKMANIFEST" />

MinVersion is the minimum framework package version, not the Windows minimum version, DLL file version, or compiler version. At deployment, Windows requires a dependency package whose version is equal to or greater than that value.^2^

Determine the value as follows:

Establish the MSVC toolset used to build every native input in the frozen 791-file revision:
- CPython and its native modules;
- PyInstaller run.exe and runw.exe;
- Qt/PySide6 and Shiboken6 binaries;
- every additional .pyd and native DLL.
Install/select the matching supported VCLibs Desktop Extension SDK.
Open its SDKManifest.xml.
Copy the Name, Publisher, and MinVersion from FrameworkIdentity-Retail into AppxManifest.xml. This is Microsoft’s documented procedure; the example values such as 14.0.24217.0 or 14.0.27323.0 are examples, not a basis for selecting the current package’s minimum.^3^
Build and test against that minimum and newer compatible framework versions.

The general VC runtime rule is that the deployed v14 runtime must be the same version as or newer than the newest MSVC toolset used to build any loaded component. Visual Studio 2015–2026 use the compatible v14 family, but an older runtime is unsupported for a component built with a newer toolset.^4^

The cited documentation does not provide a universal table mapping every Microsoft.VCLibs.140.00.UWPDesktop package version to each contained DLL file version and every supported MSVC toolset. Therefore, neither 14.0.33321.0 nor the installed 14.0.33728.0 can be selected solely from its numeric similarity to a toolset or DLL. Inspect the actual Extension SDK package and SDKManifest.xml; obtain build-toolset provenance from each binary supplier where it is not recorded.

Framework versus private DLLs

For this Desktop Bridge configuration, remove these private candidates from the final package after confirming the framework contains the complete imported set:

msvcp140.dll
msvcp140_1.dll
msvcp140_2.dll
vcruntime140.dll
vcruntime140_1.dll

Do not intentionally mix private and framework copies under the assumption that the framework will win. For packaged desktop processes, name-based lookup checks the process package graph before the executable directory, but loaded-module reuse, Known DLLs, explicit paths, SxS redirection, and altered search modes can change the observed binding.^5^

Microsoft’s general redistribution guidance permits local deployment in ordinary VC++ deployment scenarios, while discouraging it because the application becomes responsible for servicing.^4^ However, the more specific Desktop Bridge guidance says applications in that container must specify the Desktop framework and must not simply use Visual Studio/VCRedist runtime copies.^1^ That case-specific rule should govern this MSIX.

Main and Helper processes

The manifest dependency is package-level, not executable-specific. A packaged process receives a graph containing its main package and manifest-declared framework dependencies at process creation.^6^ This makes the runtime available before Python starts, so runtime hooks and AddDllDirectory calls are neither required nor early enough to establish the bootloader’s statically imported VC runtime.

Apply the same validation independently to Main and Helper:

Launch each through its intended production path.
Confirm that each process has package identity. In Task Manager, enable Details → Select columns → Package name, or call GetCurrentPackageFullName; ERROR_INSUFFICIENT_BUFFER indicates identity and APPMODEL_ERROR_NO_PACKAGE indicates none.^7^
Query each process’s graph with GetCurrentPackageInfo, requesting the applicable static framework entries, and verify the resolved x64 Microsoft.VCLibs.140.00.UWPDesktop full name/version.^8^
If Helper reports no package identity or its graph lacks VCLibs, its actual launch arrangement has not produced the required packaged runtime context. A successful historical direct launch does not establish that contract.

The available documentation does not state that every arbitrary helper-launch mechanism necessarily preserves the parent’s identity or graph. Validate the exact packaged activation/launch route rather than inferring inheritance from the parent process.

Binding verification

Use separate evidence for graph membership and loader binding:

Graph: GetCurrentPackageInfo establishes which packages are available to that process; it does not prove which DLL won lookup.
Loaded provider: Run listdlls -v <PID> for each process. ListDLLs reports loaded DLL paths and full version information; use -u as an additional unsigned-module check.^9^
Live/short-lived loads: Capture Process Monitor events filtered to Main/Helper process names and the five DLL names. Process Monitor records process, file-system, and DLL activity in real time.^10^
Earliest loader decisions: Before launching either executable, enable per-image loader snaps:

gflags /i Main.exe +sls
gflags /i Helper.exe +sls

Attach/capture with the Windows debugger. Loader snaps record DLL loading and unloading for each configured image, including failures occurring before Python initialization.^11^

After testing, remove the diagnostic setting:

gflags /i Main.exe -sls
gflags /i Helper.exe -sls

For every one of the five names, record: importing module, attempted paths, selected full path, file version/signature, process package identity, and resolved framework package full name. A path under the resolved VCLibs framework package demonstrates framework binding; an application-directory or _internal path demonstrates private binding; a System32 path demonstrates system fallback. Repeat on a clean x64 VM with only the declared dependency installed, rather than relying on the development machine’s existing x86/x64 registrations.

References