Option to prevent manually triggered S0 sleep (lid closure, for example)

[MARK-Git-N]

This is an amazing piece of software. I was looking for something that would temporarily prevent the computer from going into sleep mode, and your software does it wonderfully and simply, just like I dreamed. Thank you for that!

Currently, the software prevents the Windows timer from entering sleep mode. However, it still enters sleep mode when the screen lid is closed. Adding the ability to prevent sleep mode in this scenario would significantly enhance the software's functionality.

Thanks for everything!

[CHerSun]

Hello, @MARK-Git-N. It's cool you like it.

Currently, the software prevents the Windows timer from entering sleep mode. However, it still enters sleep mode when the screen lid is closed. Adding the ability to prevent sleep mode in this scenario would significantly enhance the software's functionality.

Hmm, I was pretty sure it already works like this, i.e. prevents laptop from going to sleep even on lid closing. I'll try to replicate this when I can. If you have some extra info to add (like how you tested, or working examples, or whatever else) - I'd appreciate that, could save me some time.

[CHerSun]

I've checked this on a desktop for now:

powercfg -requests

Lists nosleep properly:

DISPLAY:
[PROCESS] \Device\HarddiskVolume5\Users\CHerSun\scoop\apps\nosleep\1.2.0\NoSleep.exe

SYSTEM:
[PROCESS] \Device\HarddiskVolume5\Users\CHerSun\scoop\apps\nosleep\1.2.0\NoSleep.exe

AWAYMODE:
[PROCESS] \Device\HarddiskVolume5\Users\CHerSun\scoop\apps\nosleep\1.2.0\NoSleep.exe

EXECUTION:
None.

PERFBOOST:
None.

ACTIVELOCKSCREEN:
None.

Trying to forcefully send PC to sleep - it turns off the screen indeed, but doesn't go to sleep, i.e. there's a message in event logs from Kernel-Power with id 59, accompanied with id 187 - attempt to sent PC to sleep, but no actual sleep events (going into sleep and wake-up events).

Also double-checking with ipython with:

from datetime import datetime
from time import sleep

while True:
    sleep(1)
    print(datetime.now())

shows no skips in time logging.

Turning off the screen looks misleading for sure. I'm not sure if I can prevent it, still looking for info.

[CHerSun]

Disabling nosleep and repeating the same steps for forceful sleeping I can see Windows events for sleep:

Information	28.12.2024 3:41:50	Kernel-Power	59	(65)
Information	28.12.2024 3:52:49	Kernel-Power	187	(243)
Information	28.12.2024 3:52:58	Kernel-Power	42	(64)
Information	28.12.2024 3:53:00	iaStorE	4151	None

Information	28.12.2024 3:53:00	Kernel-Power	107	(102)
Information	28.12.2024 3:53:07	Kernel-Power	131	(33)
Information	28.12.2024 3:53:07	iaStorE	4152	None

Messages with id 42 and 4151 are indicating actual sleep mode start; id 107 - wake-up.

Script above shows missed time logging during the same timeframe:

2024-12-28 03:52:59.248616
2024-12-28 03:53:00.249477
2024-12-28 03:53:06.936553
2024-12-28 03:53:07.937258

So it looks like nosleep does prevent the sleep, but cannot prevent screen turn off event in this case.

Could this be your case @MARK-Git-N ? Could you elaborate a bit more?

[MARK-Git-N]

Hey @CHerSun , thanks for the quick response!
Honestly, I'm not really knowledgeable about Programming and Scripts.
But I see that when I close the screen cover the user is locked, and most importantly all music playback stops.

[CHerSun]

I've found a small bug - app needed ~10 seconds to request proper execution state when you toggle it to enabled state. If you took action fast during tests - this might've been what caused the behavior. Could you test version 1.3.0 (https://github.com/CHerSun/NoSleep/releases/tag/1.3.0 or scoop install nosleep@1.3.0 if you are using scoop)?

[CHerSun]

@MARK-Git-N just a though, what does your laptop do on lid closing? If you go to Settings -> Power & sleep -> Advanced power settings -> Choose what the power buttons do - you should get something like this:

There will be lid action too. Just a guess, but it could be set to hibernation.

[MARK-Git-N]

This is how it looks by me

[CHerSun]

I was able to get a Lenovo laptop and reproduce it there. Behavior clearly differs from desktop.

While NoSleep correctly claims it needs SYSTEM and AWAY mode - system still goes to sleep - both from lid closing and from forcefully triggering sleep mode. I'll try to investigate this further.

I can only suggest to change behavior on laptop lid closure for now as a workaround.

[MARK-Git-N]

Indeed, the computer in question is a Lenovo.

[CHerSun]

Ok, I've checked every possible power-related setting and tweak, as well as all docs I could find. SetThreadExecutionState with ES_AWAYMODE_REQUIRED (this is used in NoSleep actually) should prevent the sleep --- including manual sleep. Problem is it looks like it works differently with the Modern Standby (S0 mode). In S0 mode it looks like the app itself (i.e. music player) should request something to continue working. Also it looks like S0 mode cannot be prevented in general, like with NoSleep. System power states reference from Microsoft, which has a note on ES_AWAYMODE_REQUIRED for S1-S3 sleep only, not for S0 sleep.

So this is the only guess left --- S0 vs S1-S3 sleep modes difference. My desktop PC uses S3 sleep and the sleep is prevented as expected, including manually triggered sleep (good/expected).

Lenovo Laptop I have uses S0 sleep. It goes into sleep with NoSleep running. I cannot change this laptop's sleep mode (I don't have access to its BIOS).

To check currently used sleep mode one needs to run this command in administrator mode:

powercfg /a

On top the command will output available modes. If S0 is available - all other modes will be disabled automatically.

There's a tweak to try to disable S0 mode from Windows side alone (needs a reboot), but this didn't work for this laptop (there might be a setting in BIOS, can't access it though).

@CHerSun to do:

• check another laptop if I can get that to run in both S0 and S3 mode to double-check my findings.
• subscribe to power events and try to cancel sleep actively

@MARK-Git-N could you check sleep mode used on your laptop (the powercfg /a command above) and report that? Full output is ok too. I guess it's S0, but need to be sure. Also, if you can change sleep mode to S3 on your laptop to verify this theory - I'd appreciate your help.

P.S.: Just to clarify, NoSleep will still prevent automatic sleep in S0 mode, but NOT MANUALLY triggered sleep (lid closure is considered manual, if it is set to sleep in power options).

[CHerSun]

@MARK-Git-N I've forgotten to mention that in my tests a MouseJiggler with low delay (1 second) did prevent S0 sleep for me. It simulates user events, mouse movements in this case. Zen mode uses virtual device, i.e. doesn't interfere with your actual mouse.

[CHerSun]

I was able to find another older laptop today - ASUS. It comes with S3 sleep only (no support for S0 sleep at all). NoSleep properly prevents sleep - both automatic and manually triggered (power -> sleep; lid closing with power options action set to sleep).

So currently I have only 1 conclusion - it is indeed S0 sleep mode way of work. Hoping for a confirmation from you @MARK-Git-N that your laptop is using S0.

Now, the question is what to do:

• Change sleep mode from S0 to S3. S0 is responsible for a lot of bugs, including overheating of laptops, so this solution looks quite OK imo. Problem is - it might be impossible for specific model.
• Disable Sleep on lid closure.
• Try to catch power events in NoSleep - I will do this when time permits, might be a wrong way to go (PR is welcome, if any1 will want to do that).
• Try some workaround, like MouseJiggler I mentioned above.

[MARK-Git-N]

Sorry for the late response..
Indeed, for me it is on S0 mode.

This is what appears in the output in CMD

The following sleep states are available on this system:
Standby (S0 Low Power Idle) Network Connected
Hibernate
Fast Startup
The following sleep states are not available on this system:
Standby (S1)
The system firmware does not support this standby state.
This standby state is disabled when S0 low power idle is supported.
Standby (S2)
The system firmware does not support this standby state.
This standby state is disabled when S0 low power idle is supported.
Standby (S3)
The system firmware does not support this standby state.
This standby state is disabled when S0 low power idle is supported.
Hybrid Sleep
Standby (S3) is not available.
The hypervisor does not support this standby state.

[CHerSun]

Thank you for confirmation. My conclusions look to be correct. I'll try to dig into preventing S0 sleep programmatically, when time allows.