Recurring WSL2 kernel panic with guest-initiated reset on kernel 6.18.33.2 under Docker Desktop

## Windows Subsystem for Linux

### WSL Version

2.7.11.0

### WSL Kernel Version

6.18.33.2-2

### Windows Version

Windows 11 Pro, build 10.0.26200.7623

### Distro Version

Docker Desktop 4.84.0 WSL2 backend (`docker-desktop` utility VM). No user distro involved in the crashes.

### Other Software

Docker Desktop 4.84.0. Host RAM 8 GB. No `.wslconfig` present -- all defaults.

### Repro Steps

The failure is intermittent and **has not been reproduced on demand**.

1. Run Docker Desktop continuously with a small always-on compose stack (4 containers: a reverse proxy, an API, a background worker, PostgreSQL). Total container memory footprint is a few hundred MB.
2. Leave the machine otherwise idle. No builds, no heavy allocation, no interactive use.
3. After hours to days, the WSL2 utility VM kernel-panics and is re-created.

It has occurred **5 times in ~3.5 days**. Notably, one occurrence happened with a guest uptime of **0 seconds** -- the VM panicked essentially at boot, on the secondary-CPU startup path -- so an accumulated workload is not a necessary condition.

### Expected Behavior

The utility VM should not kernel-panic on an idle host, and after any VM re-creation the published container ports should become reachable from the host again.

### Actual Behavior

Two separate problems. The first is the panic. The second is that recovery is *partially* successful in a way that health checks do not detect.

#### 1. Recurring guest kernel panics

Five `Microsoft-Windows-Hyper-V-Worker-Admin` event **18590** entries, all with `ErrorCode0..4 = 0x0`, each followed by event **18515** (guest-initiated reset). The crash sites are unrelated to each other:

| # | When (local) | Guest uptime | Panic | Last reported RIP |
|---|---|---|---|---|
| 1 | 2026-07-31 11:22:04 | 0 s (0 h) | `Kernel panic - not syncing: Fatal exception` | `asm_exc_invalid_op+0x2/0x30` |
| 2 | 2026-07-31 20:52:33 | 34214 s (9.5 h) | `Kernel panic - not syncing: Fatal exception` | `asm_exc_invalid_op+0x0/0x30` |
| 3 | 2026-08-01 02:36:12 | 13257 s (3.68 h) | `Kernel panic - not syncing: Fatal exception in interrupt` | `vprintk_emit+0x9/0x290` |
| 4 | 2026-08-02 07:15:26 | 103136 s (28.65 h) | `Kernel panic - not syncing: Fatal exception in interrupt` | `skb_clone_tx_timestamp+0x0/0x110` |
| 5 | 2026-08-03 22:12:42 | 140216 s (38.95 h) | `Kernel panic - not syncing: Fatal exception` | `asm_exc_invalid_op+0x2/0x30` |

The reliable (non-`?`) frames differ completely between occurrences:

- **#1** and **#5**: CPU idle path only (`arch_cpu_idle <- default_idle_call <- do_idle <- cpu_startup_entry`); #1 via `start_secondary`, #5 via `rest_init <- start_kernel`.
- **#3**: crashed on the **double-fault stack** (``), with `handle_stack_overflow` / `exc_double_fault` / `vprintk_emit` nearby -- i.e. the kernel overflowed its stack while printing an earlier trace.
- **#4**: network TX from a timer softirq -- `irq_exit_rcu <- handle_softirqs <- run_timer_softirq <- __run_timers <- call_timer_fn <- neigh_timer_handler <- neigh_probe <- arp_solicit <- arp_send_dst <- arp_xmit <- __dev_queue_xmit <- dev_hard_start_xmit`, entered via `sysvec_hyperv_stimer0`.

`Modules linked in` is identical in all five and contains only the standard Docker/iptables set -- **no out-of-tree modules**.

#### 2. Published ports stay broken after VM re-creation

After the VM is re-created:

- `docker ps` reports the containers `Up` and `healthy`;
- the container health checks pass, because they run **inside** the containers;
- but the **published ports do not answer from the host**;
- HNS endpoints are torn down and re-created during the incident window.

From an operations standpoint this is the worst failure mode: every health indicator says OK while the service is unreachable. The only mitigation we found is restarting the containers, which restores host-side port publishing.

One detail for anyone trying to reproduce: on Windows, `localhost` resolves `::1` before `127.0.0.1`. On this machine `wslrelay` listens on `[::1]` and the Docker backend on `0.0.0.0`. After the incident the two paths diverge, so **probing `localhost` alone can produce a false positive** -- IPv4 and IPv6 must be probed separately.

### Diagnostic Logs

#### Classification

```text
Confirmed:
- WSL2 guest kernel panic
- guest-initiated reset (Hyper-V event 18515)
- five recurrences
- Docker engine responsive immediately before the panic
- host did not reboot
- Docker Desktop process did not restart

Observed secondary effect:
- published ports sometimes fail after guest re-creation
- containers return running/healthy
- container restart restores accessibility

Unknown:
- root cause of the kernel fatal exception
```

We are explicitly **not** claiming memory pressure, `get_page_from_freelist`, HNS failure, IPv6 failure, or Docker as the cause. Frames prefixed with `?` are stack-scan noise and are not treated as a call path.

#### Evidence that the host and Docker Desktop did not restart

```text
host last boot : 2026-07-31 22:54:06 (uptime 87.6 h at time of writing)
Docker Desktop pid 2532 started 2026-07-31 22:55:24
Docker Desktop pid 2824 started 2026-07-31 22:55:24
Docker Desktop pid 12372 started 2026-07-31 22:55:00
com.docker.backend pid 12736 started 2026-07-31 22:55:02
Docker Desktop pid 13008 started 2026-07-31 22:55:29
com.docker.backend pid 13028 started 2026-07-31 22:55:04
Docker Desktop pid 13072 started 2026-07-31 22:55:10
Docker Desktop pid 14188 started 2026-07-31 22:55:19
vmmemWSL pid 9272 started 2026-08-03 22:12:55 <-- re-created after occurrence #5
```

The host has been up continuously across occurrences #3, #4 and #5 (occurrences #1 and #2 fall in the previous boot session). Every Docker Desktop process dates from that same boot and has never restarted. The guest uptimes corroborate the chain exactly: #3 panicked 3.68 h after the host booted; #4's 28.65 h uptime places its VM creation at #3's panic; #5's 38.95 h places its VM creation at #4's panic; and the current `vmmemWSL` started 13 s after #5.

#### Docker engine was responsive ~2 s before the panic

Last `apiproxy` request served, from `init.log` (UTC), immediately before occurrence #5 at `01:12:42Z`, and the first line from the newly booted guest:

```text
{"component":"apiproxy","level":"info","msg":">> GET /networks/","time":"2026-08-04T01:12:40.795044777Z","user_agent":"DockerDesktopUI"}
{"component":"apiproxy","level":"info","msg":"<< GET /networks/","time":"2026-08-04T01:12:40.797006065Z","user_agent":"DockerDesktopUI"}
*** guest kernel panic at 01:12:42Z, guest-initiated reset ***
{"component":"dns.leases","level":"info","msg":"eBPF loaded","time":"2026-08-04T01:13:01.641308055Z"}
```

The engine served requests up to 1.2 s before the panic; the gap to the new guest is about 21 s.

#### Full guest messages

**Note on truncation:** the Hyper-V event's `Guest message` field appears to contain only the **tail** of the panic output. The head -- which would carry the `kernel BUG at ...` / `Oops:` / `CPU: n ... Comm:` lines -- is not present in the event. This matters for interpretation, so the messages are pasted verbatim rather than summarised.

Occurrence #5 -- 18590, full guest message

```text
[140216.480816] ? asm_exc_invalid_op+0x2/0x30
[140216.481684] ? asm_exc_invalid_op+0x2/0x30
[140216.482571] ? asm_exc_invalid_op+0x2/0x30
[140216.483233] ? asm_exc_invalid_op+0x2/0x30
[140216.483910] ? get_page_from_freelist+0x16e7/0x18b0
[140216.486161] ? asm_exc_invalid_op+0x2/0x30
[140216.486766] ? asm_exc_invalid_op+0x2/0x30
[140216.487497] ? asm_exc_invalid_op+0x2/0x30
[140216.488079] ? asm_exc_invalid_op+0x2/0x30
[140216.488697] ? asm_exc_invalid_op+0x2/0x30
[140216.489289] ? asm_exc_invalid_op+0x2/0x30
[140216.489865] ? asm_exc_invalid_op+0x2/0x30
[140216.490498] ? get_page_from_freelist+0x16e7/0x18b0
[140216.491376] ? asm_exc_invalid_op+0x2/0x30
[140216.491993] ? asm_exc_invalid_op+0x2/0x30
[140216.492612] ? asm_exc_invalid_op+0x2/0x30
[140216.493269] ? asm_exc_invalid_op+0x2/0x30
[140216.493897] ? asm_exc_invalid_op+0x2/0x30
[140216.494521] ? asm_exc_invalid_op+0x2/0x30
[140216.495263] ? asm_exc_invalid_op+0x2/0x30
[140216.495914] ? asm_exc_invalid_op+0x2/0x30
[140216.496558] ? asm_exc_invalid_op+0x2/0x30
[140216.497165] ? asm_exc_invalid_op+0x2/0x30
[140216.497857] ? asm_exc_invalid_op+0x2/0x30
[140216.498618] ? asm_exc_invalid_op+0x2/0x30
[140216.499209] ? asm_exc_invalid_op+0x2/0x30
[140216.499916] ? asm_exc_invalid_op+0x2/0x30
[140216.500567] ? hv_send_ipi+0x1a/0x40
[140216.502152] ? asm_exc_invalid_op+0x2/0x30
[140216.502859] ? __smp_call_single_queue+0xd3/0x120
[140216.504898] ? asm_exc_invalid_op+0x2/0x30
[140216.505516] ? asm_exc_invalid_op+0x2/0x30
[140216.506146] ? asm_exc_invalid_op+0x2/0x30
[140216.506767] ? asm_exc_invalid_op+0x2/0x30
[140216.507393] ? asm_exc_invalid_op+0x2/0x30
[140216.507996] ? asm_exc_invalid_op+0x2/0x30
[140216.508551] ? asm_exc_invalid_op+0x2/0x30
[140216.509179] ? asm_exc_invalid_op+0x2/0x30
[140216.509752] ? asm_exc_invalid_op+0x2/0x30
[140216.510288] ? asm_exc_invalid_op+0x2/0x30
[140216.510883] ? __schedule+0x54e/0xc20
[140216.511785] ? asm_sysvec_hyperv_reenlightenment+0x30/0x30
[140216.512455] ? sched_clock+0x14/0x30
[140216.513138] ? pv_native_safe_halt+0xf/0x20
[140216.513853] ? ct_kernel_exit.constprop.0+0x77/0x90
[140216.514571] ? default_idle+0xd/0x20
[140216.515150] arch_cpu_idle+0xd/0x20
[140216.515828] default_idle_call+0x33/0x100
[140216.516413] do_idle+0x24d/0x280
[140216.517980] cpu_startup_entry+0x2d/0x30
[140216.518535] rest_init+0xd0/0xd0
[140216.519053] start_kernel+0x5e8/0x850
[140216.520774] x86_64_start_reservations+0x25/0x40
[140216.521649] x86_64_start_kernel+0xd4/0xe0
[140216.522310] common_startup_64+0x13e/0x141
[140216.523061]
[140216.523380] Modules linked in: nf_conntrack_netlink xt_nat xt_conntrack xt_MASQUERADE xfrm_user xfrm_algo xt_set ip_set xt_addrtype ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 nft_compat sunrpc isofs br_netfilter bridge stp llc ip_tables tun
[140216.529590] ---[ end trace 0000000000000000 ]---
[140216.531672] RIP: 0010:asm_exc_invalid_op+0x2/0x30
[140216.532469] Code: e8 f3 0b 00 00 48 89 c4 48 8d 6c 24 01 48 89 e7 48 8b 74 24 78 48 c7 44 24 78 ff ff ff ff e8 25 6c 39 01 e9 10 0d 00 00 f3 0f <1e> fa 0f 01 ca fc 6a ff e8 c1 0b 00 00 48 89 c4 48 8d 6c 24 01 48
[140216.535088] RSP: 0018:ffffffff93403018 EFLAGS: 00010052
[140216.535844] RAX: ffff8b5baf1c7000 RBX: 0000000000000000 RCX: 0000000000000000
[140216.537093] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000002fc5988c
[140216.538226] RBP: ffffffff93403e30 R08: 0000000000000000 R09: 0000000000000001
[140216.539522] R10: ffffffff93471860 R11: 0000000000000001 R12: ffffffff9340e940
[140216.540653] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff9340e040
[140216.541876] FS: 0000000000000000(0000) GS:ffff8b5baf1c7000(0000) knlGS:0000000000000000
[140216.543000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[140216.544036] CR2: 0000777f90000020 CR3: 000000003238d000 CR4: 0000000000350ef0
[140216.545043] Kernel panic - not syncing: Fatal exception
[140216.547866] Kernel Offset: 0x10000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
```

Occurrence #4 -- 18590, full guest message (most complete call trace)

```text
[103136.453238] Call Trace:
[103136.453705]
[103136.454024] ? veth_xmit+0x75/0x340
[103136.454474] ? sk_filter_trim_cap+0x130/0x380
[103136.455062] dev_hard_start_xmit+0x69/0x1d0
[103136.455657] __dev_queue_xmit+0xaab/0xfb0
[103136.456101] ? kmem_cache_alloc_node_noprof+0x141/0x580
[103136.456669] ? kmalloc_reserve+0x99/0x100
[103136.457074] ? __alloc_skb+0xd9/0x1a0
[103136.457484] arp_xmit+0x44/0xd0
[103136.457885] ? arp_create+0x163/0x270
[103136.458318] arp_send_dst+0x7f/0xa0
[103136.458752] arp_solicit+0xf5/0x2c0
[103136.459195] ? _raw_spin_unlock_irqrestore+0x12/0x40
[103136.459788] neigh_probe+0x57/0x70
[103136.460214] neigh_timer_handler+0x9f/0x370
[103136.460786] ? __pfx_neigh_timer_handler+0x10/0x10
[103136.461358] call_timer_fn+0x2f/0x130
[103136.461786] ? __pfx_neigh_timer_handler+0x10/0x10
[103136.462358] __run_timers+0x1db/0x270
[103136.462870] ? hv_ce_set_next_event+0x2b/0x40
[103136.463476] ? clockevents_program_event+0xa4/0x110
[103136.464048] run_timer_softirq+0x7a/0xe0
[103136.464512] handle_softirqs+0xd5/0x2b0
[103136.464954] __irq_exit_rcu+0x96/0xc0
[103136.465408] irq_exit_rcu+0x12/0x20
[103136.466065] sysvec_hyperv_stimer0+0x7f/0xa0
[103136.466905]
[103136.467297]
[103136.467702] asm_sysvec_hyperv_stimer0+0x1f/0x30
[103136.468394] RIP: 0010:pv_native_safe_halt+0xf/0x20
[103136.469183] Code: 22 df c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d f5 15 07 00 fb f4 bc 0c 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[103136.471876] RSP: 0018:ffffffffb4403e28 EFLAGS: 00000256
[103136.472449] RAX: ffff8b828e1c7000 RBX: 0000000000000000 RCX: 0000000000000001
[103136.473268] RDX: 0000000000000000 RSI: 0000000000000087 RDI: 000000001f23081c
[103136.474089] RBP: ffffffffb4403e30 R08: 0148342c12cbbd17 R09: 0000000000000007
[103136.475156] R10: 0000000000000001 R11: 0000000000000021 R12: ffffffffb440e940
[103136.476130] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffb440e040
[103136.477124] ? ct_kernel_exit.constprop.0+0x77/0x90
[103136.477830] ? default_idle+0xd/0x20
[103136.478258] arch_cpu_idle+0xd/0x20
[103136.478665] default_idle_call+0x33/0x100
[103136.479055] do_idle+0x24d/0x280
[103136.479458] cpu_startup_entry+0x2d/0x30
[103136.479871] rest_init+0xd0/0xd0
[103136.480277] start_kernel+0x5e8/0x850
[103136.480676] x86_64_start_reservations+0x25/0x40
[103136.481208] x86_64_start_kernel+0xd4/0xe0
[103136.481699] common_startup_64+0x13e/0x141
[103136.482555]
[103136.482854] Modules linked in: nf_conntrack_netlink xt_nat xt_conntrack xt_MASQUERADE xfrm_user xfrm_algo xt_set ip_set xt_addrtype ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 nft_compat sunrpc isofs br_netfilter bridge stp llc ip_tables tun
[103136.485104] ---[ end trace 0000000000000000 ]---
[103136.489391] RIP: 0010:skb_clone_tx_timestamp+0x0/0x110
[103136.490558] Code: 31 c0 41 5c 5d c3 cc cc cc cc 31 c0 c3 cc cc cc cc 0f 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1e fa 0f 1f 44 00 00 48 83 7f 18 00 0f 84 f4 00 00 00 55 48
[103136.497753] RSP: 0018:ffffd36d00003b98 EFLAGS: 00010246
[103136.498649] RAX: 0000000000000000 RBX: ffff8b819f589000 RCX: ffff8b819f589198
[103136.500688] RDX: 000000000000002a RSI: 0000000000000000 RDI: ffff8b8142a46100
[103136.502058] RBP: ffffd36d00003bd8 R08: 00000000cc504fe1 R09: 000000000000001c
[103136.503648] R10: ffff8b81acd858c0 R11: 0000000000000071 R12: ffff8b819f58e000
[103136.505310] R13: ffff8b819f588000 R14: 0000000000000000 R15: ffff8b8142a46100
[103136.506953] FS: 0000000000000000(0000) GS:ffff8b828e1c7000(0000) knlGS:0000000000000000
[103136.508692] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[103136.510889] CR2: 0000773301050170 CR3: 0000000000500000 CR4: 0000000000350ef0
[103136.512482] Kernel panic - not syncing: Fatal exception in interrupt
[103136.514144] Kernel Offset: 0x31000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
```

Occurrence #3 -- 18590, full guest message (double fault / stack overflow)

```text
[13257.252974] ? asm_exc_page_fault+0x1/0x30
[13257.252976] ? asm_exc_page_fault+0x1/0x30
[13257.252978] ? asm_exc_page_fault+0x1/0x30
[13257.252980] ? asm_exc_page_fault+0x1/0x30
[13257.252982] ? asm_exc_page_fault+0x1/0x30
[13257.252984] ? asm_exc_page_fault+0x1/0x30
[13257.252986] ? asm_exc_page_fault+0x1/0x30
[13257.252988] ? asm_exc_page_fault+0x1/0x30
[13257.252990] ? asm_exc_page_fault+0x1/0x30
[13257.252992] ? asm_exc_page_fault+0x1/0x30
[13257.252994] ? asm_exc_page_fault+0x1/0x30
[13257.252996] ? asm_exc_page_fault+0x1/0x30
[13257.252998] ? asm_exc_page_fault+0x1/0x30
[13257.253000] ? asm_exc_page_fault+0x1/0x30
[13257.253001] ? asm_exc_page_fault+0x1/0x30
[13257.253004] ? vsnprintf+0x127/0x570
[13257.253210] ? sprintf+0x59/0x80
[13257.253214] ? vsnprintf+0x127/0x570
[13257.253217] ? vsnprintf+0x127/0x570
[13257.253220] ? sprintf+0x59/0x80
[13257.253223] ? __sprint_symbol.isra.0+0x9d/0x100
[13257.253346] ? symbol_string+0x98/0x130
[13257.253350] ? symbol_string+0x98/0x130
[13257.253353] ? symbol_string+0x98/0x130
[13257.253356] ? asm_exc_page_fault+0x1/0x30
[13257.253358] ? asm_exc_page_fault+0x1/0x30
[13257.253434] ? asm_exc_page_fault+0x1/0x30
[13257.253436] ? asm_exc_page_fault+0x1/0x30
[13257.253438] ? desc_read_finalized_seq+0x33/0x90
[13257.253443] ? _prb_read_valid+0x251/0x2e0
[13257.253446] ? desc_read_finalized_seq+0x33/0x90
[13257.253448] ? desc_read_finalized_seq+0x33/0x90
[13257.253451] ? _prb_read_valid+0x251/0x2e0
[13257.253454] ? desc_read_finalized_seq+0x33/0x90
[13257.253456] ? _prb_read_valid+0x251/0x2e0
[13257.253460] ? desc_update_last_finalized+0x4c/0x90
[13257.253463] ? prb_final_commit+0x23/0x30
[13257.253465] ? vprintk_store+0x4fb/0x520
[13257.253470] ? __wake_up_klogd+0x52/0x80
[13257.253473] ? vprintk_emit+0x130/0x290
[13257.253477] ? vprintk_emit+0x130/0x290
[13257.253480] ? vprintk_emit+0x130/0x290
[13257.253483] ? vprintk_default+0x21/0x30
[13257.253486] ? vprintk+0x1c/0x50
[13257.253488] ? is_bpf_text_address+0x26/0x40
[13257.253987] ? kernel_text_address+0x11d/0x130
[13257.254155] ? asm_exc_page_fault+0x2b/0x30
[13257.254160] ? __kernel_text_address+0x16/0x50
[13257.254162] ? __kernel_text_address+0x16/0x50
[13257.254164] ? __show_trace_log_lvl+0x1ca/0x400
[13257.254393] ? asm_exc_page_fault+0x1/0x30
[13257.254397] ? show_regs+0x68/0x80
[13257.254400] ? die+0x3b/0x90
[13257.254403] ? handle_stack_overflow+0x52/0x70
[13257.254444] ? exc_double_fault+0xfd/0x180
[13257.254540] ? asm_exc_double_fault+0x23/0x30
[13257.254545] ? vprintk_emit+0x9/0x290
[13257.254551]
[13257.254553] Modules linked in: nf_conntrack_netlink xt_nat xt_conntrack xt_MASQUERADE xfrm_user xfrm_algo xt_set ip_set xt_addrtype ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 nft_compat sunrpc isofs br_netfilter bridge stp llc ip_tables tun
[13257.255571] ---[ end trace 0000000000000000 ]---
[13257.255676] RIP: 0010:vprintk_emit+0x9/0x290
[13257.255686] Code: 02 74 91 eb f2 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 <55> 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 89 7d c4 65 48
[13257.255689] RSP: 0018:fffffe5fea122000 EFLAGS: 00010046
[13257.255692] RAX: fffffe5fea122048 RBX: fffffe5fea122188 RCX: ffffffffaf9cdbf8
[13257.255694] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: 0000000000000000
[13257.255696] RBP: fffffe5fea122008 R08: fffffe5fea122028 R09: 0000000000000000
[13257.255697] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
[13257.255699] R13: 0000000000000000 R14: 0000000000000046 R15: 0000000000000000
[13257.255701] FS: 0000000000000000(0000) GS:ffff8e2e92347000(0000) knlGS:0000000000000000
[13257.255703] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[13257.255705] CR2: fffffe5fea121ff8 CR3: 00000000724b1000 CR4: 0000000000350ef0
[13257.255711] Kernel panic - not syncing: Fatal exception in interrupt
[13257.256237] Kernel Offset: 0x2d000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
```

Event 18515 (guest-initiated reset) following occurrence #5

```text
'' was shut down for a reset initiated by the guest operating system. (Virtual machine ID )
```

#### An observation we cannot explain

In occurrences #1 and #5 the last reported RIP is `asm_exc_invalid_op+0x2/0x30`, and the reported code bytes are:

```text
f3 0f <1e> fa # endbr64, with the fault marked 2 bytes into the instruction
```

RIP pointing 2 bytes into an `endbr64` at an exception entry stub is not an instruction boundary. We do not know whether this reflects a genuine bad indirect branch/return, or is an artefact of the truncated event output or of a nested fault during oops handling. Flagging it as an observation only.

#### Possibly related

- #41195 -- same kernel (`6.18.33.2-2`) and same WSL (`2.7.11`), `list_add` corruption panic in `kswapd0`. That report requires a memory-intensive workload to trigger; **our host is idle and has no `.wslconfig`**, and one of our occurrences happened at 0 s guest uptime. If the underlying defect is the same, that is a useful datapoint: it reproduces without memory pressure.
- #40989 -- WSL2 kernel panic in the Hyper-V `netvsc` receive path. Our occurrence #4 is in the network **TX** path from a timer softirq, so it is not the same signature, but it is adjacent.

#### Additional data

A passive host-side telemetry ring buffer (30 s samples, host-side only -- no `wsl.exe`/`docker.exe` calls) is now running so that the **pre-panic** window is captured next time. The existing forensic capture only ran *after* `/ready` failed, by which point the VM had already been re-created, so all its host measurements describe the new VM.

The official WSL diagnostics kit has been archived locally at a fixed revision. Because the failure is intermittent we have not been able to run `collect-wsl-logs.ps1` across an occurrence yet; a full `logs.etl` capture will be attached as a comment if the panic recurs.

Everything above is sanitised: hostnames, usernames, IP addresses, file paths, certificates and internal identifiers have been removed.