As long as the system determines that there is user or application activity, it will not enter
sleep. The system can detect certain activities, such as user input or network communications. However,
there are other activities that the system cannot detect. For example, a presentation application requires the
screen for display. However, it may appear that the application is idle during the presentation, causing the
system to turn off the display.
To notify the system that your application is busy, use the
SetThreadExecutionState function. This
function prevents the system from entering sleep or turning off the display while the application is
running.
Presentation and multimedia applications must call the
SetThreadExecutionState function with
ES_DISPLAY_REQUIRED so that the system will know that it should not put the display
device to sleep. Event-handling applications, such as tools for managing incoming faxes, must call
SetThreadExecutionState with
ES_SYSTEM_REQUIRED, handle the event, and then clear the flag so the system can return
to sleep. Note that most productivity applications do not need to use
SetThreadExecutionState because the system
can usually determine activity by user input.
To maintain the time since the last user input, the system uses a display idle timer and a system idle timer.
The system compares the idle timers to the values configured in the power plan. If the display idle timer value
is greater than the display time-out value, and no threads have requested the display by calling
SetThreadExecutionState with
ES_DISPLAY_REQUIRED, the system powers off the display. Similarly, if the system idle
timer is greater than the system time-out value and no applications have requested the system by calling
SetThreadExecutionState with
ES_SYSTEM_REQUIRED, the system enters sleep.
The system maintains a count of applications that have called
SetThreadExecutionState. The system tracks
each thread that calls
SetThreadExecutionState and adjusts the
counter accordingly. If this counter reaches zero and there has not been any user input, the system enters sleep.
When applications call the SetSystemPowerState
function with the fForce parameter set to TRUE, the system
generally enters sleep. However, if the next scheduled wake-up time is less than 30
seconds from the current time,
SetSystemPowerState leaves the system in the
working state and returns FALSE, regardless of the value of the
fForce parameter.
If the system wakes automatically
(PBT_APMRESUMEAUTOMATIC), none of the timers
are relevant. For more information, see System Wake-up
Events.
Entering Sleep
When the system enters sleep, it will automatically preserve the state of the entire system and all
applications. Therefore, most applications do not need to take any special action. Applications that need to
perform specific actions before the system transitions can register for power events.
When the system sends a PBT_APMSUSPEND event, each application has two
seconds to perform any necessary actions before the system starts the transition to sleep. Applications
must limit what action they take in response to this event to ensure that they complete all operations in the
time allotted.
Windows Server 2003 and Windows XP/2000: The system initiates a sleep request by first sending a
PBT_APMQUERYSUSPEND event. Applications should
not deny this request; doing so will prevent the system from going to sleep.
After all applications have accepted a sleep request, the system sends a
PBT_APMSUSPEND event. Applications are allowed up to 20 seconds to respond to the
PBT_APMSUSPEND event. In some circumstances, the
sleep request can be canceled. If this occurs, the system sends a
PBT_APMQUERYSUSPENDFAILED event. In this
case, the application should restore its data to a working state and continue operation.
See Also
- About Power Management
- System Wake-up Events
Send comments about this topic to Microsoft
Build date: 11/19/2009