So you’re writing a console application and you think “Hey, it would be great if I could catch power events so I could:”
- get all my data in a sane state before a shutdown
- defer heavy processing until we are back on AC power
- reinitialize network resources if we just returned from an unexpected sleep state
You fire off a Google search for “Windows Power Events” and you quickly come across this MSDN article that tells you that you need to call the RegisterPowerSettingNotification API function. Super! Then you quickly notice a few problems:
- The RegisterPowerSettingNotification function takes either a Window Handle or a SERVICE_STATUS_HANDLE.
- You’re a console application so you don’t have a Window handle.
- You aren’t running as a service so you can’t call RegisterServiceCtrlHandlerEx to get a SERVICE_STATUS_HANDLE
- The minimum supported client is Windows Vista and you would like to at least support Windows XP forward.
Ahh, crap. As far as my (prolonged) search results show, there is no way to receive power events without either having a window handle, running as a service or being a device driver. Period.
Enter the Hidden Window
The best solution to this problem that I’ve come across is to create a hidden window. It seems like such a hack, but it does work! There are a few things you need to be aware of when using this method. As per MSDN recommendations one should generally use a single thread to create all of their windows. The system directs messages to individual windows, so you need to process the message queue on the same thread that created the window*. In a Windows application this is generally all done in WinMain. However for a console application, we likely have other things going on in the main thread, especially if we want the power event notifications to be available early on in the application startup process. Therefore I create a separate thread which will create the hidden window, register for power events, and then continuously process the message loop.
* In fact, the message queue is really the thing that we need in all this so that we can receive the WM_POWERBROADCAST messages. AFAIK, the only ways to get a message queue are via creating a window or running as a service.
After you have a thread and create a window you will automatically receive the WM_POWERBROADCAST messages in your message queue for the following power events:
As you can see you may not even need to call RegisterPowerSettingNotification at all to get the events you need! In the case of Windows XP, these are all that you are going to get. On Vista and later however, you may still want to register for additional power events. There are several more event types that you can register for, which are described here. The ones that I cared about were:
Show Me Teh Codez!
I wrote a sample console application in C that creates a hidden window on a separate thread, tries to register for additional power events if they are available, and then processes the message queue until the user enters input twice. It prints the message type of any window message it receives, but it provides additional information for power events. The application has both 32- and 64-bit builds and has been tested on Windows XP Home RTM 32-bit and Windows 7 Home Premium 64-bit. It is written with Visual Studio 2010 but the code should work on previous versions of VS as well, you’ll just have to migrate the project and solution settings.
NOTE: In order to build for Windows XP RTM/SP1 I targeted the v90 (Visual Studio 2008) toolset. You must have Visual Studio 2008 installed to do this. See my post here on how and why I have to do this.
- Michael Dunn has written great article over on Code Project on “Vista Goodies in C++: Monitoring the Computer’s Power Status”
- MSDN: The Power-Aware Application
- Channel 9: How To: Use Vista’s Power Management APIs to Be a Good Laptop Citizen