Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Tray spawns `wsl.exe` during session teardown, producing an "Application Error 0xc0000142" popup on every shutdown/restart

Open
  • Is something wrong?
#1,571 5 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
64/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
desktop, operating-systems

Research direction

Trace _reArmKeepAliveAsync, reconnectIfCurrentAsync, probeReachableAsync, and WslGatewayKeepAliveService.TryEnsureAsync to find every reconnect or keepalive spawn. Add session-ending guards and logging for the repair/probe command, then reproduce with a Windows shutdown or restart. Done means teardown produces no new wsl.exe spawn or Application Popup event while normal reconnect behavior remains intact.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P2
Summary

When the tray is running (the normal case — it autostarts), shutting down or
restarting Windows frequently pops up a Windows hard-error dialog:

wsl.exe - Application Error
应用程序无法正常启动(0xc0000142)。请单击"确定"关闭应用程序。

This is STATUS_DLL_INIT_FAILED raised via NtRaiseHardError. It happens because
the tray's reconnect timers fire after the session has started tearing down, and
each fire spawns a wsl.exe that can no longer get a conhost. Nothing is actually
broken — the gateway comes back fine on next boot — but the dialog is alarming and
users reasonably read it as "my system is failing".

Environment
OS Windows 11 Home (China), build 10.0.26300
App OpenClaw Companion 2026.9.4.0 — D:\OpenClawTray\OpenClaw.Tray.WinUI.exe
Distro app-owned OpenClawGateway (base Ubuntu-24.04, systemd enabled)
Gateway ws://127.0.0.1:18789, loopback + token auth
Data %APPDATA%\OpenClawTray\settings.json, %LOCALAPPDATA%\OpenClawTray\openclaw-tray.log
Tray autostart yes; starts 2–4 min after boot
Steps to reproduce
  1. Start the tray normally and let it reach the steady state (keepalive running,
    i.e. a long-lived wsl.exe -d OpenClawGateway -- sleep infinity is present).
  2. Shut down or restart Windows from the Start menu.

Observed on essentially every shutdown where teardown takes long enough for the
timers to fire (~45% of shutdowns on this machine, measured over 47 shutdowns
since install; when it happens it is exactly 2 dialogs, always).

Observed behaviour

The dialogs are recorded verbatim by Windows as Application Popup, System log,
Event ID 26 (Properties[0] = caption, Properties[1] = message):

10-01 12:46:xx  [wsl.exe - Application Error]  应用程序无法正常启动(0xc0000142)。请单击"确定"关闭应用程序。
10-01 12:46:xx  [wsl.exe - Application Error]  应用程序无法正常启动(0xc0000142)。请单击"确定"关闭应用程序。
10-01 14:31:xx  [wsl.exe - Application Error]  … (x2, same text)
10-01 16:44:46  [wsl.exe - Application Error]  … (x2 — 16:44:46 and 16:44:49)

Correlated with the tray log (%LOCALAPPDATA%\OpenClawTray\openclaw-tray.log,
local time — note the app logs local, not UTC):

16:44:44  User32 1074: shutdown initiated (StartMenuExperienceHost.exe, "restart")
16:44:45  <both WS sockets to the gateway close>  "Connection closed prematurely" (x2, 15-35 ms apart)
16:44:45  "node reconnecting in ~1.1s"
16:44:45  "gateway reconnecting in ~1.2s"
16:44:46  timer fires -> wsl.exe spawn          <- dialog #1
16:44:47  timer fires -> wsl.exe spawn          <- dialog #2
16:44:46+ Winlogon 6000 / 7002, FilterManager 6006, Hyper-V-VmSwitch NIC teardown

Inter-dialog spacing is not fixed (0.09 s / 0.15 s / ~3 s observed across events),
so it is not one code path firing twice on a fixed schedule — it is the two
independent reconnect paths (node + gateway) racing the teardown.

Which spawn is it

The spawn command is wsl.exe -d OpenClawGateway -- bash -s (the repair/probe
form), not the steady-state -- sleep infinity. Note that the tray logs nothing
for this spawn — the log has no Repair/Probe line at all, which is what made
this hard to pin down from the outside. Might be worth logging it.

Ruled out (by testing, not by reading)
  • EnableManagedLocalGatewayAutoRepair: false does not prevent it. With that
    switch set, the 2026-10-01 16:44:44 restart still produced exactly 2 dialogs
    (16:44:46 and 16:44:49) — same as with it left true (12:46 → 2, 14:31 → 2).
    So the spawn is not (only) the auto-repair coordinator; it is the
    reconnect/keepalive path. Setting reverted afterwards.
  • EnableNodeMode: false would at best remove 1 of the 2, at a large functional
    cost, so it is not a fix.
  • This is not a WSL/hypervisor defect: the distro itself is fine, and the same
    wsl.exe runs happily all day while a session is alive. The problem is purely
    "spawn a console app after teardown has begun".
  • Not a WER dialog: HKCU\...\Windows Error Reporting\DontShowUI does not
    suppress it (this is a hard error, not a report).
Root cause, as best I can tell from outside

The 4 tray assemblies contain zero occurrences of SystemEvents,
SessionEnding, QUERYENDSESSION, HasShutdownStarted, or WM_ENDSESSION.
The app has no notion of "the session is ending", so when the gateway connection
drops during shutdown it treats it as an ordinary transient disconnect and re-arms
keepalive / reconnect timers (_reArmKeepAliveAsync, reconnectIfCurrentAsync,
probeReachableAsync, WslGatewayKeepAliveService.TryEnsureAsync) into a session
that is already gone.

Suggested fix
  1. Before any keepalive/reconnect spawn, bail out if the session is ending. Either:
    • check Environment.HasShutdownStarted, and/or
    • subscribe once to Microsoft.Win32.SystemEvents.SessionEnding and set a flag
      that gates _reArmKeepAliveAsync / the reconnect callbacks, and/or
    • poll GetSystemMetrics(SM_SHUTTINGDOWN) (works without a message pump).
      Any of these would also stop the pointless spawn during logoff, not just
      shutdown/restart.
  2. Log these spawns (command + reason) — their absence from the log is the main
    reason this took a full day of external tracing to attribute.
Impact

Cosmetic but loud, and in this case it is the only thing the user sees at
shutdown, so it reads as a system fault. There is no in-app workaround.

The only machine-side suppression I found is
HKLM\SYSTEM\CurrentControlSet\Control\Windows\ErrorMode = 2. I have since
verified it on a restart where the trigger chain definitely fired (same two
Connection closed prematurely lines, same two reconnect timers): the dialogs
are no longer displayed, but Windows still logs the three Application Popup
records, so the underlying spawn still happens and the failure is only hidden —
not fixed, and now hidden machine-wide for every app. That is why this still
needs a fix in the tray.

Diagnostic commands used
# the authoritative record of a desktop popup (caption + message)
Get-WinEvent -FilterHashtable @{LogName='System';Id=26;StartTime=(Get-Date).AddDays(-7)} |
  Sort-Object TimeCreated |
  ForEach-Object { "{0:MM-dd HH:mm:ss} [{1}] {2}" -f $_.TimeCreated, $_.Properties[0].Value, (($_.Properties[1].Value -replace '\s+',' ')) }

# what initiated the shutdown
Get-WinEvent -FilterHashtable @{LogName='System';Id=1074;StartTime=(Get-Date).AddDays(-7)} |
  Sort-Object TimeCreated |
  ForEach-Object { "{0:MM-dd HH:mm:ss}  {1}" -f $_.TimeCreated, (($_.Properties | ForEach-Object {$_.Value}) -join ' | ') }

# the trigger chain in the tray's own log
Select-String -Path "$env:LOCALAPPDATA\OpenClawTray\openclaw-tray.log" `
  -Pattern 'Connection closed prematurely|reconnecting in' -Encoding UTF8
Dominant language
C#
Stars
2.2k
Forks
321
Avg merge
3d 17h
Merged PRs (30d)
173

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.