Account Limitation of SetThreadExecutionState of ES_DISPLAY_REQUIRED about awake HOT 1 CLOSED

Interesting, but does the underlying function of resetting the timers work? Is the display prevented from turning off when you call the methods periodicly?

I mean setting those two flag with continous is optional, you can just set system required and display required without continous and the timers will reset for the thread all the same. the only difference with continous is that the timers will reset automatically for the calling thread for as long as the thread lives or the two flags are removed. So even though your display required does not stick it should (if there is a display attached) reset the timers for it.

But for a more likely scenario my guess would be that even though you have an interactive session there is no display with a timer bound to that session. Windows at its core has terminal server functionality with multiple parallel sessions but one display is only connected to one session at a time. and thats not the interactive session for the local system user, thats maybe the reason the continous display required flag does not stick since there is no display attached.

have you by chance called GetLastWin32Error from the marshal class? And converted the number you get (hopefully > 0) to a error message using FormatMessage from kernel32.dll? What does it say. I mean it should say something if the executionstate could not be fully set to the desired value.

sanity check ... you are operating on one thread. not with some async await stuff on the thread pool. the setthreadexecutionstate has thread in it so its a per thread setting and threads in the threadpool are kind of short lived sometimes. console apps have traditionally one thread that is bound to the terminal, a gui app has one main thread with its application loop, a windows service with the newest service host builders and backgroundservices lives on the threadpool.

from awake.