WSL2 install stuck at 14% / VirtualMachinePlatform cannot be enabled

Question

System:

• Windows 11 Pro, Version 25H2, OS Build 26200.7840
• Hardware: Virtualization enabled in BIOS (confirmed via Get-ComputerInfo)
• Location: Iraq (relevant — see root cause below)

---

Initial Symptom: Running wsl --install hangs at 14% indefinitely. The command is attempting to enable the VirtualMachinePlatform optional feature via DISM, which never completes.

---

What was tried (in order):

1. Checked CBS.log — found repeated WULib DownloadProgress: [0/100] and [50/100] entries, indicating a Windows Update download loop.
2. Reset Windows Update components (stopped services, renamed SoftwareDistribution and catroot2). No improvement.
3. Ran dism /online /enable-feature /featurename:VirtualMachinePlatform /all /limitaccess — failed with error 0x800f0912 (source files not found).
4. Downloaded Windows 11 25H2 ISO, mounted it, attempted DISM with /source:F:\sources\install.wim:6 /limitaccess. Command hung indefinitely — DISM ignored the local source entirely.
5. Monitored CBS.log during hang — still showed WU download loop, confirming /limitaccess was being ignored.
6. Booted into WinRE, copied install.wim to D:\WinSource, attempted offline DISM enable. Failed with 0x800f0912 — VirtualMachinePlatform FOD payload is not included in the standard install.wim (confirmed: it's a separate Features on Demand package not shipped in the ISO).
7. Attempted in-place upgrade via setup.exe — failed at 20% with error 0x8007042B - 0x2000D (MIGRATE_DATA failure during SAFE_OS phase).
8. Tried enabling via optionalfeatures.exe GUI — downloaded to 50% then stalled every time.
9. Confirmed all Windows Update services were running, no WSUS configured, no proxy set in WinHTTP, hosts file clean.
10. Ran sfc /scannow — no integrity violations.
11. Ran dism /online /cleanup-image /scanhealth — returned "The component store is repairable" (corruption confirmed).

---

Root Cause Identified: Using PowerShell to inspect the SSL certificate being served by https://download.windowsupdate.com, the certificate returned was:

Subject: CN=*.cqloud.com
Issuer: CN=global.qwilt.com

This is NOT a Microsoft certificate. Qwilt is a transparent CDN caching system deployed by ISPs. My ISP (in Iraq) is intercepting all Windows Update HTTPS traffic and serving it through their own CDN, presenting a certificate that Windows does not trust for Windows Update connections. This causes the SSL/TLS handshake to fail silently, manifesting as an infinite hang rather than an explicit error.

This explains every single failure throughout the troubleshooting process — every DISM hang, every 50% stall, every 0x8024002e error. The feature payload was never actually downloading; Windows was just waiting on a broken TLS connection.

---

Further Investigation (on hotspot):

Switched to a mobile hotspot (different ISP, no transparent proxy) and ran:

dism /online /cleanup-image /restorehealth

DISM reached 100% but completed with error 0x800f0915 ("The repair content could not be found anywhere"). Monitoring CBS.log during the run revealed the following errors repeating for multiple packages:

HRESULT = 0x800f0950 - CBS_E_NO_OPTIONAL_CONTENT_FOUND_FOR_BUILD

Specifically, manifests for the following packages could not be located on Microsoft's update servers:

• Microsoft-Hyper-V-Services-Package~31bf3856ad364e35~amd64~~10.0.26200.7840
• Microsoft-Windows-Subsystem-Linux-Package~31bf3856ad364e35~amd64~~10.0.26200.7840

These are the exact two packages that were accidentally deleted and are the root of the WSL/Hyper-V issue. The error indicates that Microsoft's update servers do not yet have FOD packages available for build 26200.7840, meaning DISM cannot restore them regardless of internet connectivity or source path.

Additionally, a leftover WIM mount at C:\WIMMount from a previous repair attempt required cleanup via:

powershell

dism /Unmount-Image /MountDir:C:\WIMMount /Discard
dism /Cleanup-Wim
takeown /F "C:\WIMMount" /R /D Y
icacls "C:\WIMMount" /grant administrators:F /T
Remove-Item -Path "C:\WIMMount" -Recurse -Force

---

Current Status: The ISP TLS interception issue is bypassed via hotspot. However, DISM RestoreHealth cannot restore the missing Hyper-V and WSL packages because their FOD payloads are not yet available on Microsoft's servers for build 26200.7840. The component store corruption related to these two packages remains unresolved pending Microsoft publishing the correct FOD content.

---

Questions:

1. Is there a permanent fix for Windows Update being intercepted by an ISP transparent proxy, short of always using a VPN or hotspot?
2. Is there a way to pre-download the VirtualMachinePlatform and WSL FOD packages on another machine and install them manually, bypassing Windows Update entirely?
3. Could the in-place upgrade failure (0x8007042B - 0x2000D MIGRATE_DATA) be related to the component store corruption from the missing packages, or is it a separate issue worth investigating?
4. Is there a known timeline or mechanism by which Microsoft publishes FOD packages for new Insider builds like 26200.7840, and is there a way to check availability before attempting DISM again?

Thanks in advance.WSL2 install stuck at 14% / VirtualMachinePlatform cannot be enabled — Windows Update TLS broken by ISP transparent proxy

Answer 1

Thanks for the response. I want to clarify a few points that weren't fully addressed:

1. /LimitAccess was being actively ignored by DISM

The response correctly states that /LimitAccess should prevent DISM from contacting Windows Update and force it to use only the local source. However, in my case, DISM ignored /LimitAccess entirely. Even with a valid 25H2 install.wim mounted and explicitly specified via /Source, monitoring CBS.log in real time showed DISM was still attempting Windows Update downloads (WULib DownloadProgress entries continued), meaning the local source was never used. This is not a matter of the payload being absent from the WIM — DISM never even checked the local source.

2. The FOD packages are not available on Microsoft's servers for build 26200.7840

After switching to a mobile hotspot (bypassing the ISP TLS interception), DISM /RestoreHealth ran to 100% but still failed with 0x800f0915. CBS.log showed repeated 0x800f0950 (CBS_E_NO_OPTIONAL_CONTENT_FOUND_FOR_BUILD) errors specifically for:

• Microsoft-Hyper-V-Services-Package~31bf3856ad364e35~amd64~~10.0.26200.7840
• Microsoft-Windows-Subsystem-Linux-Package~31bf3856ad364e35~amd64~~10.0.26200.7840

This means the issue is not just the ISP interception — even on a clean network connection, the repair content for these packages does not exist on Microsoft's update servers yet for this specific Insider build. The ISP issue and the missing FOD issue are two separate problems that were compounding each other.

3. The KB5048667 reference in the response is for build 26100.x (24H2) and is not relevant to my system (26200.7840 / 25H2).

My core outstanding question remains: is there any way to obtain the VirtualMachinePlatform and WSL FOD package payloads for build 26200.7840 outside of Windows Update, given that DISM cannot restore them and the standard ISO does not include them?

Answer 2

1. There is no configuration-based permanent fix in Windows for an ISP that performs TLS interception on Windows Update endpoints. When DISM or Windows Update needs repair content and cannot use a local source, it contacts Windows Update or a repair source as documented. If the network path is being intercepted or broken by the ISP, the only reliable workarounds are to use a different network path (such as a hotspot) or a secure tunnel that bypasses the interception. DISM itself has only two modes in this regard:
   • Use online sources (Windows Update or a configured repair source).
   • Use only local sources with /LimitAccess and explicit /Source paths. If the required payload is not present locally and the online path is untrustworthy or blocked, there is no additional built-in mechanism to override the ISP behavior.
2. DISM can restore or enable features from a local source if the payload exists there. The documented mechanism is:
   • Use /Source:<path> to point to a local WIM or folder that contains the feature payload, optionally with /LimitAccess to prevent contacting Windows Update:

          Dism /Online /Enable-Feature /FeatureName:TFTP /Source:Z:\sources\SxS /LimitAccess
     

   • For offline servicing, the same applies against a mounted image:

          Dism /Image:C:\test\offline /Enable-Feature /FeatureName:TFTP /Source:C:\test\mount\windows
     

   This works only if the feature’s payload is actually present in the specified source. For Features on Demand that are not included in the standard install.wim or in the available repair source, DISM will still fail with source-not-found errors. The context does not provide a method to independently download specific VirtualMachinePlatform or WSL FOD packages for Insider builds and apply them as standalone packages; it only documents using DISM with WIMs, mounted images, or configured repair sources.
3. Component store corruption and pending actions are explicitly called out as limitations for servicing operations. When packages are in an install-pending state or dependencies are missing, subsequent actions (including adding packages or performing upgrades) can fail until the pending or corrupted state is resolved. The documentation notes that:
   • When installing a package in an offline image, the package state can be “install pending,” and subsequent actions cannot be processed until previous pending actions are completed.
   • Some packages require other packages to be installed first, and dependencies must be satisfied, often via an answer file. Given that the Hyper-V and WSL packages are missing and DISM reports the component store as repairable but cannot find repair content, this corruption can affect other servicing operations, including upgrades. The context does not provide a specific mapping between error 0x8007042B - 0x2000D and this corruption, but it does establish that unresolved package and component store issues can block further servicing.
4. The context does not describe a public schedule or mechanism for when Features on Demand for specific Insider builds (such as 26200.7840) are published, nor does it provide a documented way to check availability of those FOD packages per build beyond attempting DISM operations that contact Windows Update or a configured repair source. The available guidance is:
   • Use DISM /Online /Cleanup-Image /ScanHealth and /RestoreHealth to detect and repair component store issues, optionally with a local /Source.
   • Use DISM /Online /Enable-Feature or /Disable-Feature with appropriate sources and, if needed, an answer file.
   • For servicing images, ensure version compatibility between DISM and the target image and rely on configured repair sources or Windows Update when payloads are not in the base image. No additional mechanism for tracking Insider FOD publication status is documented in the provided context.

---

References:

• Enable or Disable Windows Features Using DISM
• DISM Operating System Package (.cab or .msu) Servicing Command-Line Options
• Take Inventory of an Image or Component Using DISM
• DISM Overview
• December 10, 2024—KB5048667 (OS Build 26100.2605)