Skip to content

WSLg: shared-memory virtiofs share returns EIO after host hibernate/resume; all GUI windows become transparent until wsl --shutdown #41903

Open
Open
WSLg: shared-memory virtiofs share returns EIO after host hibernate/resume; all GUI windows become transparent until wsl --shutdown#41903
Labels
wsl2Issue/feature applies to WSL 2

Description

@jozenstar
Arthur Yazhevich (jozenstar)
opened on Oct 13, 2026

Windows Version

Microsoft Windows [Version 10.0.26200.9457]

WSL Version

WSL version: 2.7.0.0 Kernel version: 6.6.114.1-1 WSLg version: 1.0.71 MSRDC version: 1.2.6676 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26100.1-240331-1435.ge-release Windows version: 10.0.26200.9457

Are you using WSL 1, WSL 2, or WSLC?

  • WSL 2
  • WSL 1
  • WSLC

Kernel Version

6.6.114.1-1

Distro Version

Ubuntu 22.04

Other Software

Android Studio (Linux), xeyes for a minimal repro. .wslconfig: networkingMode=mirrored, dnsTunneling=true, autoProxy=true, memory=10GB, swap=8GB, [experimental] autoMemoryReclaim=gradual, sparseVhd=true.

Repro Steps

  1. Start WSL 2 with WSLg; run any GUI app once (works, shared-memory path active, use_gfxredir = 1).
  2. Leave the VM running; hibernate (or long-suspend) the Windows host overnight. In this case: suspend requested via the power API at 22:10, resume ~12 h later at 10:28 (Kernel-Power 42/107).
  3. After resume, launch any Linux GUI app (xeyes, Android Studio).

Expected Behavior

GUI windows render normally after resume, or WSLg recovers the shared-memory path on its own.

Actual Behavior

Every GUI app gets a taskbar entry and a RAIL window in msrdc.exe (title prefixed [WARN:COPY MODE]), but the window is a layered window that never paints, i.e. fully transparent.

In the system distro, /mnt/shared_memory (virtiofs tag wslg, dax=always) returns EIO on every operation, including stat of the mount root:

# wsl --system -u root -- ls -la /mnt/shared_memory
ls: cannot access '/mnt/shared_memory': Input/output error

/mnt/wslg/weston.log logs, for every surface:

[18:34:55.745] rdp_allocate_shared_memory: Failed to open "/mnt/shared_memory/{68f9bcca-57f7-4ea0-abe9-342e6d03bcdb}" with error: Input/output error

Timeline detail: the resume was at 10:28, but the first EIO is at 18:34:55, which was the first window created after the resume (no window surface was allocated in between). So the breakage happens at resume and stays latent until WSLg first touches the share.

The VM itself is fine (vmwp.exe / vmmemWSL running continuously since 4 days earlier; distro shells, VS Code server, 9p drvfs, networking all work). Only the shared-memory device is dead.

Diagnostic Logs

What was checked (host side, Windows)

  • \Sessions\<id>\BaseNamedObjects\WSL\<vm-guid>\wslg object directory exists, is owned by the user, DACL intact, and a test process can successfully create a section in it. wslservice.exe holds open handles to the directory. So the host-side object namespace is healthy.
  • vmwp.exe for the VM is alive, responsive, idle, no WER crash/hang entries for vmwp.exe, wslservice.exe, or msrdc.exe. Hyper-V Worker/Compute/VMMS channels show nothing but the normal NIC reconnect at resume.
  • Hyper-V-Compute-Operational shows the share wired as VirtualMachine/Devices/FlexibleIov/<guid> with "HostingModel":"ExternalRestricted".
  • In the guest: PCI device 1af4:105a (virtio1) is bound to virtiofs, device status 0x0f (DRIVER_OK), mount still present, yet every FUSE op returns EIO.
  • Guest kernel log at the same minute shows repeated misc dxg: dxgk: dxgkio_query_adapter_info: Ioctl failed: -22 from the GPU-PV path, and the host logged WER LiveKernelEvent telemetry buckets (no dump saved, no bugcheck).

Attempted recoveries (none help)

  1. umount -l + remount of /mnt/shared_memory in the system distro: mount succeeds, every open/create still EIO.
  2. Killing the WSLg msrdc.exe: WSLGd respawns it, reconnects, still transparent.
  3. Killing weston: WSLGd respawns it with use_gfxredir = 0 (fallback), but windows still do not paint.
  4. Only wsl --shutdown fixes it, which kills every session in the distro.

Ask

  • Is there any way to re-initialise the WSLg shared-memory (virtiofs/DAX) device in a running VM, short of recreating the VM?
  • Could WSLg detect EIO on the shared-memory share and re-arm it, or at least make the copy-mode fallback actually paint after a resume?

Happy to collect wsl --debug-shell/debug console kernel logs or a WSL log bundle on the next occurrence if that helps.

Activity

  1. github-actions commented on Oct 13, 2026

    @github-actions
    github-actionsbot
    on Oct 13, 2026 – with GitHub Actions
    Contributor

    Logs are required for review from WSL team

    If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
    Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

    How to collect WSL logs

    Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

    Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

    The script will output the path of the log file once done.

    If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

    Once completed please upload the output files to this GitHub issue.

    See Collect WSL logs (recommended method).

    If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

  2. github-actions
    added
    needs-author-feedback
    on Oct 13, 2026

  3. jozenstar commented on Oct 13, 2026

    @jozenstar
    Arthur Yazhevich (jozenstar)
    on Oct 13, 2026
    Author

    Logs collected with the unmodified collect-wsl-logs.ps1 (default profile) from an elevated PowerShell, while the issue was live (VM still the same instance that went through the hibernate/resume; not restarted). Archive WslLogs-2026-10-13_20-14-54.tar.gz is attached in the next comment.

    What was reproduced while the trace was recording (local time 20:15:08–20:15:21):

    # wsl.exe --system -u root -- sh -c 'ls -la /mnt/shared_memory; stat /mnt/shared_memory; touch /mnt/shared_memory/repro-41903'
ls: cannot access '/mnt/shared_memory': Input/output error
stat: cannot statx '/mnt/shared_memory': Input/output error
touch: cannot touch '/mnt/shared_memory/repro-41903': Input/output error

    followed by timeout 10 xeyes in the Ubuntu-22.04 distro (DISPLAY=:0, WAYLAND_DISPLAY=wayland-0): the window appears in the taskbar but is fully transparent.

    Notes that may help triage:

    • wslg/weston.log in the archive contains the original rdp_allocate_shared_memory: Failed to open "/mnt/shared_memory/{guid}" ... Input/output error entries (first at 18:34:55, the first window created after the 10:28 resume). weston was restarted once since then and now runs with use_gfxredir = 0, so new windows no longer log the EIO but still do not paint.
    • In the WPR trace, the WSL providers (Microsoft.Windows.Lxss.Manager / Microsoft.Windows.Subsystem.Lxss) record no event for the failing virtiofs requests; only Plan9 Tgetattr/Rgetattr traffic for drvfs and HNS/VfpExt networking events appear. Guest side: virtio1 (PCI 1af4:105a) is bound to virtiofs, device status 0x0f, mount wslg /mnt/shared_memory virtiofs rw,dax=always still present.
    • The guest kernel log is also full of WSL (<pid> - Relay) ERROR: UtilAcceptVsock:244: Waiting for abnormally long accept(10) for ~10 relay processes, repeating every 60 s since ~14:43 the same day (visible as GuestLog events in the trace). Possibly the same post-resume damage.
    • Host side: \Sessions\<n>\BaseNamedObjects\WSL\<vm-guid>\wslg exists, is owned by the user, and a test process can create sections in it; wslservice.exe holds handles to it; vmwp.exe is healthy. The share is wired as VirtualMachine/Devices/FlexibleIov/<guid> with "HostingModel":"ExternalRestricted".

    Happy to run collect-wsl-logs.ps1 -LogProfile hvsocket or a custom .wprp if a different provider set is needed.

  4. microsoft-github-policy-service
    removed
    needs-author-feedback
    on Oct 13, 2026

  5. OneBlue commented on Oct 13, 2026

    @OneBlue
    Blue (OneBlue)
    on Oct 13, 2026
    Collaborator

    Arthur Yazhevich (@jozenstar): You're using an old version of WSL. Can you see if running wsl --update solves the issue ?

  6. David Bennett (dkbennett)
    added
    wsl2Issue/feature applies to WSL 2
    on Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    wsl2Issue/feature applies to WSL 2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions