wsl --install should detect a pending CBS reboot instead of failing with an undecodable Error: 0xc004000d

[lsc892]

TL;DR — When a CBS reboot is pending, wsl --install fails with a bare Error: 0xc004000d that has no text in the system message table and, from its 0xC004xxxx shape, looks like a Windows activation failure. It is not. CBS actually succeeded and deferred the feature-enable to the next reboot (S_OK, Reboot required: yes); the DISM API layer re-reads the feature state, sees it still disabled, and reports that as a failure. Retrying then leaves the package Staged, which produces a second, unrelated and factually wrong error: 0x80070032 "Parent features must be enabled". Fast Startup means the user's habitual "shut down, power on" never clears the pending queue, so this loops indefinitely.

User-side fix: a real Restart. This also explains why the long-standing community workarounds in MicrosoftDocs/WSL#1296 work — see Related.

Ask for WSL: check for the pending-reboot state before touching optional features and say so, instead of surfacing an opaque code.

---

Windows Version

Microsoft Windows [Version 10.0.19045.6466] (Windows 10 Home 22H2)

WSL Version

0.0.0.0 at time of repro (inbox wsl.exe 10.0.19041.4522 — Store WSL never gets installed because wsl --install aborts at the optional-feature stage). Now 2.7.11.0 after the resolution below.

Are you using WSL 1 or WSL 2?

• WSL 2

Kernel Version

N/A — installation never reaches kernel setup.

Distro Version

N/A

Other Software

None involved.

Repro Steps

1. Windows 10 Home 22H2 (19045.6466). Windows is activated (SoftwareLicensingProduct.LicenseStatus = 1, OEM:DM channel). VT-x and SLAT are enabled in firmware.
2. Get the machine into a state where CBS has a pending reboot queued, i.e. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending exists. This happens naturally after a servicing operation when the machine has not had a true restart — note that with Fast Startup enabled (HiberbootEnabled = 1), "Shut down" followed by power-on is a hybrid resume and does not flush the pending queue. Only "Restart" does. On my machine uptime was 14.6 days despite regular shutdowns.
3. Run wsl --install from an elevated prompt.

Expected Behavior

wsl --install should detect the pending-reboot condition and say so — something like "A restart is required to complete a pending servicing operation. Please restart and run wsl --install again." WSL already knows how to ask for a reboot after enabling features, so surfacing this specific precondition would be consistent.

Failing that, the error surface should at least be identifiable rather than a bare Error: 0xc004000d with no text.

Actual Behavior

wsl --install fails immediately with an undecodable error code:

C:\Windows\system32>wsl --install
설치 중: 가상 머신 플랫폼
Error: 0xc004000d

0xc004000d has no message in the system message table (certutil -error 0xc004000d returns no text), and its 0xC004xxxx shape strongly suggests a Software Licensing / activation failure. That is a false lead: Windows is fully activated on this machine. I spent a while chasing activation before finding the real cause.

Attempting the same thing directly through DISM reproduces it:

C:\Windows\system32>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
...
오류: 50
작업이 완료되었지만 VirtualMachinePlatform 기능을 사용하도록 설정하지 않았습니다.
(Error: 50 — The operation completed but VirtualMachinePlatform was not enabled.)

C:\Windows\Logs\DISM\dism.log:

Error DISM API: Failed to enable feature VirtualMachinePlatform. - CEnableDisableFeatureCommandObject::InternalExecute
Error DISM API: InternalExecute failed - CBaseCommandObject::Execute(hr:0xc004000d)
Error DISM API: CEnableDisableFeatureCommandObject internal execution failed - DismEnableDisableFeatureInternal(hr:0xc004000d)

Second-order symptom that makes this much harder to diagnose: the failed attempt leaves the feature's package in Staged state. Every subsequent attempt then fails with a completely different and even more misleading error:

Info  DISM Package Manager: Feature VirtualMachinePlatform with CBS state 4(CbsInstallStateStaged)
                            being mapped to dism state 4(DISM_INSTALL_STATE_STAGED)
Error DISM Package Manager: Parent features must be enabled before this feature can be enabled.
                            "VirtualMachinePlatform"
Error DISM Package Manager: One or more features could not be enabled. (hr:0x80070032)

VirtualMachinePlatform has no disabled parent feature. Microsoft-Windows-Subsystem-Linux fails identically. Both features report 상태 : 사용 안 함 (Disabled) via /Get-FeatureInfo, and the component store is clean:

C:\Windows\system32>DISM /Online /Cleanup-Image /ScanHealth
[==========================100.0%==========================] 손상된 구성 요소 저장소가 검색되지 않았습니다.
(No component store corruption detected.)

So every standard troubleshooting avenue — activation, sfc /scannow, DISM /RestoreHealth, BIOS virtualization — comes back clean, and the "Parent features must be enabled" message actively points away from the real problem.

Root cause

C:\Windows\Logs\CBS\CBS.log shows the truth. CBS succeeded and simply deferred the work to the next reboot:

2026-08-10 14:12:03, Info  CBS  Exec: Found package is smart pending queue:
                                 Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~10.0.19041.1
2026-08-10 14:12:03, Info  CBS  Exec: Task package already smart pended by earlier sessions,
                                 force package smart pend
2026-08-10 14:12:03, Info  CBS  Perf: InstallUninstallChain complete.
2026-08-10 14:12:03, Info  CBS  Exec: Scheduled TrustedInstaller for auto-start because session was delayed.
2026-08-10 14:12:03, Info  CBS  TI: CBS has signaled that a reboot is required.
2026-08-10 14:12:03, Info  CBS  Exec: Execution Skipped for now.
2026-08-10 14:12:03, Info  CBS  Exec: Processing complete. ... [HRESULT = 0x00000000 - S_OK]
2026-08-10 14:12:03, Info  CBS  Session: 31271046_3324950609 finalized. Reboot required: yes [HRESULT = 0x00000000 - S_OK]

There are no CBS errors at all in that session. The only non-success entries are benign:

Info CBS Failed setting restore point [HRESULT = 0x80070422 - ERROR_SERVICE_DISABLED]
Info CBS Failed to move \\?\C:\Windows\CbsTemp\... [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]

Confirming the precondition:

PS> Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
True
PS> (Get-CimInstance Win32_OperatingSystem).LastBootUpTime   # 14.6 days ago
PS> (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power').HiberbootEnabled
1

So the sequence is:

1. A pending reboot is outstanding, so CBS puts the feature-enable into the smart-pend queue and returns S_OK with "reboot required".
2. The DISM API layer immediately re-reads the feature state, sees it is not Enabled, and reports failure — surfacing 0xc004000d instead of the "reboot required" signal CBS actually returned.
3. wsl --install passes that opaque code straight through to the user.
4. The package is now Staged, so retries produce the unrelated 0x80070032 / "Parent features must be enabled".
5. Fast Startup means the user's habitual "shut down, power on" never clears the pending reboot, so the loop repeats indefinitely.

Resolution

Confirmed fixed. A genuine Restart (not shutdown + power-on) flushes the pending CBS queue. Verified afterwards:

PS> Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
False                                  # was True
PS> (Get-Service LxssManager).Status   # feature now present
PS> (Get-Service vmcompute).Status     # feature now present

With the pending queue cleared, the optional features enabled without complaint. Full working sequence:

# 1. Elevated. A real Restart first (Start > Power > Restart), NOT shutdown + power-on.
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -All -NoRestart
# 2. Restart again.
# 3. Install the WSL 2 kernel (see note below), then:
wsl --set-default-version 2
wsl --install -d Ubuntu

Optionally disable Fast Startup so future servicing operations are not silently deferred:

Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power' -Name HiberbootEnabled -Value 0

Note: one more step was needed to finish the install

Clearing the pending reboot resolves 0xc004000d, but it is not the whole story on this build. On 19045 with the inbox wsl.exe, the WSL 2 kernel is not brought in as part of wsl --install, so distro registration then failed with 0x800701bc. Installing the kernel package completed it:

msiexec /i wsl_update_x64.msi /passive     # https://aka.ms/wsl2kernel
wsl --set-default-version 2
wsl --unregister Ubuntu                    # the failed first pass had left a half-registered entry
wsl --install -d Ubuntu

Noting this only so the sequence is reproducible end to end. 0x800701bc is expected behaviour on this build and is not part of what I am reporting here.

Final verified state on this machine:

PS> wsl --version
WSL version: 2.7.11.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
Windows version: 10.0.19045.6466

PS> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Running         2

Suggested fix

1. Check for a pending reboot before touching optional features. If Component Based Servicing\RebootPending (or PackagesPending / WinSxS\pending.xml) is present, wsl --install should stop with a clear message asking for a restart, instead of queuing a change that cannot execute.
2. Do not swallow the CBS "reboot required" result. DismEnableFeature here corresponds to a session that finalized with S_OK, Reboot required: yes. That is the reboot-pending path wsl --install already handles after a successful enable — it should be handled here too rather than collapsing into 0xc004000d.
3. Make the error printable. Error: 0xc004000d with no accompanying text sends users toward Windows activation, which is unrelated. Even appending "see %windir%\Logs\CBS\CBS.log" would save a lot of time.
4. Consider detecting the Staged leftover state and reporting it as "a previous attempt is pending a restart" rather than letting DISM emit "Parent features must be enabled", which is factually wrong for VirtualMachinePlatform.

Related

• wsl --install results in Error 0xc004000d on win 11 #9643 (wsl --install results in Error 0xc004000d on win 11) — closed by pointing at WSL installation giving errors. Not able to install on Windows 10 OS build:19043.1237 MicrosoftDocs/WSL#1296. Reporter was on Windows 11 Pro 22H2 (22621.1105), so this is not specific to old hardware or to Windows 10.

• WSL installation giving errors. Not able to install on Windows 10 OS build:19043.1237 MicrosoftDocs/WSL#1296 — the origin thread, open since 2021, with the same error reported on Windows 10 19043 and on Windows 11 Pro for Workstations 21H2. Two workarounds in that thread are reported as working:

  1. Enabling WSL through Control Panel → Turn Windows features on or off, which — as the commenter notes — prompts for a restart, after which the error is gone.
  2. "Run wsl --install, then reboot Windows."

  Both work because they force a restart, which flushes the pending CBS queue. That mechanism is never stated in the thread; it was found by trial and error. This matters in two ways:

  • When the restart is not part of the path, the workaround fails. One commenter followed the Windows Features route and hit 0x80073701 instead, with no follow-up.
  • Because the mechanism is unknown, the escalation path is disproportionate. Several Microsoft Q&A threads carrying this same error recommend an in-place repair install of Windows for what a single restart resolves.

  So the practical cost of 0xc004000d being unreadable is not just confusion — it is users reinstalling Windows unnecessarily. That is the case for fixing the reporting, independently of whether the underlying DISM behavior is in scope for this repo.

• Not the same issue, noting it because it surfaces in the same searches: WSL install fails with Failed to enable Windows component 'VirtualMachinePlatform' (exit code 14107) #12196 is a different failure (14107 / 0x8007371B, a CBS transaction error) and is unresolved.

Diagnostic Logs

Relevant excerpts inlined above from:

• C:\Windows\Logs\DISM\dism.log
• C:\Windows\Logs\CBS\CBS.log (sessions 31271046_3324950609 and 31271047_186441305)

Happy to attach the full CBS log if useful.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[lsc892]

/feature

[github-actions]

Diagnostic information

Found '/feature', adding tag 'feature'

[chemwolf6922]

Hi lsc892 (@lsc892)
I'm not able to repro this on win10 22h2 and win11 25h2. However, the win10 version is slightly newer than yours.
Could you please provide these information to help diagnose this?

• The full cbs.log file.
• The full dism.log file.
• The full dism.log.bak file if present.
• The timestamp you triggered the issue.

[lsc892]

wsl-logs.zip

Thanks for taking a look, Feng Wang (@chemwolf6922). Logs attached as wsl-logs.zip.
In dism.log I masked my Windows account name (<USER>);

Timestamp — 2026-08-10 14:12:00–14:12:03 KST (UTC+9).
CBS session 31271046_3324950609 at CbsPersist_20260810061021.log:44215-44222;
the corresponding DISM failure is at dism.log:9331-9332.

[github-actions]

No logs.etl found in the archive. Make sure that you ran collect-wsl-logs.ps1 as administrator and that the logs.etl file is in the archive.

Diagnostic information

appxpackage.txt not found
optional-components.txt not found
No logs.etl found in archive.
Error while parsing the logs. See action page for details