Power to the People

In 2002 when we released our first Smartphone OS, there were quite a few fundamental differences between the Smartphone and the PocketPC.  Since then, we've been working to unify the platforms.  In WM5, we did a bunch of plumbing work to this end, and brought Softkeys and Persistent Storage to PocketPC.  At this point, the two biggest differences in the platforms are the PocketPC touch screen and the wildly different power models the two platforms use.  In this blog entry, I'm going to talk about those power models and what they mean to users.  I'll follow up with a second entry that talks about what this means to ISV developers.

You are getting very sleepy...
It all comes down to this: PocketPCs sleep, and Smartphones don't.  Smartphones have a model that's very easy to understand.  The device can be on, or it can be off.  When it's on, everything works.  When it's off, nothing does.  When it's off, you can't receive phone calls, you don't get meeting reminders, and nothing is burning power.  You can pull out the batteries and have no detrimental effects.  (Okay I'm stretching the truth a bit here.  Many phones use a tiny bit of charge to keep a clock going so that you don't need to reset the time every time you pull out the batteries.) 

The PocketPC model is much harder to explain.  It can be on, it might be able to be off, and it can be somewhere in between.  A purist will call that in between state "suspended" but I like to anthropomorphize my devices, and "sleep" is more catchy.  When the device is asleep, the screen is off, and programs aren't running.  In fact, by and large, programs don't even know that the system went to sleep.  We never tell them, and we expect them to act as though it never happened.  While the PocketPC was asleep, they just didn't run. 

Still, while the system is asleep, there are a few things that keep working, and those things can wake the system back up.   For instance, the power button works.  And an incoming phone will wake the system up.  So will a meeting reminder.  Applications have the ability to say, "Run me at this time, and wake the system up to do it if you have to."  If you've ever had your PocketPC turn on in your pocket, it was a result of something deciding it was time to wake up, even though you didn't want it to.  (Yes, that annoys me too.)

Sleep is the main way that PocketPCs conserve power.  So the PocketPC is always trying to fall asleep.  He's like a bored security guard on the graveyard shift staring at a TV screen with his eyes drooping, only to jolt himself back awake every few minutes.  In Settings you get to tell your PocketPC how long to stay awake.  Three minutes is typical.  And then you've got to actively work to keep him up.  If three minutes go by without you pressing any buttons or touching the screen, he'll fall back to sleep.  (You can put him right to sleep by pressing the power button.)  Apps that want to keep him awake longer need to be proactive about it.  There's a function apps call (SystemIdleTimerReset) every 30 seconds when they want the system to stay awake.  This is how Media Player keeps the music playing for longer than three minutes.  This is also how Active Sync can make sure it syncs everything.  And this is how PIE can download huge files without the system falling asleep in the middle of them.  Etc.

But wait, it gets even more complicated than this.  What happens when the system wants to wake up briefly to do something (like keep your email up to date) but doesn't want to bother you about it?  (There was a time when the PocketPC turned on at midnight and shined its backlight all over your bedroom, thus waking you up with him.  Now he's smart enough to not turn the backlight on for his midnight excursions.)  There's a semi-lucid state between Sleep and On called "Unattended."  In Unattended, the system is running, but the screen and backlight are off.  Unattended is how ActiveSync keeps your email up to date without turning the device on in your pocket. 

PocketPCs generally don't have a button you can press to turn them all the way to Off.  But if you pull out the batteries (because of Persistent Storage, more WM5 devices will have removable batteries), they'll turn Off completely.  By and large, however, when the device seems to be "Off," he's really just asleep.

That guy must drink a lot of coffee...
As I said before, things are much simpler in the Smartphone world.  Smartphones follow a model we call "Always On."  These guys never sleep.  You can turn them off completely, but when you do that, you don't expect to receive phone calls (at least, I hope you don't.  You'll be disappointed otherwise).  Sure, if you don't touch any keys for a bit, the backlight will turn off.  And if you don't touch any keys for a while longer, the screen will turn off.  And with the screen off, he looks asleep.  But he's not.  He's just resting his eyes.  Programs are still running, and everything is still going.

This is simpler for everyone involved.  Users don't need to understand the differences between On, Off, Sleep and Unattended.  And apps don't need to frequently call SystemIdleTimerReset to keep things going.  We've written all of our Smartphone apps to use the CPU as little as possible.  If you're not actively using the device, then nothing runs 99.9% of the time.  And our OEMs have written code that makes the CPU go into an extremely low power mode whenever there's nothing for it to do.  When the phone is sitting there idle, it's using just barely more power than a sleeping PocketPC.

But there's a drawback.  Badly written apps can do very bad things to your battery life.  Say you've got a cute little app that has an image of a kitty that jumps around and waves to you.  And, say that animation makes the CPU run just 1% of the time.  You've got the device sitting on your desk overnight, with the screen off, and this darned kitty desperately trying to get you to look at it, even though you're in bed and uninterested.  The animation just cut your standby time to one tenth of what it would have been without it.

In my next blog entry, I'll tell developers how not to destroy your battery life.  But, users, if you've got apps that run animations forever, get rid of them.  Yes, the PocketPC sleep would have protected you from these apps.  (Remember that apps don't run while a PocketPC is sleeping.)  But, even on a PocketPC, if you've got an app that's burning power unnecessarily, it's probably not an app you want.

Note that the problem here is apps which use the CPU when you're not using the phone.  Doing animations and such while you're interacting with the app is fine.  If you're playing a game, the backlight is on.  The backlight is burning a ton more power than the CPU is.  But when you stop playing, that game better stop too.

Mike, what are you smoking?
The PocketPC "Sleep" model has been around since the dawn of time.  Okay, well, at least since the dawn of Windows CE.  So why did Smartphone change it?  You're going to find this hard to believe, but in a connected world, the Always On model actually burns less power than the Sleep model.  Yes, you read that correctly.  Staying on all the time actually burns less power than going to sleep.  Here's why.

The issue is that it takes a "long" time to go to sleep and a similarly long time to wake back up.  When a PocketPC goes to sleep, we have to notify every device driver so that they can each save any important information (their "state") and shut off the hardware they're controlling.  Then, on wake up, we need to notify every driver again and have them turn all their hardware on.  This process can take up to three seconds in each direction. 

Smartphone, on the other hand, can come out of his idle in a millisecond, do what he needs to do, and go back to idle a millisecond after he's done.

Imagine that your device receives a SMS message.  The sleeping PocketPC will need to run the CPU for around six seconds to handle it.  The Smartphone will do the same task in a few milliseconds.  Waking up is much more efficient on a device that doesn't sleep.  It turns on only the devices necessary, uses them for the minimum amount of time needed, and then immediately shuts them back off. 

Now, imagine a device that gets an SMS every time it moves from one cell tower to another, and imagine being in an area where you're on the boundary between two towers.  Or, consider being signed in to an Instant Messenger client and having it frequently updating your friends list.  Or, imagine a process that downloads data you care about every few minutes.  Etc.  As these things become more pervasive, we'll see the Always On power model being much more energy efficient than the sleep model. 

In Windows Mobile 5, the PocketPC still uses the original Sleep power model.  In some future version (maybe the next, maybe the one after that, we don't know yet) PocketPCs will move to the Smartphone Always On model.  And then the touch screen will be the one big difference between them.

Mike Calligaro

Comments (102)

  1. Joel Stidley says:

    Excellent information and a very well written. Keep it coming!

  2. Interesting blog from Microsoft about the power states in the new version of Windows Mobile 2005.

    But does anyone know if the more troublesome problem with the maximum number of processes have been fixed?

    – or is it still only possible to run 32 processes simulataniously in Windows Mobile 2005?

    Furthermore, what about the driver memory model? Is that still split up in in Windows Mobile 2005 so that there is a memory side for applications and a memory area for drivers?

    – Will the "Bluetooth Manager" still raise "Not enough memory" exceptions in Windows Mobile 2005?

    If anyone has sources from within Microsoft.. please let me know about the above "problems" status in Windows Mobile 2005?


    Kristian Reesen Skouboe

    Computer Scientist

  3. Doug Boling says:

    Any device that takes 3 seconds to suspend should be limited to idle and off. However, that shouldn’t prohibit other (well designed) phones that can suspend in 250 mS from using suspend. A combination of persistent store could be quite useful

    Many SP designs could take advantage of suspend to provide a better customer experience… like avoiding the amazingly painful 45 second boot time for a smartphone. Fix that, and we can all brag about eliminating suspend.


  4. windowsmobile says:

    Doug, I think you’re mixing apples and oranges. Adding suspend to smartphone wouldn’t decrease the boot time. Suspend is the equivalent to idle, not off. In suspend, the phone can still ring. In off, it can’t. If you want to be able to receive phone calls, then you’ll let your phone idle. And smartphones come out of idle in milliseconds. If you’re actually turning you phone off, I assume you’re doing it to keep it from ringing. Even a suspending smartphone would be turned off and need to boot again for that.

    Also, we did work in WM5 to decrease the boot time. The WM5 phones I’ve seen so far boot in about 30 seconds. You may claim that’s still too long, but it’s progress.

    Finally, even a device that takes 250 ms to suspend is inefficient compared to a device that takes 1 ms to idle.

    Mike Calligaro

  5. windowsmobile says:

    Kristian, the max number of processes has not changed in WM5. That is fundamental to the way CE works and will take a significant amount of work to change. However, we understand your pain and want to fix it.

    The driver model was also not changed, but it never worked the way you suggested. There is no division between memory for drivers and memory for applications. However, if you’re talking about virtual memory constraints (that’s a division between memory for DLLs and memory for applications), unfortunately, that too was not changed for WM5. It’s another pain point we’re very aware of, and another thing we want to fix, but that will take some fundamental rearchitecting.

    I’m sorry, but I’m not familiar with the Bluetooth Manager issue you’re describing, so I can’t answer that question. There are two bluetooth stacks, one provided by Microsoft and one provided by a third party. The Microsoft stack doesn’t have anything called a "Bluetooth Manager" so I believe you’re asking about an issue with the other stack. I’m not familiar with changes they made to their code for this release.

    Mike Calligaro

  6. Doug Boling says:


    First, I’m not interested in starting an argument. There are valid reasons for suspend and for true off. I would simply like to point out that ‘always off’ isn’t always the best way.

    My point is that to the user, Suspend == off. This, along with the persistent store model has its advantages. A suspend state in a Smartphone could be quite useful for the appearance of fast ‘turn on time’ avoiding the long boot time in many, but not all, cases. After a few hours in battery powered suspend, the phone could quietly power off (real off) to save battery.

    For example, if a suspend enabled phone were being charged overnight, the user would grab the phone in the morning, hit the power button, and the phone would immediately be on, without the need to wait 30-45 seconds to check email, send a text message, or make a call.

    There are plenty of other reasons (too many to go into here) to have the CPU quickly available when the system is ‘off’. I’ve talked to cellular phone manufacturers who also believe this.

    Finally, I’m not talking about replacing Idle with Suspend. CE devices that support Suspend also support Idle. There is no power state that a Smartphone can get into that a ‘suspend enabled’ smartphone couldn’t also get into.


  7. Dean says:

    great, article. I do have a question…you mentioned that the only 2 differences are the the touch screen and the power mode. Does this mean that smartphones can have WIFI? I haven’t seen any that is support it yet.

  8. Riki says:

    "But, users, if you’ve got apps that run animations forever, get rid of them."

    hey, hey, hey not so fast, it’s not quite that simple. i’ve written a home screen plugin which scrolls text, and to do that i spent a good deal of time battling the evils of the power management APIs. well it’s not the APIs fault, it’s the OEM. on one phone they had implemented GetDevicePower(L"BKL1"..) and on the other it was GetSystemPowerState(), but only one of these, and it was the same OEM. GRRRR. bottom line, my plugin was power state aware, and didn’t burn battery when the device was in low power mode.

    Q: so how does PPC Phones work? does the CPU turn off and the radio hardware stay on, which then notifies the CPU, and wakes it up in unattened mode every so oftern? this seem to be what you imply here.


  9. windowsmobile says:

    (I’m following up with Doug offline.)

    Dean, yes WiFi on Smartphone is a new feature for WM5. You will see WiFi enabled smartphones in the near future.

    Riki, it sounds like you agree with me. (-: You wrote an app that DIDN’T run animations forever, so yours isn’t one I’m telling people to get rid of.

    And, yes, your description of how PPC Phone works is correct.

    Mike Calligaro

  10. Ed says:

    I never understood why people would want to turn their phones off… I guess if you had it in a movie theater or hospital (go into airplane mode for that) but for the most part I always leave my phone on so the startup time is a non issue for me.

  11. Tye says:

    I am truly sorry to drag this off topic more, but this is the first time I’ve seen a definitive answer to this question.

    Personally, I consider this to be *the* single biggest problem with CE–to the point that it makes me hesitate to use the device as it advertised.

    I see now that it is too late to expect the architecture to change in WM5’s first release. Instead, please let me ask:

    1. Since the basic architecture and process limit has not changed, does WM5 at least boot "cleaner" than WM2003? Will I be able to run my WM5 device longer before process space runs out? Of course, some of this has to do with what he manufacturers load, but "all else being equal."

    2. Is there a timeline when we can expect to see this resolved? A service pack in six months? Or a total rewrite of the OS in 2007?

    3. Related to above question. Now that WM5 has been released to manufacturers, will this issue take a priority spot to be fixed–not just looked at?

    Again, I apologize, but I don’t think I can stress enough how disappointed I am to hear this news. The memory situation has become so bad, with the VGA devices especially, that I don’t even recommend them to "casual buyers" anymore. Without fail, I end up receiving calls asking why this program or that won’t run when "it worked yesterday." Please keep in mind that these are not power users that are pushing their systems to the limit, either.

    Thank you for your time in answering our questions–it is appreciated.


  12. windowsmobile says:

    (Answers for Tye)

    While we didn’t change the fundamental architecture, we did make some changes.

    32 process limit:

    I will argue that the biggest problem here was having a number of things that were really services running as apps. We recently added services.exe (I can’t remember for sure whether we did this in WM5 or 2003SE). This allows people to run all of these service-like things under one process. That reduces the number of processes running, making the 32 process limit a bit more acceptable. We did not require that all service-like things were made into services though. We can suggest such things to our partners, but in the end, how they choose to act is up to them.

    So my answer there is a copout, "we made it possible for things to be better, but I don’t know if people will take advantage of it." Time will tell.

    Virtual memory:

    We did a good deal of work to make the system use less ram on boot. And we changed the architecture of how the virtual memory is divided up to remove some of the waste there. But we also added more features, making the whole thing a mixed bag.

    It kills me to say this, but I can’t answer your questions 2 and 3, because doing so would be tantamount to me pre-announcing stuff. The best I can say (and, yes, I recognize how lame this answer is) is that we really and truly understand how much of a pain these issues are. The only reason we haven’t fixed them already is that it’s a "rewrite the kernel" sort of change, and that kind of work doesn’t happen overnight.

    Mike Calligaro

  13. So, I’ve finished watching Westworld, again. With robots, action, and that grainy old-movie look, it’s…

  14. Nino.Mobile says:

    So I decided not to blog much from O’ahu – not such a bad thing, eh?  (..and I got sick of updating…

  15. Nino.Mobile says:

    So I decided not to blog much from O’ahu – not such a bad thing, eh?  (..and I got sick of updating…

  16. In Power to the People we learned some of the differences between how PocketPCs and Smartphones handle…

  17. In Power to the People we learned that it’s very bad for your app to use the CPU unnecessarily. …

  18. In Power to the People we learned that it’s very bad for your app to use the CPU unnecessarily. …

  19. Mikel Berger says:

    A good read for CPT 355 about power for Windows Mobile devices http://blogs.msdn.com/windowsmobile/archive/2005/08/01/446240.aspx This is part of series on power, but one of the more interesting parts is the list of power states for smartphones and Pocket PCs from this post http://blogs.msdn.com/windowsmobile/archive/2005/08/10/450186.aspx * On: The user is interacting with the device. Everything is on. * BacklightOff: There has been a brief period of user inactivity (no one has pressed any buttons or touched a touchscreen). The backlight has been turned off, but everything else is on. When you set the backlight timeout values in the control panel, you’re setting how long the system should wait before going into this state. (Note that this state is new for WM 5.) * UserIdle: There has been a longer period of user inactivity. Both the backlight and LCD have been turned off. When you set the screen timeout value on a Smartphone control panel, you’re setting how long the system should wait before going into this state. This state is generally not used on PocketPC. There’s no reason to turn the screen off when the device is about to go to sleep (sleeping turns the screen off). However, if/when PocketPCs go to the "Always On" model, they’ll start using this state. * ScreenOff: You go into this state when someone specifically says to turn the screen (and backlight) off. For instance, in Media Player you can assign a button to turn the screen off. When you press it, we go into this state. This state is different than UserIdle, though. This state says, "The user wants the screen off and doesn’t want it to turn back on." UserIdle says, "The user hasn’t touched any buttons in a while, so we might as well turn the screen off to save power." In ScreenOff, pressing a button (other than the power button) doesn’t turn the screen back on. In UserIdle, pressing a button does turn the screen back on. Both PocketPC and Smartphone use this state. * Unattended: This is a confusing state in which the screen, the backlight, and the audio are off. I won’t go into too many details, other than to say that this is a PocketPC-only state that is used by applications which need to do things without alerting the user. While the PocketPC is in this state, the user thinks the device is asleep. For instance, ActiveSync when it syncs every 5 minutes. It’s waking up, syncing, and going back to sleep, but the user can’t tell. * Resuming: This is the state the PocketPC goes into when it wakes up from sleep. In this state, the screen is off, and there is a very short (15 second) timer before it goes back to sleep. The only way to keep the device from going back to sleep is to have something put it into one of the other states. This is really for dealing with spurious wakeups and for giving the system a way to get into Unattended without letting the user know about it. * Suspended: This is the PocketPC "Sleep" state. Everything is off, and the system isn’t going to wake back up until some piece of hardware wakes it up. It’s not actually an official Power Manager state, the way the other six are, but I’m including it for completeness….

  20. badbob001 says:

    So even with WM5 on PocketPC, I will not be able to yank out the battery (assuming no backup battery) and not lose data? If I install all my programs to flash, what’s left in memory? I’ve heard of a tweak to make WM5 store its registry in flash instead of in memory. Would that help?

  21. windowsmobile says:

    Bob, on WM5 PocketPC, you CAN yank the battery and not lose data. The registry is stored in flash. Data is stored temporarily in RAM and flushed out to flash periodically and at certain times. So it’s possible for you to make a change, immediately yank the battery and lose that change. But you kind of have to try to lose you data to do so. And, you’ll only lose the most recent change, not everything. Everything is always flushed when the PocketPC suspends, so if you want to be sure its safe to pull the battery, press the power button to put the device to sleep, wait 30 seconds, and then pull the battery.

    Mike Calligaro

  22. Bruno says:

    Where can I get specific information about the power management ? Programming the pocket pc is so frustrating because I really can’t find any information, especially information about API’s.

    At the moment I’m writing a ppc application which captures gps data. Everything works fine, but the ppc’s battery last only for about 4 hours. So now I’ve extended my app with some API’s who turn off the ppc after receiving gps data in 20 secs and than after 1 minute the ppc app starts again (with CeRunAppAtTime) receiving gps data. (This way the battery lasts for about 20 hours). However, when the com port is closed and opened again periodically, the gps receiver has to do a restart so it takes some time to record the first NMEA string with good data quality. So that’s the reason why I would like the gps not to go in suspend mode. If it stays on then I have good data each time my app starts itself. How can I force the COM2 (or gps) not to go in suspend mode ?

  23. Kelvin says:

    Nice article, Mike. However in regards with Doug’s comment , i believe your the last section of your article is really comparing an orange to an apple.

    ".. but in a connected world, the Always On model actually burns less power than the Sleep model.."

    It should be rephrased along the lines of < Smartphone HARDWARE burns less power than a PPC HARDWARE would ..>

    Smartphone hardware does not have touch screen , screen size generally are smaller, less power consuming chips ( ie. WiFi chip ) .. mentioned are all power consuming hardware features you would find on PPC devices.

    If i were to say if i have this PPC hardware running Always On model ( ie. SystemIdleTimerReset() often enough to make it Always On ), now your original statement wouldn’t be correct if it is claiming Always On burns less power than Sleep Model in this sense.

    Different platforms require different power strategy and Microsoft is applying a wise strategy to suit the nature of different hardware.

  24. hanson says:

    if smartphone & pocket pc only has those differences, can a smartphone install any application that a pocketpc phone use?

    I mean, not all programs can be navigate by just buttons, right?

  25. MikeCal says:

    Hanson, the smartphone is a subset of the PocketPC.  Almost every application I write runs on both SP and PPC, but it’s entirely possible to write an application that only runs on one or the other.  If the application required a touch screen or physical number keys, it would limit itself to one of the two platforms.  Or, if an application assumed a screen size that was in one platform but not the other, it also wouldn’t work everywhere.  Finally, if an application relied on functions that exist on a PocketPC but that don’t exist on a smartphone, it wouldn’t run on smartphone.


  26. BoblaTurbo says:

    I had a smartphone for a year. I wanted my phone off at night (to save batteries) and for the reminder to work even if the phone is off. I use my phone as alarm clock so it’s very embarrassing being almost late for work when phone alarm doesn’t’ work due to phone being off. Smartphone just couldn’t do this so I fell out of love with my orange spv 500 and went back to a normal phone. Another thing that turned me off the smartphone was the filing system – very scary. I want to find a file to send to someone and then I find myself navigating through the folders as if it’s a desktop – very embarrassing.

  27. Andrew Lewis says:


    I am particularly interested with this statement."And an incoming phone will wake the system up.  So will a meeting reminder.".

    How could we intercept or disassociate any events from waking up the system?.

    any system level or low level APIs which we can use?.

  28. MikeCal says:

    If you turn on Flight Mode, the system will shut down the cellular radio, and incoming phone calls will go to voicemail rather than wake up the system.

    Start->Settings->Sounds And Notifications->Notifications gives you the ability to disable notifications of various system events.  I believe that, if you disable the notification, the system won’t wake up for it anymore.  For instance, under "Reminders" you can clear the "Play sound", "Display message on screen", and "Flash light" options.  

    There’s no way for an ISV application to keep the system from waking up.  It takes OEM code to do that.  You could be notified when the system wakes up, but you wouldn’t have the power to stop it.


  29. Andrew Lewis says:


    Every incoming call, upon a call is offered, and after a call is disconnected (I am using TAPI 2.0), the system will definitely wake the system up.

    I tried the suggested advice on disabling the notifications for ALL available options (not only call related options), just trying to identify which of the events wake the system up. I tried by unchecking ALL options found in the notifications, but it still wake the power up.

    Appreciate if you could point out which particular low level events (from OEM point of view) to wake the system up. Some resource/articles would be very much appreaciated.

    I am interested with the incoming call events where it will be handled by our TAPI application without waking the system up.(and without turning on to Flight Mode, which can not be handled by our TAPI apps).

  30. MikeCal says:

    When the system is suspended, the only thing that can wake it up is a hardware interrupt.  The CPU has a single interrupt pin and a number of different interrupt sources are mixed together (through what’s called a "Multixplexor" or a "MUX") and fed to that pin.  Which interrupt sources are used is dependent on the hardware design, but these are the typical ones:

    1) Keyboard (sometimes any key, sometimes just the power button).

    2) Real Time Clock (RTC).  All systems will have an alarm that generates a hardware interrupt when the RTC hits a set time.  This is how meeting requests and scheduled active sync wake the system up.  They set the alarm for time X, and at that time the RTC fires the hardware interrupt and wakes up the device.

    3) Celluar hardware.  On most devices, the cell stack is running in its own CPU and processing cell activity.  If a phone call comes in, it fires a hardware interrupt that wakes the device up.

    When suspended, the CPU is effectively off.  No code is running, so no code you can write will change things.  When a hardware interrupt is fired and the system wakes up, it goes through a longish process in which every hardware driver is notified and then the system is woken up.  

    The OEM wrote the code that is called just before the CPU is turned off, as well as the code that is called the instant it wakes up.  So he has a lot of control over what happens there.  The OEM also wrote all of the drivers that get called during the wakeup process.  So they have opportunities there as well.  

    When the system finishes waking up, it goes into the "Resuming" state.  In that state, the screen is off and the device will suspend again in 15 seconds unless something puts the system into a different state.  However, because it was woken up for a phone call, the cell radio driver notifies the phone app that a phone call is coming in, and the phone app puts the device into the "On" state and plays the phone ring sound.

    Because it’s hardware, not software, that wakes the system up, the only way to keep it from waking up is to disable that hardware.  For the phone, the only way to do that is to disable the cell stack.  And the best way to do that is to put the phone into flight mode.


  31. DonAndress says:


    Guys there’s this GPS software, ‘i-GO’ and developper says it runs on Windows Mobile for Pocket PC. Can anyone tell me if Windows Mobile 5 is compatible with Pocket PC or Smartphone? Or maybe both?

    Thanks in advance.

  32. Chris says:

    Interesting blog, i actually landed here because i am having a bit of a problem. I have an HTC Universal and was forced to disable the "sleep" aka "suspend" features because it takes 6+ seconds to wake up rather vital functions such as your RINGER/AUDIO and vibrating functions.

    The problem with this is, 6 seconds on an incoming call = you miss all your calls [because it only starts ringing after the device wakes up] !

    So the person calling me, hears the phone rings, but my little PPC is sleeping and takes ages to turn on audio/vibrating functions to let me know of the call.

    In fact, this is the order of events:

    1. Person calls me, this person hears ringing on his end.

    2. My PPC in "sleep" mode, starts waking up to receive this incoming call.

    3. First thing to wake up after 3-4 seconds is the backlight. So i can SEE i am receiving a call on my screen, but my phone ain’t ringing yet.

    4. After another 3+ seconds, the phone starts ringing and vibrating.

    Now point 4 for me will seem like the FIRST ring, for the other person it’s like the 7-8th ring! Most people don’t wait that long..missed call!

  33. MikeCal says:

    Chris, they behavior you’re describing is not normal.  Did your device act this way when you first got it, or did it start waking up slowly later?  If it started later, have you installed any extra software on the device after you bought it?  Can you try uninstalling that software and seeing if it fixes your problem?

    If you haven’t installed anything extra, is there anything else different about the device compared to when you bought it?  


  34. Chris says:

    Hey Mike

    Thanks for tipping me off that it’s not normal, i just assumed it’s a CPU limitation . I decided to do a hard reset. After the reset everything worked fine [wake up instantly on incoming call] , until i changed a specific setting : My ringtone!  

    I used a WMA ringtone located on my storage card. It seems "starting up" whatever must play the WMA from the storage card takes alot of time to execute.

    I moved the ringtone to local storage [built in RAM] , and this seems to solve the issue. Conclusion? Something to do with initializing the storage card from sleep mode takes awhile?

    The first setting i usually change ,is my ring tone [on hard reset] , so i never noticed this.

  35. MikeCal says:

    On most devices, the SD hardware is powered down when the system suspends.  So it needs to be re-initialized on wakeup.  Then, after it is initialized, it needs to find the SD card and mount it.  Depending on the SD bus hardware and the particular SD card, this process can take a few seconds.  So you definitely don’t want to store your ringtone on an SD card on a suspend/resume PPC.  

    Your device is WM5 based, so when you moved the ringtone into local storage, it should be put into internal flash, not RAM.  If it was put into RAM, you’d lose it on soft reset.  That would be bad.  You’re putting it into Application DataSounds right?

    Yeah, moving my ringtone over is one of the first things I do to.  I’m glad you were able to fix your problem.


  36. Chris says:

    Thanks for that SD card detail. Yes, my device is WM5 based so i assume it’s into internal flash. My exact directory is actually WindowsRings .

    I wanted to keep it on storage because it’s full quality WMA songs [4-5MB] . With only 64MB flash memory you start getting picky what you place on there 😉 .

    I guess it’s live and learn.

  37. MikeCal says:

    WindowsRings should work.  The official place to put your ringtones is Application DataSounds.  The small advantage to using the latter is that you don’t need to go through the Windows directory, which is very large and takes a while to browse through.  Either way, though, you’re in flash so you’re okay.


  38. LJKelley says:

    Thanx for the very informative article 🙂

    My problem:   I have a regular Windows Mobile 5.0 Pocket PC.   I have intergrated WiFi and have installed Skype on it.

    There should be away to reduce power consumption in an Smartphone type way, to constantly receive Skype Call Notifactions or MSN Messenger Messages thur WiFi without requiring the Device to be 100% On (which eats a ton of power, on my device its about 1% a minute)

    Perhaps a Service Pack or other fix to allow a 3rd power state would be useful to alot of people.

  39. In my recent “Power to the Smartphone” entry, I talked about the biggest drains on Smartphone batteries.&amp;nbsp;…

  40. Osama El Mahmoud says:

    With regards to the 32 process limit on WM.  What exactly is the behaviour when the 33rd process attempts to launch, and is this behaviour consistent across PPC 2003 and WM5 devices?

  41. J. Heyison says:

    My Samsung i730 running Win Mobile 5.0 still wakes up at midnight and turns on the backlight.  Does anyone know of any fixes?

  42. Kim Nergaard says:

    I have a Qtec 9100 (WM5) with a 1 GB storage card. I keep my music/podcasts on the storage card. When I power off while playing a song and then power on again the media player is there but the song/playlist is gone so I have to go to the library and find the song again etc. VERY annoying. Is this a power thing or a problem with my Storage card? Any help would be greatly appreciated.

  43. Sam says:

    I have the same problem as J. Heyison — I just upgraded my i730 to WM5.0, and now it keeps turning the backlight on for no reason.  In fact, sometimes it turns on the backlight but not the screen, so I just see a white screen.  When I flick the backlight switch on the left side, it then comes on normally, and I can turn it back off — until the next time it decides to turn itself back on.  It was so bright it woke me up in the middle of the night last night!  (Okay, I’m a light sleeper…)

  44. DrDave says:

    I have a similar problem to J. Heyison and Sam, except that at midnight the i730 makes a sound (which wakes us up, my wife wasn’t happy…). I don’t think the backlight is coming on. It may have started doing it after I accidentally turned on the alarm, and then turned it off. It appears to only do it some nights, maybe one night a week. Any ideas? (BTW, great blog!)

  45. aleh says:

    Funny that Media Player on Qtek 8310 eats the battery quite fast (4x faster) even if nothing is being played back! I need to manually close it using the Task Manager every time I do not need it 🙁

    Someone (Media Player guys or Qtek team) should check this.

    Mike, thanks for the great articles!

  46. Leftyjace says:

    let me add my 4th voice the very same problem Sam, J. Heyison and DrDave have. the whole reason i found this blog is because I was looking for a solution to this very problem. This is a new problem, and only exhibited itself once I upgraded to WM 5.0.

    my phone always goes blank screen, fully lit. it’s very sporadic. it wakes me up at night. it drains the battery. sometimes i can get it to stop, sometimes not – doing a soft reset solves the problem, but only temporarily.

    There has GOT to be a fix for this. It’s driving me bonkers! Anyone? Anyone?

  47. MikeCal says:

    Unfortunately, we’re the wrong people to report this to.  The backlight driver on the i730 was written by Samsung, and no one at Microsoft has access to it.  If it’s misbehaving, only Samsung can fix it.  Your best bet is to report this to your mobile operator so that they can report it to the OEM.


  48. JeanB says:

    Thanks for these information ,

    I have a problem I did’t have on the previous versions of windows ce (mobile), and it concerns the power management, and more precisely the sleeping state and the wake up event.

    I wrote an application where I catch when a sms is received and then processes it. When the device is turned on (and not suspended),  everything works fine.

    My problem occurs when the device is in a sleeping state (I can still receive phone call and text messages…). But when this event occurs, instead of keeping the device awaken, it just flashes the screen (for a few milliseconds), and then go back to sleep… It doesn’t  process the message.

    Then, if I manually wake up the device (by pressing the power button), everythings goes back to the normal state and my code is correctly executed.

    Do you know why I have this behaviour and how to fix it?

    Many thanks,


  49. MikeCal says:

    JeanB, there is a discussion on this in the comments of the Power To The PocketPC thread, specifically here:  http://blogs.msdn.com/windowsmobile/archive/2006/08/16/702833.aspx#744642

    You might also want to read the "Power To The System" entry to get a background for this: http://blogs.msdn.com/windowsmobile/archive/2005/08/10/450186.aspx


  50. Andrew Lewis says:

    Hi Mike,

    It’s almost a year, when my first attempt to force the ppc to sleep when an incoming call is detected, and I still have not found the ideal way to do this.

    Small ISVs like us would like to see more flexibility in terms of implementing software in the device we purchased and owned.

    Till this moment, am still trying various methods to force the device to sleep to conserve battery power by switching of backlight, and sending the device to sleep mode.

    My question would be, what other options do we have to do the above other than sending the device to flight mode, as doing so is equivalent to disconnecting the PPC phone from the outside world. Some implementation, voice answering machine, mini implementation of call centres etc from the phone would simply means impossible.

    We as the user/developer would like to see more and take advantage more from the capability of the phone in terms of its portability, processing power and phone capabilities. If the above is simply not possible, what other options do we have?.any way to send the reverse interrupt to send the power/backlight to off?. what are the ways to do so? (by studying the interrupts provided by the BSP vendor?. This may even kept confidential only to OEM partners)

    Any suggestions?



    When the system finishes waking up, it goes into the "Resuming" state.  In that state, the screen is off and the device will suspend again in 15 seconds unless something puts the system into a different state.  However, because it was woken up for a phone call, the cell radio driver notifies the phone app that a phone call is coming in, and the phone app puts the device into the "On" state and plays the phone ring sound.

    Because it’s hardware, not software, that wakes the system up, the only way to keep it from waking up is to disable that hardware.  For the phone, the only way to do that is to disable the cell stack.  And the best way to do that is to put the phone into flight mode.



  51. MikeCal says:

    I don’t understand what you’re trying to do.  You want the phone to ring and the immediately go back to sleep?  Won’t the user be frustrated that he can’t answer the phone?


  52. Andrew Lewis says:

    Hi Mike,

    PPC phone can be implemented in various ways.Applications can be developed in various scenarios and situations, such as PPC phone-based Call Centre Manager, such as a sales hotline, where the main PPC is installed with an application which handle calls, and route it to a specific phone number of sales agent/account manager which handle that customer account.

    To the customers, it would seems that they have a single point of contact number (PPC phone with the installed application).

    In this scenario, the ppc phone can also be used for other purpose, such as document management, etc. It is impossible to have the phone backlight lit up whenever a phone call is placed to the PPC phone. This will quickly drain the battery.

    The way we did it was to handle the call and power off the handset soon after the device wakes up. However, we still lost a few milliseconds and drain up some battery life when the device wakes up, few milliseconds (within a seconds) of lighting up the backlight and the application’s effort in switching off the power.

    It would be better to have a design which could provide some flexibility to the developer whether to wake the system up (and/or lit the backlight) when there is an incoming call.

    Thanks and Regards,


  53. MikeCal says:

    Okay, I think I understand what you’re doing now.  

    There’s no way for an ISV to guarantee that the backlight won’t come on for a few milliseconds.  The OEM has that ability, since it’s his driver, but there’s not enough hardware standardization to make it possible for ISVs to rewrite the backlight driver.  That said, many devices have a control panel that lets you completely disable the backlight.  If the one you’re using does, you can turn it off there, and not burn the milliseconds you’re concerned with.

    I believe the fastest way to get the screen to turn off is this.  As soon as your app detects the phone ring, first call:

    PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);

    Then call

    PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0);

    Now handle the call.  You need to be calling SystemIdleTimerReset(); every 30 seconds to keep the system from falling asleep while you’re processing the call.

    When the call is over, do:


    The first PPN puts the system into a state where, if the power button is pressed, it will turn the screen off but not suspend.

    The second PPN simulates the press of the power button.  Assuming the screen was on at the time, this will tell the system to suspend, but will instead go to the Unattended (screen off) state because of the first call.  (If the screen was off when you did the PowerButtonPressed, it would turn the screen on.)

    When you’re done with the call, the last PPN tells the system to suspend immediately (as long as there isn’t another app in Unattended).

    If you couple that with the control panel setting that completely disables the backlight, I think this will be your most power efficient way to do what you’re trying to do.


  54. Andrew Lewis says:

    I have tried the PPN before and backlight control panel settings in registry. However, due to the nature that the settings will only started kick in only if I emulate power off, on and then off the device again. Hence, this may not be fruitful, since the effort of the above far exceed the conservation of the power, unless, there could be some other way which I am not aware of.

    However, I am quite interested in venturing on rebuilding my own device drivers for cell stack, backlight, etc. Is there any information out there which I can refer to?. any pre-requisites on how to build my own device drivers? (such as getting to know the kind of hardware used, from which manufacturer, understanding the "MUX" which you have mentioned from the datasheet,etc).

    And also, is there anyway that two device drivers co-exist together for a particular piece of device?.

    Frankly,I have never developed any kind of drivers especially for Mobile devices, any online source which I can refer to?. (My guesses would be to study the sample from the platform builders, or others.) or perhaps these information are only limited to OEMs?.

    Another idea that came across my mind was,tapping into low level hardware interrupts and listen to whatever events occured, and report them back fast to the higher level application. Can I achieve something with this idea?.what are the pitfalls I may encounter?. and how can I achieve this from the Windows CE world?.

    Nevertheless, it is a very detail and fruitful explanation. I’m sure it will definitely benefit others.Thanks Mike!



  55. MikeCal says:

    There’s no sanctioned way to write your own drivers for other people’s hardware.  But there are some amazing people over on http://xda-developers.com/ that manage to do it anyway.  I’d say that’s your best place to start.


  56. christos says:

    Hello eveyone,

    Is it possible to configure WM5 registry keys so as to enable an application run in  suspended mode. In other words when the PPC goes to stand-by-mode I would like my application to keep on running.

    I have developed a Java application (runs with IBM J9) but when the PPC enters the suspend mode, threads pause and the application does not behave as it should do. My intention is not to completely disable suspend mode for the PPC, but just for an application (as it is possible to prevent e.g. the ‘sound device’ (‘wav1:’) from going to suspend mode, when the PPC goes to stand-by).

    The point is if you can achieve this by altering registry keys (setting a specific .exe for instance not to enter the suspended mode), not by having to write a C application to perform this !

    Thank you in advaced.

  57. MikeCal says:

    christos, when the system is suspendend, the CPU is completely shut down.  There’s no way to shut the CPU off and keep your app running.  The only way to keep your app running is to keep the system running.  Doing that, though, would be bad for battery life.  

    What does your app need to do that requires that it keep running all the time?


  58. christos says:

    It is a Java application that checks for name-days. When a nameday comes it informs the user.

    The user can define what time the reminder should check for namedays during the day. So if he choose 9.00am, the application will check for namedays at 9.00. Then there is a time-thread that counds x milliseconds so as to check for namedays next day (same time). In usuall phones the application works fine, without waisting too much battery. If I have to write a C application that wakes up the system every how often, then I presume that I should just forget Java…(what’s the point of writting 2 programs for the job of 1!)

  59. MikeCal says:

    christos, does Java have any mechanism for calling native APIs (in C# this is called PInvoke)?  There is an API call “CeRunAppAtTime” that does exactly what you’re trying to do.  You tell it, “Run my app at 9am tomorrow” and then exit your app.  At 9 am, the system will wake up and your app will run.

    CeRunAppAtTime uses the system’s Real Time Clock, which is the one clock that keeps running when the system suspends.  So, if you use it, you won’t have trouble with suspend.  It will also protect you against the user running too many programs and the system closing your app because it needs more RAM.  


  60. christos says:

    I think that you can call C from Java (99% sure) but since the Java application will be in suspend mode it won’t be able to call anything…I think that the solution to the problem unfortunatelly is

    1. create a C application that calls the Java (whenever the user specifies)


    2. disable suspendmode (bad for battery though).

    Anyhow, thank you veru much for your concern 😉

    all the best,


    <a href="http://www.geolos.com">http://www.geolos.com</a&gt;

  61. MikeCal says:

    Again, using CeRunAppAtTime is the right solution.  You run your app once, it calls CeRunAppAtTime and tells the system to run the app again at 9am.  Your app then exits.  At 9am, the system wakes up from suspend and runs your app.  Your app does what it’s supposed to do, then calls CeRunAppAtTime for the next day and exits.  The next day, the system wakes up again and runs your app.

    The kind of app you’re writing is precisely what CeRunAppAtTime was designed for.  And we have a number of apps in the system that use it to do what you’re trying to do.


  62. christos says:

    Thanks once again MikeCal,

     you’ve been more than helpfull.

    when you are saying that "…we have a number of …"

    do you mean that you have open-source example files that  use CeRunAppAtTime or documentation from where I can find out more information ?

    Thank you in advanced.

  63. Olu says:

    Hello Mike,

    You efforts are appreciated.

    1. How can one set an application to run on ‘wake-up’?

    2.The application has been written and compiled, and works OK irrespective.


  64. MikeCal says:

    christos, sorry, I’m not aware of any open source code that uses CeRunAppAtTime, but here’s a link to the documentation.  http://msdn2.microsoft.com/en-us/library/ms908103.aspx  I got there by going to msdn.com and typing "CeRunAppAtTime" into the search field.  You can also get at this documentation from Visual Studio if you type the function name into the documentation index.

    Olu, I’m not sure about the best way to write an app that runs whenever the system wakes up.  When I was looking up the MSDN article for christos I noticed a similar API called CeRunAppAtEvent which seems to allow for a wakeup event.  I’ve never tried it though.  If you use it and it does what you need, please report back.

  65. tbmvp says:

    Hi, MikeCal.

    I saw the comments between you and christos,

    i just want to know when my smartphone device has turned off by using the ExitWindowsEx(EWX_POWEROFF, 0) API, how could i boot my smartphone then.

    You said"when smartphone is off, nothing does.", so is there any API i can use for booting my sp, or there must have a hardware support.

    Thanks in advanced.

  66. MikeCal says:

    tbmvp, if you do a full shutdown of the phone, the only possible way to turn it back on is to press the power button.  At full shutdown, the CPU is completely powered off and no code can be running.  

    It would be possible for an OEM to design hardware to act differently, but I’m not aware of any that has.  Any solution to what you’re trying to do would either have to be a hardware one or one in which full shut down doesn’t actually shut the phone down.


  67. tbmvp says:

    Thank you for your answer, MikeCal

  68. Celesta Brown says:

    Dear Mike,

    I am the new owner of a pocket pc using Windows Mobile. When entering all day events, such as birthdays, anniversaries, etc. my pocket pc wakes me up at midnight to remind me of this all day event. This is true when entering events in the calendar mode and also when using the outlook option for entering birthdays. Can I change the default reminder time? My only solution until now has been to turn off the sound for notifications every night. Not the ideal solution. I would like to be reminded of these events, but not at midnight. If you can help, thanks.

  69. MikeCal says:

    Hi Celesta,

    I spoke with the calendar people about your problem (I’ve seen it too).  The difficulty we have is that the alarm times are coming from the Exchange server.  We’re just staying in sync with them.  We’ve had discussions with the Exchange team about this issue in the past and will continue to in the future.  

    There’s no simple workaround for you that we’re aware of (no way to set the default).  But, if you have a small number of these sorts of alarms, you can individually change the alarm times on them.

    Sorry I don’t have a better answer for you.


  70. Radek says:

    Hi Mike,

    I see it has been one year since you created this blog and you still answer questions. So, it would be great if you could answer mine too.

    Is there any way to prevent the Pocket PC from suspending without calling the SystemIdleTimerReset() function? If I perform an action which I do not want to be interrupted (like network communications) I need to call the PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE) function and periodically call SystemIdleTimerReset() function. But calling the SystemIdleTimerReset() prevents the system from switching into one of the OFF modes (the screen remains on or dimmed but still on). If I start calling the SystemIdleTimerReset() function after I receive the notification that the system is in the OFF state (bit POWER_STATE_ON cleared / I’m using the RequestPowerNotifications() function) it’s too late. Id does not prevent the system from going into suspended mode because the suspended mode comes right after the ON mode. Calling the SystemIdleTimerReset() in the ON state on the other hand is a waste of energy. How can I make the system switching into unattended mode when the system idle timer is timed out?

    BTW: Your blog and your comments have been a great help to my programming so far. Thanks.

  71. MikeCal says:

    Hi Radek,

    I’m glad the blog has been useful for you.

    The problem you’re describing is one of the many reasons we like the Smartphone power model better than the PocketPC one.  There is unfortunately no good way to do what you’re trying to do.  Time out to unattended and time out to suspend are on the same timer.  

    For your users, the half-solution is that after your app does the PowerPolicyNotify they can hit the power button.  So even though they can’t rely on the phone to time out after so long, at least they can make sure it does turn off.

    The half-solution for you isn’t much better.  You can simulate a power button press with PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0);  If you first enter unattended and then do that, the screen should go off.  But there are significant troubles with this.

    1) If the user is doing something ELSE with the device when your app does this, you’ll suspend it out from under him.  That would be annoying to say the least.

    2) If, for whatever reason, the screen is already off, simulating the power button press will turn it back on, which it the opposite of what you want.

    Not that I have a better solution for you.  If you DO go down this route, I suggest you only do it when your app has focus and you’ve noticed that the user hasn’t interacted with it for some amount of time.  That will lessen the chances of you turning the device off when the user doesn’t want you to.  Yes, you’re redoing work we should be doing for you, but that’s the way the cookie crumbles in this case.


  72. Radek says:

    Thanks for your prompt reply. At least I know it can’t be done and in good conscience I can finally stop searching the Internet for a solution. I’ve been looking for it for quite a long time.

    Forcing the users to hit the power button would be hard to explain. I was taught during one of the Microsoft’s DevDays by one of the lecturers that application users are "stupid, malicious and don’t read the documentation". 🙂 But seriously, I wouldn’t want to rely on the user actions because the character of the application I am developing requires not disturbing the users (car drivers, people working in the field, meeting customers, etc.). Besides, such actions are frequent so users would start to ignore it very quickly. So, as I see it I have three choices. Let the power be drained a little more because of the screen not turned completely off. The second choice is to accept the fact of occasionally messing up the transmission or other actions (I have also other portions of code in my application that when started should be run until finished). I expect many users would like the second choice more than the first even at the price of occasionally losing data. The third choice is following. I would be glad if you wrote your opinion or comments about this because it is indeed redoing the work the system should be doing.

    1) Read the "back-light turn off" time and the "device turn off" time – both for the AC and DC power supply – from the registry. I’m not sure if this is the safest method of doing this, but I’ve seen on many Pocket PC’s from different manufacturers it is correct:





    2) From the power notifications (PBT_POWERINFOCHANGE) I receive the information if the device is on AC or DC power supply.

    3) Subtract the "back-light turn off" from the "device turn off" time for the current power supply model and start counting this time from the moment the back-light is turned off (dimmed). If the back-light is off (dimmed) users don’t do any actions anyway. One potential problem is when the user sets a greater value for the "back-light turn off" time than for the "device turn off" time. I could execute the SystemIdleTimerReset() function when the back-light is fully on but there is no way I can detect if the user did something or not. There is no way of reading the value of the system’s idle timer counter as far as I know. So, I will ignore this special case.

    4) When the back-light is on but dimmed the flag POWER_STATE_ON + the string "backlightoff" is signaled in the power notification callback function. When the back-light is fully on the POWER_STATE_ON + "on" power state signaled. I won’t call the the SystemIdleTimerReset() function when the back-light is fully on. If the SystemPowerState member of the POWER_BROADCAST structure is for some reason other than "on" or "backlightoff" I will use the following C++ code:

    if (GetDevicePower(L"BKL1:", POWER_NAME, &State) == ERROR_SUCCESS)

    bScreenOn = (State < D3);


    bScreenOn = false;

    I’m noting this because I read in the Animatesample program ( http://windowsmobile.members.winisp.net/animatesample.zip ) that: "It’s possible for OEMs and future versions of the OS to change those strings". This should solve the problem to some extent.

    4) When I find the time is right (I use windows timers – function SetTimer() ) I force the system to go into suspended mode or to switch off by calling the PowerPolicyNotify(PPN_POWERBUTTONPRESSED, 0) function call you suggested.

    5) If the screen is already off, like you noted, I turn it back to dimmed. I see no other reason for this than any other strange application like mine did this. Here is the code to switch the screen back to dimmed:

    if (GetDevicePower(L"BKL1:", POWER_NAME, &State) == ERROR_SUCCESS && State > D3)

    DevicePowerNotify(L"BKL1:", D3, POWER_NAME);

    I don’t like this whole idea because it can disturb other programs. But I don’t see any better solution of the problem right now. Am I thinking right? Maybe you know a way of doing this better?

    Anyway, thanks for your great help.

  73. Kim says:


    MY application wakes up my PPC every once a while from the suspended mode to check some signals, I only need the wi/fi and CPU for the checking. And if the signal is detected, then I will fully wake the PPC. Otherwise, I will put the PPC back to sleep. I use CeRunAppAtTime to wake up the PPC. However, it wakes up the PPC fully. I know how to turn off the display, but I don’t know how to turn off others like audio. And BthSetMode does not work properly for my device.

    Thanks for your help.


  74. MikeCal says:

    Kim, you want Unattended Mode.  At the start of your application do:

    PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);

    And when you’re done, do:


    This is how ActiveSync does it’s "wake up, sync, and go back to sleep without the user knowing it" trick.  It will allow you to go straight to Unattended mode without turning on the screen.  However, your app will need to stop doing whatever it’s currently doing to turn the screen on (CeRunAppAtTime alone doesn’t turn the screen on).  

    Note that the user timeout is still in effect while in Unattended.  So, if you need to run for any significant amount of time, you still need to call SystemIdleTimerReset.


  75. Mike Lewis says:


    Great series of Power articles.  They have really helped me out!

    I have a problem with PPN_UNATTENDEDMODE and SystemIdleTimerReset():

    I have a thread that periodically makes wininet calls to fetch data from a URL. The fetch cycle takes about one second to complete.  My thread does the following:

    PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);


    fetch the data…


    This all works fine as long as the data is fetched at a rate of once a minute, or more.  Many of my users, however, need the data fetched every 30 seconds while their devices are ON, but at 30 second between fetch cycles the above causes their devices to never suspend.

    If I remove SystemIdleTimerReset(), the device could (and does) suspend in the middle of the fetch cycle, which cause the connection to crash following the resume.  Then we have to deal with messy time-outs and re-connections.

    I can solve this mess if I had access to the user idle timer.  Then I would simply skip the fetch if I see that the device is about to suspend soon.

    Any and all advise will be highly appreciated!


    Mike Lewis

  76. MikeCal says:

    Mike, you’ve hit one of the worst aspects of the PocketPC power model.  There’s no good way to solve your problem.  

    Unattended protects your app from the user hitting the power button.  If the system is on, though, you’re right that any sort of frequent call SystemIdleTimerReset will keep it from suspending.  I’d expect both the 1 minute and the 30 second calls to keep the system awake (the default user timeout is 3 minutes).  

    Unfortunately, I don’t know of any way for you to get access to the user timer (other than to reset it).

    If your users press the power button, things will work correctly (you’ll suspend as soon as you leave unattended, even though you reset the idle timer).  But your app is going to make it hard for their device to time out on its own.


  77. Mike Lewis says:

    Thanks Mike for you response.

    I’m not very happy to run into "one of the worst aspects of the PocketPC power model".  At the very least give us access to the user idle timer… hint, hint…

    How about working around this problem by tracking the backlight off timer.  I assume we can figure out when the backlight goes off (say using a timer to poll GetSystemPowerState) and mark that time. Now if we can get the backlight off setting from the registry, we can calculate approximately when the device will suspend.  Knowing approximately when the device will suspend, we can skip our refresh cycle if we’re within a few seconds of suspending.  Will this approach work?

    Two questions:

    1.  For WM5/WM6, can I detect when the backlight goes off with GetSystemPowerState?  If so, how?

    2.  What is the registry key for the backlight timeout?

    Thanks again,


  78. LarryD says:


    First this blog post is awesome. I have a Sprint Mogul running WM6. I love it except for two little things.

    First, I don’t want a reminder to wake it up. I only want the reminder to play its sound and flash the light. So I turn off on screen notifications for reminders. That did the trick for tasks; however calendar reminders still wake it up and display on screen. This of course caused a lot of problems if I have the machine in my pocket or in the holster. Many times it gets bumped and starts calling the last person I talked to. I know this Pocket Outlook and might not be your area. So if you can’t answer it can you direct me to someone that can?

    Second, it randomly wakes up for no apparent reason. Is there an event log or something I can look at to see what caused it to wake up?

    Thanks for your efforts


  79. MikeCal says:

    Larry, the only solution I’ve ever found for the "it turns on in my pocket and changes things as the screen gets rubbed" is to activate the keylock.  Of course, that means you need to unlock it every time you turn it on.  

    There is no event log that explains why its turning on.  On a previous Sprint device, that happened whenever you moved from an area of no signal strength back to an area where you could get a connection.  The OEM did this on purpose for reasons I disagreed with, but I was unable to convince them it was the wrong decision.  I’m not sure if they made the same choice on this new device as well.


  80. Fabien says:


    Is there a way to programmatically power off my PocketPC? I mean i want to completlety power off my PPC (in order to really save my battery for some days).

    Previously, i had a HTC TyTN that provided me this functionnality by pressing 2 seconds the power button. Can i do this by API on other PPC?

    Thanks for your response.


  81. MikeCal says:

    Unfortunately, no there’s not.  PocketPC’s don’t have an official mechanism for completely powering off.  Some OEMs have provided their own mechanisms, but it has always been OEM specific.  

    Smartphones, on the other hand, do have a full power off option and a programattic way to do it.  For a smartphone, you call ExitWindowsEx with the EWX_POWEROFF flag set.

  82. Salil says:

    I have to develop simple use case by which i can have my Windows Mobile functionality working while display is off.e.g.Running of Songs on Windows Media Player while the Display is off.How i can get its value from regitry.What is the value for say




  83. Salil says:

    I have to develop simple use case by which i can have my Windows Mobile functionality working while display is off.e.g.Running of Songs on Windows Media Player while the Display is off.How i can get its value from regitry.What is the value for say




  84. MikeCal says:

    Salil, which of these questions are you asking?

    1) How do I write an app that is notified when the screen turns off?

    2) How do I write an app that keeps running whether the screen is on or off?

    3) How do I write an app that turns the screen off and keeps running?

    4) How do I write an application that keeps the screen from turning off?



  85. Andy says:


    Thanks for your blogs.  All of the info you’ve provided in these "Power" articles is great and very helpful.  I do have one question about something that seems to be incorrect.

    In one of your comments you said "you’ll suspend as soon as you leave unattended".  Are you sure? From what I have seen this is not the case.  What happens seems to be that the system goes into suspend at some later time (possibly the time configured as the idle time).  I believe what I’m seeing is correct and it would be designed this way, because suspending the system immediately would cause other inherent problems, which I can explain if needed.

    Anyway, please let me know if what I’m seeing is really how it’s supposed to work (I think it is), or if it SHOULD really be suspending as soon as unattended is left, as you indicated.



  86. MikeCal says:

    When the system wakes up, it is guaranteed to run for the length of the Resuming timeout (15 seconds unless the OEM changed it).  So, if you wake up, go into the Unattended, and leave in less than 15 seconds, you’re right that the system won’t suspend immediately (it’ll wait until the 15 seconds complete).  On the other hand, if the system has been on longer than the resuming timeout, then it will suspend immediately when you leave unattended.

    Is that what you’re seeing?


  87. Andy says:

    This resuming timeout may be what I’m seeing.  I’ll have to look at it a little closer to be sure.

    If this is the case, I’d like to ask about the use of unattended mode.  Please look at the following description of a background thread that needs to wake up to do something every once in a while and tell me if this seems like normal use of unattended mode.



     Turn on unattended mode and start some thread to reset idle timer every 30 seconds


     while (true)


       Stop the thread that is resetting idle timer and turn off unattended mode

       Wait for some event (keyboard, RTC, radio) that can cause the system to wake up

       Turn on unattended mode and start some thread to reset idle timer every 30 seconds


       do processing




     Stop the thread that is resetting idle timer and turn off unattended mode


    Is this a normal use of unattended mode?



  88. MikeCal says:

    Yes, that sounds like a fairly normal use for unattended, so long as the "Wait for some event" part is actually a Wait and not some sort of busy loop.  

    The primary user of Unattended mode is an "always up to date sync" app (like Active Sync).  When you tell your device to sync every 5 minutes, AS does a CeRunAppAtTime, enters unattended at start, syncs the data (while resetting the idle timer as necessary), sets the next time for wakeup, and exits unattended.

    This does three things.

    1) If the system was suspended, sync will run with the screen off (neither Resuming nor Unattended turn the screen on).

    2) If the system was suspended, it won’t stay on for any longer than Sync needs it to (modulo the 15 second Resuming thing).

    3) If the system was running, and the user hit the power button to suspend it during the sync, sync would be able to finish getting its data before allowing the system to suspend.

    As for the "don’t suspend until the resuming timeout completes" part, that wasn’t the original design.  When WM5 first shipped, if the system was in unattended, and the last app left unattended (the refcount went to 0) the system suspended no matter what.  The trouble we found was that an OEM needed to use unattended for a high priority event that happened VERY quickly.  The result was that there was a chance for the system to wake up for both a normal app and the high priority thing at the same time.  The high priority thing would run first, get in, do it’s job, and get out before the lower priority app had a chance to run.  So the system would suspend and the lower priority app never ran.

    By moving it to the resuming timeout, we largely fixed the problem.  It’s still possible for a high priority app to run non-stop for 15 seconds and starve everything else, but that’s uncommon.  And, if someone were to write something like that, we could reasonably tell them to fix the 15 second CPU hog.


  89. Andy says:


    Thanks again for your help and the background information on the resuming timeout.  That makes perfect sense.

    Yes, the wait is a "wait for some event" and not a busy loop.

    Given the thread example above, and the fact that the device can (and will) suspend as soon as unattended mode is released, there seems to be a potential problem with the use of unattended mode.  As soon as the thread turns off unattended mode, the device can suspend BEFORE the call to wait for the event that can pull it back out of suspended mode.  This would mean that the system is suspended indefinitely until something else pulls it out of suspend, as the thread did not reach the place where it would be waiting for it’s event.  Is there something that prevents this from occurring?



  90. Tim says:

    Hi Mike,

    As with many others on this thread, I am frustrated by my WM6 phone that is frequently activated due to inadvertent ‘touches’ of the screen that occur subsequent to the screen waking up due to a calendar reminder. There should be an option under Power Options, Sounds and Notifications:Reminders, or Calendar that would provide an option to not force the screen to activate for the meeting reminder.

    If you know of a work-around or have an application that would disable wake up of onscreen meeting reminders and calendar events, I would be most interested.


  91. jezza says:

    Hi Mike,

    yup very good article, and am also impressed at the responses that have been provided.

    Below is a comment from your blog I would like to discuss.

    "There was a time when the PocketPC turned on at midnight and shined its backlight all over your bedroom, thus waking you up with him.  Now he’s smart enough to not turn the backlight on for his midnight excursions."

    At midnight my device wakes up and the backlight comes on with my WM6 device.

    I have been told that under Programs > System Configuration I can disable the "Wakeup Enabled" option to prevent this from occurring, but was wondering if you knew of a way that I could achieve this programatically – Ie registry key or API function – so that I can avoid doing this manually on 90 of my clients devices!

    Much Appcreciated


  92. Indeed power to the people..

    It seams all devices wm2003 and wm2005 have wakeup problems with alarms / clocks / reminders

    Now without having to hardboot my PDA (then will loose some registred car-driving software)

    Has it ever been solved this iseu

    Or are thos problems simply ignored.

    (it’s hard to ignore dough, just check google how many problems there are out there in the "real" world, in this subject)

    I gues al such events are eventualy somewhere stored in a DB where to clear them all

  93. Hezi says:

    Hi Mike,

    Excellent thread here.

    Question (WM5): I have an application that needs to check on some RIL event every 3 or 10 seconds (implemented through timer control). I’d like to keep the application running all the time, though I don;t care the screen shall turn off. When some criteria is met, the application shall turn the backlight ON.

    My question- In such case where the timers are pretty short (3/10 seconds) would you still suggest entering the UNATTENDED mode make sense? Or is it better to leave the Power ON all the time (with force) and just turn off the screen?

    How would you approach those requirements?

  94. Hezi says:


    After going (succesfully) to UNATTENDED mode, I am applying the next two lines in the code. However, the backlight does not come ON and stay dimmed. What am I missing here? (I tried to turn the backlight ON also without going out of the UNATTENDED mode, but with no good).

    PowerPolicyNotify((int)PPN_Message.PPN_UNATTENDEDMODE, 0);

    DevicePowerNotify("BKL1:", CEDEVICE_POWER_STATE.D0, POWER_NAME);


  95. leoyu says:

    Did not see my comments i posted yesterday on this thread so posting again.

    I have an app that runs on smartPhones and is supposed to run at a time specified by the user thru a GUI on the device. The app is using CERunAppAtTime(app, time) to set the RTC alarm.  A few users have reported that the app does not run at the specified time and they have to re-set the time thru the GUI to get it to run again at the specified time.  

    I was able to get a hold of a smartphone device (which is a BlackJack) from a user who reported the same issue.  When I got the device, I advanced the system clock 10 minutes before the schedule run and it did not happen.  Then, i reset the time thru a GUI on the device, advanced the system clock and i saw the app ran.  

    It looks to me the RTC alarm settings were gone in the above incident.  Has anyone encounter this before ? If i want to look at the alarm settings, can anyone recommend a way to do it, API etc?



  96. Alexandre says:

    Hello, i think that you can helpe me. My device is a Ubiquio 401. This thevice have a bug that when is in suspend mode( turn power button off), it have GSM issues(phone stay off). How to solution it???


  97. Andy says:

    Mike seems to have left this discussion after I pointed out a bug with the use of unattended mode in late November.  Sorry for ruining it for everyone else.


  98. Over the years, I’ve delivered several “Top 10” sessions and called them different things. Top Snafus,

  99. alcedes says:

    On a device running Windows Mobile 5 Professional I ran a simple program that sent the key press messages for the power button a few times with delays between the messages.  Upon running it I see the device turn on and off every few seconds until the program completes.  This suggest that my Windows Mobile 5 phone is using an Always On model.  Can you confirm this?

    for(int i=0;i<4;++i)






  100. MrPotter says:

    Joel,i got the same result.after Sleep(5000) timeout,the ppc will auto resuming from suspend.i have no way to keep ppc always suspending while in Sleep API.

  101. robert says:

    hello to everybody,

    I have this issue that i’m sure is related to the power module:


    I have a problem with the suspend wake-up procedure. I’m using the sam9263 with wince 6.0R2. I’m using a key button to wake-up the system.

    I put in suspend mode the system using the menu start->suspend,

    1) if I wake-up the system within about 20-30 seconds everything works  fine

    2) if I wake-up the system after 30 seconds the system hangs:

    KeyPadPowerOff customclass


    resetting RTT to delay rollover





    OALPowerWakeSource enable 17





    —–system hangs —–

    any ideas?

  102. bob says:

    hello to everybody,

    I have this issue that i’m sure is related to the power module:


    I have a problem with the suspend wake-up procedure. I’m using the sam9263 with wince 6.0R2. I’m using a key button to wake-up the system.

    I put in suspend mode the system using the menu start->suspend,

    1) if I wake-up the system within about 20-30 seconds everything works  fine

    2) if I wake-up the system after 30 seconds the system hangs:

    KeyPadPowerOff customclass


    resetting RTT to delay rollover





    OALPowerWakeSource enable 17





    —–system hangs —–

    any ideas?

Skip to main content