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

@benhillis is already working on this.

Since Aug 11, 2026.

**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](#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?

- [x] 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:

```powershell
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:

```powershell
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:

```powershell
# 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:

```powershell
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:

```powershell
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

- **#9643** (`wsl --install` results in Error 0xc004000d on win 11) — closed by pointing at MicrosoftDocs/WSL#1296. Reporter was on **Windows 11 Pro 22H2 (22621.1105)**, so this is not specific to old hardware or to Windows 10.
- **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: **#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.