Skip to content

Displays do not go to sleep when WSLg is enabled after unlocking Windows lock screen using modifier key (such as left-ctrl) #380

Closed

Description

@desultory-zz

Environment

Windows build number:  Version 10.0.22000.100
Your Distribution version:  Gentoo 17.1 Hardened
Your WSLg version:  1.0.24

Steps to reproduce

Just have WSLg running

C:\WINDOWS\system32>powercfg /requests
DISPLAY:
[PROCESS] \Device\HarddiskVolume4\Windows\System32\mstsc.exe
RAIL Power Request

Expected behavior

Screen should go to sleep after 15 minutes

Actual behavior

Display never goes to sleep when WSL is running

Activity

  1. hideyukn88 commented on Jul 26, 2021

    @hideyukn88
    Contributor

    Zen (@desultory), thanks for reporting the issue. Do you run any Linux GUI application ? and if so, could that application be updating screen periodically? Please refer #172. thanks!

  2. desultory-zz commented on Jul 26, 2021

    @desultory-zz
    Author

    This happens even if I just open WSL session with no GUI. I only installed tigerVNC to test wslg, nothing else.

  3. hideyukn88 commented on Jul 29, 2021

    @hideyukn88
    Contributor

    Zen (@desultory) , would you please take a look /mnt/wslg/weston.log and see if you have any log with "rdp_rail_idle_handler is called" or "rdp_rail_wake_handler is called" ? thanks!

  4. desultory-zz commented on Jul 30, 2021

    @desultory-zz
    Author

    Hideyuki Nagase (@hideyukn88)

    1700 is when I booted, 0200 is when I had a VNC session

    This is that file, grepped for "rail" with lines above and below

                   https://wayland.freedesktop.org
                   Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
                   Build: 9.0.0-30-ged4f3bbb
    [17:33:34.242] Command line: /usr/bin/weston --backend=rdp-backend.so --xwayland --shell=rdprail-shell.so --logger-scopes=log,rdp-backend,rdprail-shell --log=/mnt/wslg/weston.log
    [17:33:34.242] OS: Linux, 5.10.43.3-microsoft-standard-WSL2, #1 SMP Wed Jun 16 23:47:55 UTC 2021, x86_64
    [17:33:34.243] Using config file '/home/wslg/.config/weston.ini'
    [17:33:34.244] Output repaint window is 7 ms maximum.
    --
    [17:33:34.256] RDP backend: Environment dump - end
    [17:33:34.256] Using external fd for incoming connections: 3
    [17:33:34.256] Default head is being added
    [17:33:34.256] Registered plugin API 'weston_rdprail_api_v1' of size 56
    [17:33:34.256] RDPAPPLIST_MODULEDIR is set to /usr/lib/rdpapplist
    [17:33:34.258] RDP backend: use_rdpapplist = 1
    [17:33:34.267] RDP backend: use_gfxredir = 1
    --
                   screen capture uses y-flip: no
                   presentation clock: CLOCK_MONOTONIC_RAW, id 4
                   presentation clock resolution: 0.000000001 s
    [17:33:34.270] Loading module '/usr/lib/weston/rdprail-shell.so'
    [17:33:34.271] RDPRAIL-shell: WESTON_RDPRAIL_SHELL_DEBUG_LEVEL: 3.
    Date: 2021-07-29 CDT
    [17:33:34.271] wet_shell_init: distro name Gentoo (6)
    --
    [17:33:34.274] WSL2_DEFAULT_APP_OVERLAY_ICON:/usr/share/icons/wsl/linux.png
    [17:33:34.274] WESTON_RDPRAIL_SHELL_DISABLE_BLEND_OVERLAY_ICON_TASKBAR:1
    [17:33:34.274] WESTON_RDPRAIL_SHELL_DISABLE_BLEND_OVERLAY_ICON_APPLIST:1
    [17:33:34.274] rdp_rail_shell_initialize_notify: shell: distro name: Gentoo
    [17:33:34.275] app_list_monitor_thread: running in system-distro with user-distro: Gentoo
    [17:33:34.275] app_list_monitor_thread: open(/proc/self/ns/mnt)
    [17:33:34.275] app_list_monitor_thread: open(/proc/2/ns/mnt)
    --
    [17:33:35.061] Translated workarea:(1920,0)-(3840,1032) at rdp-0:(1920,0)-(3840,1080)
    [17:33:35.061] Client ExecOrder program terminated
    [17:33:35.061] dummy-entry exited with status 255
    [17:33:35.061] rdp_rail_notify_app_list(): rdp_peer 0x56148b049130
    [17:33:35.061]     inSync: 1
    [17:33:35.061]     syncStart: 1
    [17:33:35.061]     syncEnd: 0
    --
    [17:33:35.061]     appDesc: FLUID (Gentoo)
    [17:33:35.061]     appIcon: 0x7fb758002070
    [17:33:35.061]     appProvider: (null)
    [17:33:35.062] rdp_rail_notify_app_list(): rdp_peer 0x56148b049130
    [17:33:35.062]     inSync: 1
    [17:33:35.062]     syncStart: 0
    [17:33:35.062]     syncEnd: 1
    --
    [17:33:35.141] Audio sink thread: Listening for audio connection.
    [17:33:39.292] Audio sink thread: connection successful on socket (82).
    [17:33:39.292] RDP Sink version (1 - 1)
    [17:38:35.045] rdp_rail_idle_handler is called on peerCtx:0x56148b049130
    [21:22:28.204] rdp_rail_wake_handler is called on peerCtx:0x56148b049130
    [21:27:28.204] rdp_rail_idle_handler is called on peerCtx:0x56148b049130
    Date: 2021-07-30 CDT
    [00:22:19.154] Client: DisplayLayoutChange: monitor count:0x3
    [00:22:19.154] Client: DisplayControl: monitor count:0x3
    --
    [02:03:30.967] xfixes selection notify event: owner 2097153
    [02:03:30.967] our window, skipping
    [02:03:50.556] Didn't find output containing (-31, -12), return default
    [02:03:50.584] rdp_rail_wake_handler is called on peerCtx:0x56148b049130
    [02:03:50.694] Client: ClientGetAppidReq: pid:156 appId:Vncviewer
    [02:03:52.583] !!!cursor role is added after creation - WindowId:0x1
    [02:04:10.947] Didn't find output containing (-31, -12), return default
    
  5. gordallott commented on Aug 24, 2021

    @gordallott

    Also have this issue, powercfg -requests in an elevated powershell prompt gives

    PS C:\WINDOWS\system32> powercfg -requests
    DISPLAY:
    [PROCESS] \Device\HarddiskVolume4\Windows\System32\mstsc.exe
    RAIL Power Request
    
    SYSTEM:
    [PROCESS] \Device\HarddiskVolume4\Windows\System32\mstsc.exe
    RAIL Power Request
    
    AWAYMODE:
    None.
    
    EXECUTION:
    None.
    
    PERFBOOST:
    None.
    
    ACTIVELOCKSCREEN:
    None.
    

    zero wslg windows open

  6. desultory-zz commented on Aug 24, 2021

    @desultory-zz
    Author

    Updating my kernel seemed to fix it temporarily, but I noticed that if I ever opened a WSLg window, it would not go to sleep normally until I rebooted the whole system. I have not used WSLg since then but at least it goes to sleep when running normally through the terminal.

  7. hideyukn88 commented on Aug 26, 2021

    @hideyukn88
    Contributor

    Hi Zen (@desultory), thanks for providing more info. Do you observe this issue with any WSLg app? for example, if you launch 'xclock', then close 'xclock' (so no more WSLg app is running on desktop), then display never turned off? Or is this only happens when ' tigerVNC' is ever used? thanks!

  8. gordallott commented on Sep 6, 2021

    @gordallott

    to note, this happens with any wslg app, opening xclock and closing xclock keeps the display open, as my comment pointed out, mstsc.exe keeps the remote desktop connection going which keeps the system from sleeping

  9. ebroder commented on Oct 9, 2021

    @ebroder

    I've started seeing similar behavior within the last week or so. (If it seems like this is a different bug, let me know and I'd be happy to file separately). My computer seems to not go to sleep if WSL is running at all, even if I've never started a WSLg app. If I run wsl --shutdown, then everything seems to get cleaned up. I dumped logs at https://gist.github.com/ebroder/7143b922985281cd817a535d938cab31 but can grab more if helpful.

  10. jclark commented on Oct 9, 2021

    @jclark

    I just installed Windows 11 and then WSLg, and also found that my computer no longer sleeps. Disabling WSLg by putting

    [wsl2]
    guiApplications=false
    

    in .wslconfig got my computer sleeping again (but no WSLg of course).

  11. vladimir-novoseltsev commented on Oct 9, 2021

    @vladimir-novoseltsev

    For me just starting WSL is not enough to trigger this. I had to run some app which would use WSLg, then until WSL is explicitly shutdown displays would not turn off.

  12. desultory-zz commented on Oct 31, 2021

    @desultory-zz
    Author

    Hi Zen (@desultory), thanks for providing more info. Do you observe this issue with any WSLg app? for example, if you launch 'xclock', then close 'xclock' (so no more WSLg app is running on desktop), then display never turned off? Or is this only happens when ' tigerVNC' is ever used? thanks!

    most recently I noticed it keeping my computer awake when using firefox. I was using it with Selenium for what it's worth and when I closed that program it seemed to sleep properly.

  13. 51 remaining items

  14. wowczarczyk commented on Jan 6, 2023

    @wowczarczyk

    I also use DD, but I am uncertain if it is the root cause. For me killing it does not make the msrdc power requests go away.

  15. hideyukn88 commented on Jan 7, 2023

    @hideyukn88
    Contributor

    Justin Bowes (@justinbowes), Wojciech Owczarczyk (@wowczarczyk), thanks for info, what's happening here might be that WSLg/msrdc takes power reference regardless of any GUI application presence at WSL start up, and the reference goes away after 5 mins if no GUI application starts up. but within that 5 mins, docker might startup new instance of WSL, so it extends another 5 mins, and this can repeat while docker is running, thus power reference never goes away. You can check the uniqueness of WSL instance by hcsdiag list command from Windows's command prompt. Would you please check if the GUID shows for WSL is changing while your docker scenario is running? thanks!

    C:\>hcsdiag list
    276EB821-E97C-46A7-9FA7-763BF6160D6A
        VM,                         Running, 276EB821-E97C-46A7-9FA7-763BF6160D6A, WSL
    
  16. wowczarczyk commented on Jan 7, 2023

    @wowczarczyk

    I am always getting the same GUID, unless I kill wsl with wsl --shutdown

  17. justinbowes commented on Jan 7, 2023

    @justinbowes

    Hideyuki Nagase (@hideyukn88) This sounded like a reasonable theory. Based on your description, I selected a sample interval of 6 minutes. Like Wojciech Owczarczyk (@wowczarczyk), I find that the same GUID is returned.

    PS C:\Users\justi> date; hcsdiag list; sleep 360; date; hcsdiag list
    
    Saturday, January 7, 2023 10:27:21 AM
    80CE200B-FED7-410A-9842-E1F02D130B95
        VM,                         Running, 80CE200B-FED7-410A-9842-E1F02D130B95, WSL
    
    Saturday, January 7, 2023 10:33:21 AM
    80CE200B-FED7-410A-9842-E1F02D130B95
        VM,                         Running, 80CE200B-FED7-410A-9842-E1F02D130B95, WSL
    

    I made a trival change to the Docker Desktop configuration (enabling buildkit) to see if the GUID would change in a scenario where Docker must restart the backend, but the GUID remains the same even here.

    I should also mention that there are actually two active requests, and both seem to be due to Docker Desktop.

    PS C:\Users\justi> powercfg /requests
    DISPLAY:
    [PROCESS] \Device\HarddiskVolume9\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe
    RAIL Power Request
    [PROCESS] \Device\HarddiskVolume9\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe
    RAIL Power Request
    
    SYSTEM:
    [PROCESS] \Device\HarddiskVolume9\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe
    RAIL Power Request
    [PROCESS] \Device\HarddiskVolume9\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe
    RAIL Power Request
    

    On the subject of intended Docker behavior (which may be off topic for this thread), I do not have any running containers in this Docker context, so there is no reason to intentionally suppress sleep to maintain access to a service container.

    PS C:\Users\justi> docker ps
    CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
    PS C:\Users\justi>
    

    EDIT: After keeping Docker Desktop open for a long time, shutting it down decreases the number of msrdc.exe requests in both DISPLAY and SYSTEM by 1 or more, but does not necessarily remove all requests. Is it possible to leak such requests?

  18. justinbowes commented on Jan 7, 2023

    @justinbowes

    My issue is no longer aligned with original issue. My intent was to post a workaround in case the original fix did not apply. Do you want me to create a new issue?

  19. hideyukn88 commented on Jan 10, 2023

    @hideyukn88
    Contributor

    Justin Bowes (@justinbowes), Wojciech Owczarczyk (@wowczarczyk), thanks for checking. If GUID remains same, then my theory is not what's happening at your end. At this point, collecting core dump of weston process following #380 (comment) would greatly help. Also as backup, I'm working on the change to weston compositor to not take power reference until any GUI application start up, microsoft/weston-mirror#128. This allows WSL users who only works on console based applications won't be bothered by this, thanks!

  20. orionlee commented on Jan 26, 2023

    @orionlee

    I'd like to report some similar incident that have been happening intermittently:

    • In the morning, I found the machine woke up from sleep rather than hibernate.
      (the machine should have hibernated after sleeping for 1 hour in my configuration.)
    • When I ran powercfg, it showed msrdc.exe held display RAIL Power Request, similar to what the others had reported.
    • I tried to get the core dump following Displays do not go to sleep when WSLg is enabled after unlocking Windows lock screen using modifier key (such as left-ctrl) #380 (comment), but by the time I got to the wsl --system terminal, msrdc.exe no longer held display.
    • I did not use any Linux GUI app, but I did launch exploerer.exe, notepad, and nodepad2 from WSL shells, but had exited them long before the machine was put to sleep.
    • It happened quite frequent (a few times a week), but not always.

    I used the latest store version of WSL / Ubuntu on Windows 11 Home:

    wsl --version
    
    WSL version: 1.0.3.0
    Kernel version: 5.15.79.1
    WSLg version: 1.0.47
    MSRDC version: 1.2.3575
    Direct3D version: 1.606.4
    DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
    Windows version: 10.0.22621.1105
    
  21. hideyukn88 commented on Jan 26, 2023

    @hideyukn88
    Contributor

    Sam Lee (@orionlee), thanks for reporting the issue and your analysis. Currently when Windows goes to its logon screen (such as after hibernating), the RDP client (such as msrdc.exe) sent certain key sequences to all RDP servers who have active connections, including WSLg, this wakes up WSLg and take power reference (then the reference should be gone after 300 seconds). I think this is what you are seeing. Basically, Linux/WSLg does not need to receive such key sequence since "logon" state is totally independent between Windows and Linux side, so we will consider to not doing that for WSLg, thanks!

  22. orionlee commented on Jan 26, 2023

    @orionlee

    Hideyuki Nagase (@hideyukn88) thanks for your response!
    Could you clarify what you mean by "when Windows goes to its logon screen (such as after hibernating)": do you mean the following sequence of events?

    1. Windows tries to go to hibernate
    2. internally, it means Windows goes to its logon screen
    3. msrdc.exe got woken up and held the display unnecessarily, thus preventing hibernate.

    If so, then the workaround in the interim is what's suggested at #380 (comment)

    powercfg /requestsoverride PROCESS mstsc.exe DISPLAY SYSTEM
    
  23. hideyukn88 commented on Jan 26, 2023

    @hideyukn88
    Contributor

    Sam Lee (@orionlee), what I mean is when Windows's goes to Logon screen, such as by Win+L, or after waking up from sleep or hibernate, msrdc.exe takes power reference regardless usage of WSLg. Would you please run powercfg /SLEEPSTUDY, and see the generated report to see what was the power state before waking up? thanks!

  24. orionlee commented on Jan 26, 2023

    @orionlee

    Hideyuki Nagase (@hideyukn88) I see. So in that case, msrdc.exe holding the display unnecessarily is probably just a red herring, and is likely to be unrelated to the reasons that machine didn't go to hibernate.

    I ran powercfg /SLEEPSTUDY, and found something suspicious but don't know if there is enough to go on.

    When the machine hibernated after extended sleep, the standby entry is marked as "Drain" (entry 16 below). In contrast, when the machine did not hibernate after extended sleep, the standby entry is marked as "Charge" (entry 66 below), even though the machine was not connected to power (the battery drain overnight in the report proved that).
    image
    image

    Details for case the machine did not go to hibernate

    image
    image
    image

    Details for case the machine went to hibernate after extended sleep

    image
    image
    image
    image

  25. daltschu22 commented on Nov 3, 2023

    @daltschu22

    Im on windows 10 22H2 and I still have this issue.

    >wsl --version
    WSL version: 1.2.5.0
    Kernel version: 5.15.90.1
    WSLg version: 1.0.51
    MSRDC version: 1.2.3770
    Direct3D version: 1.608.2-61064218
    DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
    Windows version: 10.0.19045.3448
    

    powercfg /requestsoverride PROCESS mstsc.exe DISPLAY SYSTEM seems to fix but I have to run it every single time I sleep the computer. This is driving me nuts.

  26. antonio-petricca commented on Jun 30, 2024

    @antonio-petricca

    Any news about this issue?

  27. nabeelr commented on Jan 11, 2025

    @nabeelr

    2025 chiming in, I still have this issue too.

  28. javier-au commented on Feb 11, 2025

    @javier-au

    Power rail request disappears a short while after minimizing wsl gui apps.

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions