Windows Mobile 6.5 Suspend Mode Notifications

In Windows Mobile 6.5, the operating system relied on a centralized Power Manager to preserve battery life by transitioning the device into a low-power suspend state. This article explains how the OS notified running applications of an impending suspend transition, detailing the architectural mechanisms including the Power Manager message queues, window broadcast messages, and the State and Notification Broker used to manage application lifecycles before execution was halted.

The Power Manager and Message Queues

The primary and most robust mechanism for tracking power transitions in Windows Mobile 6.5 was the Power Manager API. Applications used this system to register for asynchronous notifications about power state changes through inter-process point-to-point message queues.

To receive these events, software performed the following steps:

  1. Queue Creation: The application created an incoming message queue using the CreateMsgQueue API.
  2. Registration: The application called RequestPowerNotifications, passing the handle to the message queue and a set of flags indicating which types of power transitions it wished to monitor (such as PBT_TRANSITION).
  3. Event Polling: A dedicated background thread waited on the queue handle using synchronization functions like WaitForSingleObject.

When the system prepared to enter suspend mode, the Power Manager pushed a POWER_BROADCAST structure into the queue. The Message field contained PBT_TRANSITION, and the SystemPowerState field explicitly reported the target state (typically D3 or "Suspend"), allowing the application to quickly serialize data and release hardware locks.

Window Messages (WM_POWERBROADCAST)

For graphical UI applications utilizing a standard Win32 message loop, Windows Mobile also supported the legacy WM_POWERBROADCAST message dispatched directly to window procedures (WndProc).

  • PBT_APMQUERYSUSPEND: Historically dispatched to ask permission to suspend, though in Windows Mobile 6.5 this was largely informational, as the system forced the suspend state to conserve battery regardless of return values.
  • PBT_APMSUSPEND: Sent immediately before the device entered the sleep state. Upon receiving this message, the application had a very short window of time to stop active threads, pause media playback, and save critical state.
  • PBT_APMRESUMESUSPEND: Sent when the device woke up, prompting the software to reinitialize hardware interfaces, reconnect sockets, and resume UI timers.

The State and Notification Broker

Windows Mobile 6.5 featured the State and Notification Broker, which mapped system states to specific Windows Registry paths under HKEY_LOCAL_MACHINE\System\State.

Applications could register to monitor device state properties—such as SN_POWERBATTERYSTATE_ROOT—using the RegistryNotifyWindow, RegistryNotifyMsgQueue, or RegistryNotifyCallback APIs. When power conditions changed or a shutdown/sleep sequence initiated, the broker signaled the registered callback or window, providing high-level state awareness alongside the lower-level Power Manager messages.

Execution Halting and Resource Management

Once the operating system broadcast the suspend notifications, it allotted a minimal time window for running processes to finish their handling. Unlike modern mobile operating systems that keep background tasks alive indefinitely in the cloud or through background fetch intervals, Windows Mobile 6.5 completely halted CPU scheduling in suspend mode.

Any threads that failed to finish their suspend logic were frozen in place mid-execution. Upon wake, the kernel restored CPU power, and threads immediately resumed from their exact instruction pointers, followed by the delivery of resume notifications (PBT_APMRESUMESUSPEND or PBT_TRANSITION targeting the "On" state).