WSLg weston SIGSEGV crash loop every ~100s (WSL 2.7.13.0 / WSLg 1.0.73.2); weston-notify.sock lost after first crash

Nobody has claimed this yet.

# WSLg weston SIGSEGV crash loop every ~100 seconds (WSL 2.7.13.0 / WSLg 1.0.73.2)

## Environment

- **Windows**: 10.0.26200 (25H2, build 26200.9445)
- **WSL**: 2.7.13.0
- **Kernel**: 6.18.33.2-2
- **WSLg**: 1.0.73.2 (Azure Linux 3.0.20260510)
- **MSRDC**: 1.2.7214
- **Direct3D**: 1.611.1-81528511
- **GPU**: RTX 5070 + AMD Radeon iGPU (display output on AMD iGPU)
- **Distro**: Ubuntu-2204-old (also registered: Ubuntu-22.04, stopped)
- **.wslconfig**: memory=32GB, networkingMode=mirrored, dnsTunneling=true, autoProxy=true, firewall=true, instanceIdleTimeout=-1

## Summary

weston (the WSLg compositor) SIGSEGV-crashes in a loop, once every ~100 seconds, **deterministically at the same code offset**. Each crash kills the X server, disconnects all running GUI apps, and the WSLGd watchdog restarts weston ~100s later, repeating forever. msrdc.exe also restarts each cycle.

## Repro

1. Install WSL 2.7.13.0 (WSLg 1.0.73.2).
2. Boot any distro (a GUI app is NOT required — the crash occurs during app-list enumeration at weston startup).
3. Watch `/mnt/wslg/stderr.log` for recurring `terminated with signal 11` lines ~100s apart.

## Key evidence

### 1. Crash frequency and deterministic offset

`stderr.log` shows weston killed by signal 11 every ~100 seconds (14 times in the current session, ~23 min):

```
[08:40:12.623] WSLGd: Run:110: pid 13 terminated with signal 11, /usr/bin/sh -c /usr/bin/weston --backend=rdp-backend.so ...
[08:41:51.882] ... pid 6954 terminated with signal 11 ...
[08:43:32.563] ... pid 10476 terminated with signal 11 ...
... (every ~100s)
```

Core dumps (captured via `|/wsl-capture-crash`) analyzed with gdb show **identical RIP offset 0x1717b** in the same anonymous mapping across multiple independent crashes — a deterministic crash at one code location, not a random fault:

```
#0 0x00007c6009d6717b in ?? () (mapping 0x7c6009d50000-0x7c6009d68000, offset 0x1717b)
#0 0x00007f050eb7917b in ?? () (mapping 0x7f050eb62000-0x7f050eb7a000, offset 0x1717b)
```

### 2. Crash occurs right after app-list enumeration completes

`weston.log` always ends the crash cycle right after app-list folder enumeration finishes (`app list folder[3]: /var/lib/flatpak/...`), i.e. in the notify/publish phase. The core contains `../compositor/wslgd-notify.c` — the crash is in the wslgd-notify path.

```
[09:26:57.625] app list folder[3]: /var/lib/flatpak/exports/share/applications
[09:26:57.521] (weston SIGSEGV, ~0.1s later)
```

### 3. weston-notify socket is lost after the first crash

First weston start of a WSL session: socket connects OK. After the first SIGSEGV, every restart fails:

```
[08:38:27.107] ../compositor/wslgd-notify.c: socket connected
[09:28:38.138] wet_module_init: connect(/mnt/wslg/weston-notify.sock) failed No such file or directory
```

`/mnt/wslg/weston-notify.sock` does not exist after the first crash. This appears to be a **consequence** of the crash (the socket never gets recreated), which then keeps the loop going, since weston can no longer notify WSLGd.

### 4. msrdc RDP transport failures

`wlog.log` shows `Accepted client` succeeded but transport write failed immediately:

```
[08:30:39] Accepted client: MSN-0597
[08:30:39] transport_write: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
```

### 5. Related: app-icon enumeration bug (find_icon_file) — fixed locally, but crash persists

We also hit the app-icon enumeration crash reported for this exact weston build (PR microsoft/weston-mirror#162, merge commit 04d436c7 = this WSLg's weston): icons with `Icon=` pointing to missing theme/absolute paths made weston SIGSEGV with `find_icon_file ... global:(0)` on the same offset 0x1717b. Fixing ALL .desktop icons (absolute paths to existing PNGs, removing a snap `ubuntu-desktop-installer` entry) stopped the icon-enumeration crash — but **the weston crash loop continues anyway**, now in the notify phase. This suggests offset 0x1717b is in librsvg/rayon thread-pool JIT code (as described in PR #162) and is reachable from multiple code paths.

## Expected behavior

weston stays alive; WSLg GUI apps keep their windows; no unbounded crash loop.

## Actual behavior

- weston SIGSEGV every ~100s, killing X and all GUI apps
- msrdc restarts every cycle
- Every crash also writes an ETL trace (`%TEMP%\DiagOutputDir\RdClientAutoTrace\RdClientAutoTrace-WppAutoTrace-*.etl`, ~8-9 MB each, unbounded) — this folder grew to 16 GB in ~13 hours before we stopped it (see issue #10216)

## Related issues

- microsoft/WSL#10216 (RdClientAutoTrace disk fill — still open, recurring reports through 2026-06)
- microsoft/weston-mirror#162 (app-list cascade fix — merged 04d436c7, present in this build, but SIGSEGV variant persists)
- microsoft/wslg#1049 / #991 (random WSLg crashes)

## Attachments

- `weston.log`, `stderr.log`, `wlog.log`, `versions.txt` (WSLg system distro logs)
- Latest weston core dump (xz-compressed, ~720K)
- `crash-analysis.txt` (gdb findings, register dumps, RIP offsets)
- `system-info.txt` (versions, .wslconfig, GPU)

## Note

User's local mitigations (done while triaging):
- Replaced `%TEMP%\DiagOutputDir\RdClientAutoTrace` folder with a read-only same-name file to stop the disk fill (issue #10216 workaround)
- Fixed all `.desktop` icon paths to absolute existing PNGs (removed the icon-enumeration crash trigger)
- WSL crash capture (`/proc/sys/kernel/core_pattern = |/wsl-capture-crash`) left enabled on purpose

Please consider: (1) fixing the weston SIGSEGV (offset 0x1717b, wslgd-notify phase), (2) recreating `/mnt/wslg/weston-notify.sock` after weston restart, (3) bounding the msrdc WPP AutoTrace (rotate/limit), (4) publishing a fix update for WSL 2.7.x.

Start with crash-analysis.txt and the attached weston core, then compare weston.log and stderr.log around app-list enumeration and the wslgd-notify.c path mentioned in the report. Verify the repeated crash offset and socket loss across restarts. Done means weston remains alive, GUI applications stay connected, and the notify socket is available after recovery.

Written by the indexing model from the issue text.