Export (0) Print
Expand All
4 out of 9 rated this helpful - Rate this topic

System Sleep Criteria

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:  

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.

Related topics

About Power Management
System Wake-up Events

 

 

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.