[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
Why is there a need for a special embedded power management in Windows Embedded Standard 2009? Does it behave differently than the desktop OS? These are valid questions about a small, but powerful component that can be found in the Systems\Management\Applications node of the Component Catalog.
It contains two files XPePM.dll and XPePM.exe. The dll holds an API that can be targeted by applications e.g. maintenance utilities or custom shells. The exe is a command line program run in a console window, or in scripts and batch files.
Embedded access to Win32 power management
To make it short, the Power Management Application component is not a different technology, but another way to access the normal XP Professional power management infrastructure. It was designed to provide this functionality in smaller images that do not have Explorer shell or a complete Win32 API set and therefore have no easy means to change the power state.
An example would be images built with the MinLogon macro component.
In a command prompt, embedded power management commands look like this:
XPePM [-Shutdown | -Restart | -Standby | -Hibernate | /?]
Pretty straightforward, isn’t it? Nevertheless, for images built using the WinLogon (Standard) component, it is recommended that you use the Win32 API calls to SetSystemPowerState and ExitWindowsEx to give applications a chance to do more sophisticated handling of the power state transition. However, the embedded Power Management Application works on larger images, as well.
Applications or shells need to handle power management. XPePM.dll can either be statically linked to a native application or called from managed code with the help of PInvoke.
The required XPePM.h header file can be found on the Windows Embedded Standard installation DVD. With a custom shell XPePM provides everything needed to access all system power modes. In maintenance applications it can be equally useful, especially if one needs to manage write filters. In this case write filter commands require reboots that are not triggered automatically using the related console management applications or APIs. With the help of XPePM this can be handled very well. I myself use this heavily in one of my own free utilities to handle EWF and HORM called HMLite.
Although based on the same infrastructure there are some minor differences between the functionalities of the standard and the embedded access. When using the embedded power management (Power Management Application component), Shutdown is pretty direct (instant off) and does not wait for any applications to store data in registry or on the file system. This may lead to problems if applications need to store data before shutting down.
With Hibernation, when using XPePM, there is no new logon required if you resume with the same user the image was hibernated as it is in desktop windows. This is a nice feature for kiosks, gaming or headless systems.
Configuring power management settings
XPePM cannot be used to configure power management settings. It is a tool directed at controlling the actual power states.
Power management settings are to be found in the HAL component related to the target hardware (such as for example Standard PC) and can be configured in Target Designer.
This is important, because if one does not set the checkmark at “Enable hibernation support” the hibernation mode will not be available in the embedded image. In addition, a power management policy that fits the usage scenarios of the embedded device (e.g. “Always On”) should be selected.
Problems with XPePM are quite rare. The only issue that I am aware of is that errors related to a missing hibernation mode occur. This can be caused by a wrong configuration in Target Designer, as described above, or a wrong driver for the video adapter.