You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Displays do not go to sleep when WSLg is enabled after unlocking Windows lock screen using modifier key (such as left-ctrl) #380
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
Reacted by Dominik Madarász, Erik Medina, Evan Broder, Justin Palpant, Justin Pierce, Aravind Nair, Jason Unsworth, Oleg, Dave Barker, Johan Venter and 11 more
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!
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!
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.
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!
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
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.
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.
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.
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
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?
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?
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!
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 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:
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!
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?
Windows tries to go to hibernate
internally, it means Windows goes to its logon screen
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
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!
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).
Details for case the machine did not go to hibernate
Details for case the machine went to hibernate after extended sleep
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.
Activity
hideyukn88 commentedon Jul 26, 2021
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!
desultory-zz commentedon Jul 26, 2021
This happens even if I just open WSL session with no GUI. I only installed tigerVNC to test wslg, nothing else.
hideyukn88 commentedon Jul 29, 2021
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!
desultory-zz commentedon Jul 30, 2021
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
gordallott commentedon Aug 24, 2021
Also have this issue,
powercfg -requestsin an elevated powershell prompt giveszero wslg windows open
desultory-zz commentedon Aug 24, 2021
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.
hideyukn88 commentedon Aug 26, 2021
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!
gordallott commentedon Sep 6, 2021
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
ebroder commentedon Oct 9, 2021
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.jclark commentedon Oct 9, 2021
I just installed Windows 11 and then WSLg, and also found that my computer no longer sleeps. Disabling WSLg by putting
in .wslconfig got my computer sleeping again (but no WSLg of course).
vladimir-novoseltsev commentedon Oct 9, 2021
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.
desultory-zz commentedon Oct 31, 2021
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.
51 remaining items
wowczarczyk commentedon Jan 6, 2023
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.
hideyukn88 commentedon Jan 7, 2023
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 listcommand from Windows's command prompt. Would you please check if the GUID shows for WSL is changing while your docker scenario is running? thanks!wowczarczyk commentedon Jan 7, 2023
I am always getting the same GUID, unless I kill wsl with
wsl --shutdownjustinbowes commentedon Jan 7, 2023
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.
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.
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.
EDIT: After keeping Docker Desktop open for a long time, shutting it down decreases the number of
msrdc.exerequests in both DISPLAY and SYSTEM by 1 or more, but does not necessarily remove all requests. Is it possible to leak such requests?justinbowes commentedon Jan 7, 2023
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?
hideyukn88 commentedon Jan 10, 2023
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!
orionlee commentedon Jan 26, 2023
I'd like to report some similar incident that have been happening intermittently:
(the machine should have hibernated after sleeping for 1 hour in my configuration.)
powercfg, it showedmsrdc.exeheld display RAIL Power Request, similar to what the others had reported.wsl --systemterminal,msrdc.exeno longer held display.exploerer.exe, notepad, and nodepad2 from WSL shells, but had exited them long before the machine was put to sleep.I used the latest store version of WSL / Ubuntu on Windows 11 Home:
hideyukn88 commentedon Jan 26, 2023
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!
orionlee commentedon Jan 26, 2023
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?
msrdc.exegot 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)
hideyukn88 commentedon Jan 26, 2023
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!orionlee commentedon Jan 26, 2023
Hideyuki Nagase (@hideyukn88) I see. So in that case,
msrdc.exeholding 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).


Details for case the machine did not go to hibernate
Details for case the machine went to hibernate after extended sleep
daltschu22 commentedon Nov 3, 2023
Im on windows 10 22H2 and I still have this issue.
powercfg /requestsoverride PROCESS mstsc.exe DISPLAY SYSTEMseems to fix but I have to run it every single time I sleep the computer. This is driving me nuts.antonio-petricca commentedon Jun 30, 2024
Any news about this issue?
nabeelr commentedon Jan 11, 2025
2025 chiming in, I still have this issue too.
javier-au commentedon Feb 11, 2025
Power rail request disappears a short while after minimizing wsl gui apps.