Modern Standby stress and long-duration testing
System designers should run stress tests and long-duration tests on their Modern Standby systems to help identify and resolve potential reliability issues. Modern Standby enables the system to keep running, even when it is in a low-power, screen-off state. This state is different from the traditional ACPI Sleep (S3) and Hibernate (S4) states, in which much of the system hardware and software is stopped and then stays inactive until it is later restarted on resume.
Modern Standby enables the system to stay up and running for a much longer total time and can therefore expose hardware and software reliability issues that would not be discovered on a system that supports only S3 and S4.
Entry and exit
Every Modern Standby system should be validated to enter and exit Modern Standby for at least 1,000 cycles without failure. Entry to and exit from Modern Standby is the user's primary interaction with low-power operation on the system and should be extremely reliable.
Successfully entering and exiting Modern Standby validates a number of hardware, firmware, and device-driver components, which include:
- The platform hardware that manages power-button operation, including the power-management IC (PMIC).
- The display-panel management and initialization hardware.
- The Wi-Fi and networking device firmware and driver.
- The graphics device driver.
Stress-testing of Modern Standby entry and exit can be automated using the PwrTest tool. PwrTest should be installed on the target system as part of the Windows Driver Kit (WDK), which includes additional software for automating the system power button on Modern Standby systems.
| Test scenario | Expected result | Diagnostic notes |
|---|---|---|
The system can enter and exit Modern Standby reliably for at least 1,000 cycles. |
Use the PwrTest tool and the /cs command-line option to automatically cycle the system through Modern Standby for 1,000 cycles. The expected result is that the system completes all 1,000 cycles. |
We recommend incrementally increasing the stress test to 1,000 cycles. First, test for 100 cycles. If an error is found, connect the system to a kernel debugger and to the SoC hardware debugger, and repeat the 100-cycle test to capture and determine the root cause of the issue. After the 100-cycle test successfully completes, extend the cycle count to 500 cycles and then to 1,000 cycles. |
SoC low-power state transitions
The firmware and drivers that are responsible for managing SoC transitions between the idle and active power states must be highly reliable to withstand the stresses of operating for long periods in Modern Standby. SoC low-power state transitions should be stressed through long-duration Modern Standby testing. This testing helps ensure that the system remains reliably operational during long Modern Standby durations, such as over the weekend. This test should be performed while connected to AC power.
| Measurement scenario | Expected result | Power notes |
|---|---|---|
The system can stay in Modern Standby for 100 consecutive hours and is functional on exit. The system maintains Wi-Fi connectivity during the 100 hours and Wi-Fi connectivity is functional on exit. |
Put the system in Modern Standby and wake it with the power button after 100 hours. The expected result is that the system powers on instantly and the Wi-Fi connection is operational without additional configuration or selection of a Wi-Fi network. |
We recommend incrementally increasing the long-duration test to 100 hours. First, test for 24 hours. If an error is found, connect the system to a kernel debugger and to the SoC hardware debugger, and repeat the 24-hour test to capture and determine the root cause of the issue. After the 24-hour test successfully completes, extend the duration to 100 hours. |
Windows HLK Modern Standby stress test
The Windows Hardware Lab Kit (HLK) includes a Modern Standby stress test named Connected Standby Stress with Driver Verifier's Concurrency Stress that exercises automatic modern standby transitions at the same time that device drivers are exercised for device operation. The test is designed to verify that the device and its driver(s) continue to function as the system transitions to and from the Modern Standby power state.
This test is a critical part of validating that the system continues to operate as expected after it exits Modern Standby. This test is included as part of the Windows HLK and is required for system certification.
Test operation
The test uses the Windows Device Testing Framework (WDTF) SimpleIO interfaces to exercise devices that are enumerated on the system. These devices include sensors, cameras, audio, graphics, Wi-Fi, storage, and Bluetooth devices. The test places the system in Modern Standby for one minute, and then transitions the system out of Modern Standby and exercises the devices for 30 seconds. This cycle repeats 150 times.
During test execution, Driver Verifier is enabled to help identify driver bugs and memory leaks.
The test helps identify the following system or device driver problems:
- A system becomes unresponsive or crashes during device operation after a Modern Standby session.
- The inability for the system to enter the low-power state (deepest runtime idle platform state, or DRIPS) after device activity.
- Driver issues that are identified by Driver Verifier, including system corruption, driver failures, and memory leaks.
- Driver issues after resume from Modern Standby, including unresponsiveness, crashes, or problem codes.
Resolving test failures
The test exercises multiple devices, which can result in different types of test failures. Identifying the type of test failure is the first step to finding the root cause of system or driver issues.
The test typically fails in one of the following three failure modes:
- The test fails and the failure is recorded in the Windows HLK logs, which contain data about the detected failure.
- The test fails, but the system does not report to the Windows HLK server as a result of the failure; however, the system is responsive and works with local interaction.
- The test does not complete and the system under test crashes or becomes unresponsive (frozen at a black screen).
Debugging test failures that are recorded in the Windows HLK logs
There are two common failure types when test failures are recorded in the Windows HLK logs:
- The system failed to enter the low-power state (DRIPS) during the test.
- The test detected that it could no longer communicate with a driver, and a time-out occurred.
You can use the SleepStudy report, which is included as part of the test logs, to identify which components are responsible for preventing the system from entering the low-power state (DRIPS). There are several common causes:
- Test setup and configuration problems, including using a wired Ethernet adapter that does not support NDIS 6.3 and Modern Standby functionality.
- DHCP server problems on the wired LAN network.
- A device and/or driver that does not correctly idle to its own low-power mode during Modern Standby.
The test logs might also include a failure message that indicates which devices did not respond to I/O requests in a timely manner. This condition is considered a test failure because it can prevent the user or an app from being functional when the system resumes from Modern Standby.
The test logs indicate the last devices to perform I/O operations—these devices are the source of the test failure. The test log output in the following example shows that the ACPI\XXXX\2&DAFA3FF&1 device timed out.
Message |
7/16/2013 12:50:24.333 AM |
WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Location Sensor Device ACPI\XXXX\2&DAFA3FF&1) |
Message |
7/16/2013 12:59:50.333 AM |
WDTF_SIMPLEIO_STRESS_PROC : - WaitAsyncCompletion(Some Other Device XXX_XXX\UART_XXX\3&2F829BAD&0&F00D) |
A common cause of failures is poor GPS reception, which causes the GPS device to take extremely long amounts of time to reply to I/O requests. For more information about running this test on systems with GPS devices, see Notes for systems that are equipped with GPS.
Debugging test failures without logs (and a responsive system)
If the system under test is still running with no signs that the test is still running, the most likely cause is that the system has encountered a fatal error or restarted. To debug these issues, check the system directory for any dump files, and disable any hardware watchdog that might reset the system.
Debugging test failures when the system is unresponsive (black screen)
If the system is frozen on a black screen, a kernel debugger must be must connected to the system to diagnose the problem.
If the kernel debugger is already connected and the system is not responding to the kernel debugger, a hardware debugger is required to identify the reason that the system locks up. You can consult with the core silicon/SoC provider for additional assistance with debugging.
Additional HLK Documentation
Notes for systems equipped with GPS
If the system-under-test has a GPS device or location sensor device, the following Windows settings must be enabled before running the test:
- Control Panel\Hardware and Sound\Location Settings\Turn on the Windows Location platform
- PC Settings\Privacy\Location: Let Windows and apps use my location
You can use the Sensor Diagnostic Tool in the Windows Driver Kit (WDK) to confirm the reception of the GPS signal at the test site. For more information, see Testing sensor functionality with the Sensor Diagnostic Tool.