Closed bug report

Setup halts at ensure-workspace (1/20): wsl.exe unresponsive even after reboot, no distro registered (Win11 25H2, Hydrogen 1.0.201)

Caleb · 14d ago ·closed by John Lauer

Summary

On a fresh Windows 11 PC (caleb-adom), Hydrogen setup stops at step 1/20 ensure-workspace: wsl.exe never responds, so the WSL wedge auto-recovery gives up and the cascade halts. WSL is still unresponsive after a Windows restart, so the "restart Windows" manual step in the setup card does not clear it. No WSL distros are registered at all (no Adom-Workspace).

Environment

Hydrogen 1.0.201 (BUILD_STAMP b34cb0fb1fa9a629703cb9d9a44c5ad936877fa4-dirty-1788546736, built Sep 4). Update 1.0.575 is staged but not applied (staged-update.json)
Windows Windows 11 Home 25H2, build 26200.9457, 64-bit (registry ProductName still reads "Windows 10 Home")
CPU Intel Core Ultra 9 285H (x64, not ARM), 16 logical processors
RAM 31.4 GB
Last boot 2026-10-07 00:19 (setup attempt below ran after this boot)
Adom Bridge 2.1.172

WSL state (read-only checks, 2026-10-09)

  • wsl --version → no response within 30 s
  • wsl -l -v → no response within 30 s
  • wsl --status → no response within 30 s
  • Lxss registry: 0 distros registered (no Adom-Workspace, no Docker distro, no default distribution)
  • No wsl, wslservice, wslhost, vmmem* or Docker Desktop processes running.

Where setup stopped (latest run, 2026-10-07)

setup-state.txt = in-progress; wsl-progress.txt = 1/20 ensure-workspace FAILED (after 1 attempts).

From hydrogen-desktop.log:

09:49:42.747 [run_all_wsl] resume: keep done steps, run from first non-done (distro_real=false)
09:49:53.388 [run_all_wsl] install-approval not available (AB direct API not reachable (no live discovery file + fixed range silent, likely HNS-reserved)), continuing with per-verb prompts
09:49:53.388 [run_all_wsl] RUN 'ensure-workspace' (status was Pending)
09:51:36.228 [ad-relay] relay :8766 not answering /health — restarting adom-relay.service once
09:51:48.285 [ad-relay] relay STILL down after restart (ws:8765 http:8766); status: workspace is still booting, try again in a moment
09:53:39.590 [run_all_wsl] HALT: step 'ensure-workspace' failed after 1 attempts; not advancing to later steps
09:53:39.592 [run_all_wsl] persisted setup-state.txt = in-progress (GET /setup/state matches the cascade)

Step output (setup-steps-wsl.json, ensure-workspace, status failed):

=== Ensure WSL2 subsystem is responsive (auto-recovers if wedged) ===
  $ wsl --status
    … still running `wsl --status`, 45s elapsed, no response yet…
  ⚠ `wsl --status` did not respond within 45s (WSL likely wedged)
  → WSL looks WEDGED, auto-recovery round 1/3 (kill stuck launchers + restart the subsystem):
  $ taskkill /F /IM wsl.exe   (clearing stuck wsl.exe launchers)
    | killed 0 stuck wsl.exe process(es)
  Docker Desktop WSL is running, scoped restart instead:
  $ wsl --terminate Adom-Workspace
    … still running `wsl --terminate Adom-Workspace`, 15s elapsed, no response yet…
  ✗ WSL is still wedged after two restarts, not restarting again; handing you manual steps.
✗ Windows Subsystem for Linux is still wedged after two restarts. Open PowerShell as Administrator, run  wsl --shutdown, then relaunch Hydrogen Desktop ... (WSL2 is wedged at the system level, even the restart command (`wsl --shutdown`/`--terminate`) didn't respond, so only a Windows restart can clear it.)

History on this PC

  • wsl-install-attempted.txt: 2026-09-14T18:35:33Z
  • setup-steps.json (older flow): ensure-wsl failed — "WSL distro not running 4 attempts after reboot. Last boot at 2026-09-17T07:25:33" (4/3 attempts, last 2026-09-17T17:11Z)
  • wsl-wedge-reboot-count.txt = 2
  • Log sessions: 2026-09-10, 09-14, 09-17, 10-05, 10-06, 10-07; the PC has been restarted since and WSL is still unresponsive.

Observations for triage

  1. Not a transient wedge: wsl.exe hangs on even --version after a reboot, and no distro is registered. This looks like a broken or half-installed WSL platform (install attempted 2026-09-14), not a stuck VM, so the "restart Windows" advice in the card loops the user.
  2. Docker detection looks wrong: recovery logged "Docker Desktop WSL is running, scoped restart instead" and skipped wsl --shutdown, but no Docker distro is registered and no Docker process is running. The scoped wsl --terminate Adom-Workspace targets a distro that doesn't exist.
  3. Setup sees distro_real=false yet runs only the responsiveness check; it never reaches a reinstall or repair path for the WSL platform itself.
  4. Possibly related: the AB direct API is unreachable at setup start ("likely HNS-reserved"), and the staged 1.0.575 update has not been applied (the app is still 1.0.201).

Nothing on the PC was changed or repaired while collecting this. Attached: the full hydrogen-desktop.log (39,726 lines; the 2026-10-07 run starts at line 32387) and the setup state files.

hydrogen-desktop.log

setup-steps-wsl.json

setup-state.txt

setup-steps.json

4 Replies

Caleb · 14d ago

Resolved on caleb-adom (2026-10-09)

Root cause: the WSL platform was half-installed. Only the old Store-style package MicrosoftCorporationII.WindowsSubsystemForLinux 2.5.9 was present: no C:\Program Files\WSL and no WSLService. So the inbox wsl.exe hung on every call, even --version. The hypervisor was present and virtualization was fine. A Windows restart could not fix this.

Fix applied:

  1. Installed the official Microsoft WSL MSI 3.0.1 (wsl.3.0.1.0.x64.msi from github.com/microsoft/WSL/releases; sha256 28b1a0d0…599c6, Microsoft-signed), elevated through one UAC prompt. The install exited 0 and needed no reboot.
  2. Afterwards wsl --version reports WSL 3.0.1.0 / kernel 6.18.40.1-1, WSLService is running, and wsl --status reports default version 2.
  3. Applied the staged Hydrogen 1.0.575 update (the PC was still on 1.0.201) and relaunched. Setup resumed and completed 8/8 (ensure-workspace → open-welcome) in about 2 minutes, and setup-state = complete.

Suggested product fixes:

  • In ensure-workspace, detect "WSLService missing / no Program Files\WSL" and offer to install the WSL MSI (or run wsl --update), instead of the wedge/restart loop.
  • Fix the "Docker Desktop WSL is running" false positive: no Docker distro or process existed.
  • The setup card's "restart Windows" advice can't fix a missing service.
Caleb · 14d ago

Suggestion: a pre-launch check for required companion installs

What made this hard to diagnose: Hydrogen opened and ran its setup on top of a broken prerequisite (WSL with no WSLService). The only symptom was a "wedged" timeout loop.

Proposal: Hydrogen should not open its main window until a pre-launch check confirms that every required companion install is present and healthy. Show the results in one easy-to-read checklist, for example:

Requirement Check Status Action if missing
Virtualization Hypervisor present / VT-x enabled ✓ / ✗ BIOS/UEFI instructions
Windows features Virtual Machine Platform, Windows Subsystem for Linux enabled ✓ / ✗ Enable (one UAC prompt)
WSL platform WSLService installed and running, C:\Program Files\WSL present, wsl --version answers within ~10 s, version ≥ minimum ✓ / ✗ Install or repair the WSL MSI (one UAC prompt)
Workspace distro Adom-Workspace registered and starts ✓ / ✗ Create or import it (Hydrogen step)
Adom Bridge Installed, version ≥ floor, direct API reachable ✓ / ✗ Install or update
Hydrogen itself Version ≥ fleet floor; a staged update gets applied before setup runs ✓ / ✗ Apply update
Other first-class apps (e.g. Docker Desktop if used, KiCad/Fusion bridges if enabled) Detected correctly (no false positives) ✓ / – Install / ignore

Behaviour:

  • Gate: if any required row is ✗, show the checklist instead of the editor, with one button per fix and a single "Fix all" button. Each fix states up front whether it needs admin or a reboot.
  • Verify, don't assume: each check reads real state (service exists, binary answers, version), not just "an installer ran once" (wsl-install-attempted.txt).
  • Same checks everywhere: reuse the checklist in "Report a problem" and in diagnostics, so a bug report always carries the prerequisite state.
  • Re-run on every launch and after updates, since Windows updates and Store package changes can silently break WSL again.

On this PC that checklist would have shown "WSL platform ✗ (WSLService missing)" on the first launch, with a one-click fix, instead of weeks of failed setup attempts.

John Lauer · 13d ago

Thanks Caleb, this was a great report. The root cause and the fix you found turned straight into code.

Fixed (insiders build 1.0.580, building now):

  1. Half-installed WSL is repaired, not treated as a wedge. Before the wsl --status probe, setup now checks for exactly the state you found: the Store WSL package is present, but WSLService and C:\Program Files\WSL are missing. In that case it downloads Microsoft's WSL MSI for the PC's architecture from github.com/microsoft/WSL and installs it elevated. That's one UAC prompt and no reboot, the same fix you applied. The restart loop no longer starts for this case.
  2. A PC stuck in setup installs its waiting update. Your PC sat on 1.0.201 with 1.0.575 staged because the update banner lives in the editor, and a PC stuck on the setup card never shows it. Now, when setup isn't complete and no step is running, the updater applies the staged update itself, and setup resumes where it stopped.
  3. The Docker false positive is already gone in current builds. Your PC was running 1.0.201. Today's wedge recovery never guesses about Docker; it only terminates our own distro.

Your pre-launch checklist idea: this is a bigger design change (gating the main window on a verified prerequisites list with one-click fixes), so I've passed it to John to decide. The two fixes above cover the WSL row for now.

John Lauer · 9d ago

Closing: Caleb's PC finished setup (1.0.575) and is still running today.

Follow-ups shipped since:

  • 1.0.580: the half-installed state (Store package, no WSL service) is repaired with Microsoft's WSL package, one Windows prompt, no restart.
  • 1.0.598: the related case where WSL itself was removed (for example from Settings > Apps) while the Virtual Machine Platform stays on. Setup used to stop with "your Windows edition may not support WSL2"; it now reinstalls WSL the same way. Verified on a clean Azure VM.
  • 1.0.598: a PC stuck in setup applies its waiting Hydrogen update by itself, including when the download finishes seconds before setup stops.

Log in to reply.