On 26H2 concrt140_app.dll hardlinked to systemApps during DISM commit, breaking apps

Nicklas Sørensen 0 Reputation points
2026-10-09T07:24:24.2933333+00:00

For years, we have been using DISM to enable .NET 3.5 in our Windows images by exporting Windows Pro, mounting it, enabling the feature, then committing it.

Since Windows 11 25H2 ISO released in July, and in all newer releases including 26H2, using any DISM version to commit any changes, however trivial, breaks the image by hardlinking the identical files:
'C:\Windows\SystemApps\MicrosoftWindows.Client.AIX_cw5n1h2txyewy\concrt140_app.dll'
'C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe\concrt140_app.dll'.

This means that the ACL from SystemApps take precedence and results in Microsoft.VCLibs.140.00 stopping in a paused state because access is denied, preventing all its dependent apps (MS Store, Calculator, etc.) from being provisioned.

This does not happen without the DISM commit. Does anyone know what is going on?

Windows for business | Windows Client for IT Pros | Devices and deployment | Install Windows updates, features, or roles
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Chen Tran 13,435 Reputation points Independent Advisor
    2026-10-10T00:44:03.8866667+00:00

    Hello Nicklas,

    Thank you for posting question on Microsoft Windows Forum!

    Based on the issue description. Well! The plausible explanation to the cause of this behavior lies in changes made to DISM’s internal Single Instance Storage (SIS) and hardlinking optimization routines during the /Commit-Wim (and /Optimize-Image) process. When DISM finalizes and commits an image mount, its deduplication engine scans for identical binaries to save disk space by converting them into hardlinks and in recent 25H2/26H2 releases, the concrt140_app.dll binary present in the new Windows AI client component (C:\Windows\SystemApps\MicrosoftWindows.Client.AIX_cw5n1h2txyewy) happens to be byte-for-byte identical to the one in the runtime dependency package (C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe). DISM aggressively hardlinks them together.

    Since a hardlink shares a single underlying file inode, metadata, and security descriptor, the strict, locked-down access control lists (ACLs) governed by SystemApps take precedence over WindowsApps. When AppXSVC attempts to provision or initialize dependent UWP/Desktop Bridge apps (such as the Microsoft Store, Calculator, and Notepad), it gets an Access Denied error on Microsoft.VCLibs.140.00, leaving the package stuck in a paused or failed state.

    The suggested workaround is to break the Hardlink via SetupComplete.cmd. Since you must commit the image to enable .NET 3.5, you can neutralize the hardlink during the final phase of setup before the user logs on by replacing it with a standalone copy and resetting permissions.

    Another suggestion is to avoid WIM commits by using audit mode provisioning. Instead of mounting and committing install.wim offline to enable features. In your testing machine, try to deploy the clean, unmodified install.wim directly to your reference machine. Boot into Audit Mode. Enable .NET 3.5 online via DISM or PowerShell. Since this is performed online rather than via an offline WIM commit, DISM handles package state bindings correctly without cross-linking SystemApps and WindowsApps ACL domains. Then capture the reference image using Sysprep.

    You can consult the following articles for further reference.

    I hope you have found something useful here. If it helps you get more insight into the issue, it is appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-10-09T07:25:55.6733333+00:00

    For Windows 11 26H2, stop enabling .NET Framework 3.5 in the offline WIM and install the standalone .NET 3.5 package after Windows starts; Microsoft states that 26H1 and later no longer include .NET 3.5 as a Windows optional component and do not support managing it in offline images with DISM.^1^

    1. Leave the 26H2 install.wim unmodified for .NET 3.5.
    2. Deploy Windows normally.
    3. During the task sequence, provisioning package, or post-install management phase, run the supported .NET Framework 3.5 standalone installer.
    4. For unattended installation, invoke that installer with /q or /quiet.
    5. Reinstall .NET 3.5 after an upgrade to a newer Windows release; Microsoft says it is not persisted across an OS-version upgrade.^1^

    Do not substitute the older DISM /Enable-Feature /FeatureName:NetFx3 process on 26H2. That process remains documented for releases where NetFx3 is a Feature on Demand, but it is not applicable to 26H1 or later.^2^

    For 25H2 and earlier, offline NetFx3 servicing is still supported. Use matching installation/FoD media; mixing source and target versions can leave the installation unsupported and unserviceable.^2^

    Hard-link creation itself is a documented AppX image-optimization behavior. DISM's provisioned-package optimization replaces identical files with hard links to reduce image size.^3^ WIM metadata can also preserve file indexes so files with matching indexes are recreated as hard links when the image is applied.^4^

    However, the current 26H2 release-health page does not list the specific concrt140_app.dll cross-link/ACL failure as a known issue.^5^ The available documentation therefore supports these narrower conclusions:

    • The hard link is compatible with documented AppX/WIM optimization behavior.
    • It does not establish that the SystemApps ACL is intentionally valid for the VCLibs package.
    • No documented fix, KIR, or supported command is currently identified for this exact cross-package ACL outcome.
    • Manually deleting the link, copying the DLL, changing ownership, or rewriting ACLs would alter protected AppX package content and should not be used as an image-production workaround.

    Also check the servicing pipeline for an explicit or implicit call to either of these operations and remove it for an isolation test:

    Optimize-AppXProvisionedPackages -Path 'C:\Mount'

    DISM /Image:C:\Mount /Optimize-ProvisionedAppxPackages

    Those commands are specifically documented to replace identical provisioned-package files with hard links.^6^ This is a diagnostic branch, not a confirmed explanation for an ordinary /Commit-Image: Microsoft documents commit as applying mounted-image changes, but does not document that every commit invokes AppX optimization.^7^

    Escalate the 25H2 commit regression

    Because the issue reproduces from pristine media after any commit and does not occur when the image is applied without committing, report it through Microsoft support as an offline-servicing/AppX packaging regression. Include:

    • Exact source ISO filename, edition, language, image index, and build.
    • Technician OS, Windows ADK, WinPE add-on, and DISM.exe versions.
    • The smallest reproduction: export → mount → trivial change → commit/unmount → apply.
    • %WINDIR%\Logs\DISM\dism.log from the technician system.
    • Windows\Logs\CBS\CBS.log from the mounted/applied image.
    • Before-and-after hashes, file IDs, hard-link counts, owners, and ACLs for both paths.
    • DISM /Image:<mount> /Get-ProvisionedAppxPackages output.
    • A control image exported and applied without mounting/committing.

    /CheckIntegrity may be added to the commit to detect WIM corruption, but it is not a repair for incorrect hard-link or ACL metadata.^7^

    References

    1. .NET Framework 3.5 on Windows 11 FAQ
    2. Deploy .NET Framework 3.5 by using Deployment Image Servicing and Management (DISM)
    3. DISM App Package (.appx or .appxbundle) Servicing Command-Line Options
    4. WIM_MSG_FILEINFO
    5. Windows 11, version 26H2 known issues and notifications
    6. Optimize-AppXProvisionedPackages-Description
    7. DISM Image Management Command-Line Options
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.