How can I extend the deadline for responding to the PBT_APMSUSPEND message?

A customer observed that starting in Windows Vista, the deadline for responding to the PBT_APMSUSPEND message was reduced from twenty seconds to two seconds. Their program needs more than two seconds to prepare for a suspend and they wanted to know how they could extend the deadline. The program communicates with a device, and if they don't properly prepare the device for suspend, it has problems when the system resumes.

No, you cannot extend the deadline for responding to the PBT_APMSUSPEND message. The two second deadline is hard-coded; it is not configurable.

The whole point of reducing the deadline from twenty to two seconds is to ensure that when users press the Sleep button on their computers, the computer actually goes to sleep reasonably promptly. If there were a way to extend the deadline, then you're just reintroducing the bad situation in Windows XP where the user hits the Sleep button on the laptop, but the laptop just sits there taunting you. Meanwhile, the flight attendant is standing there getting angrier at you for not putting your laptop away. (Or worse: You tell the laptop to Sleep and toss it into your bag, and then when you reach your destination, you discover that your laptop is really warm, and the battery is dead.)

Besides, imagine if ten apps did this. Your app asks for ten extra seconds, another app asks for another twenty seconds, next thing you know all the deadline extensions add up to five minutes.

The real solution is to fix the driver for this device so it can prepare the device properly when it is told that the machine is about to go into a low power state. (The two-second limit applies to applications but not drivers. At least not yet.)

Comments (33)
  1. Anonymous says:

    Huh? The real WTF is "Why the heck is the device depending on a userspace program to properly prepare it for suspend?!?"

    To parapharase Charles Babbage, I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a situation.

  2. Anonymous says:

    Ah, re-reading your last paragraph, I realise I read it as "…so it can prepare the device properly when it is told [by the userspace program in question] that the machine is about…", whereas you probably acutally meant "…when it is told [by the kernel] that…" – which I then needlessly restated.

    Next time: think twice, post once.

  3. Anonymous says:

    "Your app asks for ten extra seconds, another app asks for another twenty seconds, next thing you know all the deadline extensions add up to five minutes."

    Wouldn't the deadline extensions apply in parallel? The end result would be the longest deadline extension, not the sum of all them. You could even have a limit for the deadline extension ("the default is 2 seconds, but they can extend to up to 20 seconds").

    "The real solution is to fix the driver for this device so it can prepare the device properly when it is told that the machine is about to go into a low power state. (The two-second limit applies to applications but not drivers. At least not yet.)"

    Not all hardware has its own device driver. It could be a serial dongle. It could be using a common USB driver (for instance, a common USB-to-serial converter like a FTDI), so they cannot change the driver (else it would affect all USB-to-serial converters of the same brand). It could be based off a external bus like CAN or RS-485, where the driver is for the bus and not the device. And so on.

  4. Anonymous says:

    Remind me to not use Windows for life-critical software.

  5. Anonymous says:

    "Remind me to not use Windows for life-critical software."

    No need. It's already in the EULA?

  6. Anonymous says:

    @Joshua: You would be so far away from supported territory you wouldn't see even Mt. Everest should have it been there…

    (You would need there realtime system anyway, which Windows are not.)

  7. jmthomas says:

    Not that you (Raymond) have any influence in the matter, but I gotta vent.

    Two second is pretty harsh.  

    Did the decision makers consider that there may be mechanical action, not just electronic action, required?  Sorry, didn't get time to part the heads.

    Also, with poor response time being tolerated by so many (Why does my windoze machine that ran OK out of the box now take forever?), plus the cost reduction and bloat in microcode (often written by EEs, not SEs), even "all electronic" devices may not normally respond in 2 seconds.

    Opps, didn't get enough time to write the whole 2G buffer to this slow flash memory chip inside me. Sorry, I'll need a hard reset by human hand before I will work again.  But you'll not know until you diagnose why I stopped working correctly after the restart…

    Then there's network connected devices that will have to put out messages to stop their attachments at 300 baud…

    And hard coding a critical constant in windows?????   Raymond's time machine must exist!  Old things are being brought back from the past!

  8. jmthomas says:

    The argument about curing the problem where a laptop hastily shoved into a bag which never goes to sleep is bogus.

    This problem is not about the timeout, it is about ending processing.  If the 20 second timeout really worked, the laptop would remain powered up in the bag for only 20 seconds.  Not a problem.  The most this new timeout change would do is cut 18 seconds of battery use.

    But the laptop is taking forever to turn off.  Something is hanging, and the timeout is not recovering from the hang.  Doesn't matter if the hang is in the device, the driver, the kernel, wherever.  The watchdog timer is working to force a shutdown.  Doesn't matter if the watchdog is set for 2 or 20 seconds, it isn't barking or biting viciously enough.

  9. Anonymous says:

    @HiTechHiTouch: I think Raymond is using the term "hard-coded" here in a slightly different sense than you may be used to.  He doesn't mean it's hard-coded into the source code, where you have a magic number floating around in source without a cogent variable name; rather, he's referring to the fact that it's not configurableā€”there is no INI setting, registry key, or system call than can be used to change the limit.  It's hard-coded into the compiled binary of Windows and cannot be changed at runtime.

  10. Anonymous says:

    One of my pet peeves with Vista/7/8 IS that PBT_APMQuerySuspend event is not broadcast to apps so they cannot return Broadcast_Query_Deny to deny the sleep or hibernation transition. Only automatic sleep or hibernation can be prevented by resetting the idle timer using the SetThreadExecutionState function. In Windows XP, both automatic and manual sleep and hibernation could be blocked. Due to the Vista design, it also means, for example, if some mischevious app simply calls shutdown.exe /h the system will hibernate without confirmation.

    Or another disastrous decision to remove the hibernation progress bar in Vista/7/8 and just turn the screen off and it becomes a nightmarish experience when you just want to shove the thing in the bag and be confident that it hibernated successfully and wasn't hung.

  11. Anonymous says:

    As an end user, I love the stringent 2 second limit. It would be even better if this also applied to device drivers. My Win7 laptop is sometimes bad about going to sleep when it's docked, saying a device is in use, despite the only devices attached to it being the monitor, the ethernet cable, and headphones.

    On XP, my cell phone's tethering software would actively block me from putting my laptop to sleep, putting up an absurd dialog box. This was a horrible user experience. I'm not sure if they still do it on 7.

  12. What @Leo said. As a user mode app you are a guest on the system. Breaking Windows features because you're not willing to pay your taxes is a problem.

  13. Anonymous says:

    Nice back door for when the *hardware* can't sleep in 2 seconds no matter what the software does.

  14. Anonymous says:

    XPClient at 11:41 AM – Raymond has covered this before.…/533250.aspx

    This post can probably be taken to append to the old one, "… and five years later the problem still exists, and Microsoft is trying to limit the extent to which the user's day can be ruined, even if haste-oriented developers are inconvenienced in the process."

  15. Anonymous says:

    I would like it to be 0.2 seconds. Why should I accept bloated software/hardware junk? xp was far to nice to crappy software/hardware. I just want it to do what i tell it to. Turn off -> turn off NOW! Not in 20 seconds, that's bullshit. If windows accept crappy drivers, guess what users gonna blame?

  16. Anonymous says:

    Only 2 seconds?

    On most Windows machines I've used it will take more than 2 seconds just for my application to page back in…

  17. cheong00 says:

    @HiTechHiTouch: Think about it: Windows hibernation file is usually 2GB+ yet it can meet the 2 second limit. Yet for device cannot write 2GB data to internal flash which should be way faster than harddisk. Do that make sense?

    If you device can't write within time limit, you'd better write operation data on flash at the same time as you write them in memory on board.

  18. Anonymous says:

    @Joshua: Ok, let's do it now before I forget: don't use Windows for life-critical software, *you* would end up in jail as you would have put people's lives at risk by not choosing a piece of software validated for these scenarii.

    By the way, what kind of life-critical software do you develop that is able to sleep/hibernate?

  19. Anonymous says:

    Couldn't mechanical action be solved with capacitors for most Windows-type hardware? Or a wood-fired steam engine?

    Also, even worse than a warm laptop is Swissair 111  (not that a laptop had anything to do with that incident).

  20. jmthomas says:

    @Adam Rosenfield — Net's the same if you use #define or 0x02 or whatever way you want to instruct the compiler.  

    Personally, I'd expect this magic number to be set up (or a initialized value replaced by something from the registry) at the beginning of device setup.  (I've no idea internals really works, but experience says there's almost certainly a way).

    @cheong00 — You haven't seen cheap flash pushed hard.  Cache overflow, the reuse tracking algorithm overhead, bad lines to relocate (flash doesn't last forever, flaky ones with lots of manufacturing defects grow new defects fast), and some just won't let you write more than a few consecutive cycles.  

    If someone wants to make a high volume consumer item, they will gladly choose the worst performing chip when it saves them any money.  $.25 x 50,000 is $12,500, all gravy.  Consumers will wait 30 seconds for a device to turn on, so performance is not a design consideration.

    I've got a older French 2G thumb-drive that will only accept large amounts of data at 110 MBS.  My internet connection is faster!

    @It's Friday. — FWIW, hard drives used to use circuitry (with caps) to park the heads.  Then someone observed that software was cheaper than hardware…

    PS: Our development group briefly considered a wood-fired steam engine, but it made things too hot for the hamster! (grin)

  21. cheong00 says:

    @xpclient: The idea is that most applications (that do not interfere with hardware directly) have no reason to delay sleep. Since we have hybrid sleep on Vista and above, the applications shouldn't worry about not able to save data to harddisk on time.

  22. Anonymous says:

    I think in this case a user checkbox on whether to enforce the time limit or not should have been the perfect solution. For those who just want sleep to occur without any interruption, XP was too liberal to allow programs to deny or delay standby/hibernate and for those who don't want Windows to lose their non-resumable download or burnt DVD because they accidentally hit the sleep button, Vista/7/8 is too restrictive because *it has no option NOT to force it*. And you can still delay log off/restart/shutdown in Vista/7/8, why not sleep?

  23. Anonymous says:

    If I'm not mistaken it's 2 seconds for *each* application to respond and the device should be prepared by the *driver* to hibernate, not user space software, where this limit does not apply.

    For user space 2 seconds should be plenty.

  24. Anonymous says:

    @xpclient: Ah, you refer to Raymond's "The checkbox: The mating call of the loser"…/9416485.aspx

    [It's worse than that. Once you let the value be configured by the user, you it becomes possible for an application to configure it programmatically, and then you're back where you started. -Raymond]
  25. Anonymous says:

    @xpclient You're aware that as soon as there is a user configurable feature you also make it MUCH more likely for applications to programmatically set it?

    If you really constantly hit sleep accidentally, then a popup dialog asking "Are you sure?" would be a much more sensible solution than this feature from the past. But then I just don't see this as a major concern for lots of people so -100 and so on.

  26. Anonymous says:

    @xpclient: If it's really a concern that the user "accidentally hit the sleep button", you can configure the sleep button to do nothing – or cover it with a molly-guard. It's much simpler, and closer to the problem, than to still allow "awesome" programs to tell the OS "don't do what the user told you, let me continue".

    It's similar to what Raymond has explained before, that you shouldn't make global changes to solve a local problem:…/9193695.aspx

    By the way, this reminds me of this post:…/5465592.aspx

  27. Anonymous says:

    Anything that can cause data loss and which cannot be blocked by the user is flawed by design. For example, there is no way in Windows to block any of the shutdown functions if initiated using shutdown.exe. Malware can simply run a 'shutdown -l' at startup to keep the computer in a log off loop as soon as it logs on. There is no UAC requirement either for shutdown.exe. None of the APIs to intercept shutdown work against shutdown.exe.

  28. Anonymous says:

    @Nawak: you don't support sleep/hibernate. The code that I was imagining would block it by extending the deadline to infinity.

  29. Anonymous says:

    @xpclient: If you have malware only calling shutdown.exe at startup you're very lucky! Otherwise it might have decided to snoop your passwords and credit card numbers instead ;)

  30. Anonymous says:


    Adding a UAC requirement to shutdown.exe makes no sense since standard users are allowed to do all operations that it performs by default on client versions of Windows. It also would block shutdown.exe being used in scripts (and I have a few of them) so it isn't a good idea.

    Also, while it may be possible to remove the fangs from shutdown.exe, it would still be rather trivial to write a program which is just as bad by using the ExitWindowsEx function and forcing the actions with that.

    I would also have to double check, but shutdown.exe has a /f parameter that causes the shutdown/logoff to be forced, so that would imply that it doesn't force (and thus make it unblockable) unless you add the /f parameter. So this would mean that regular use of shutdown could be blocked.

    But anyway, blocking user logoff is a bad idea and should never be undertaken unless it results in nuclear meltdown or people getting killed. Would you feel happy if you shut down your system and went out, only to come home hours later to find that your shutdown had been blocked because your web browser is asking if you want to save your tabs? That is potentially data loss after all. Most of these "data loss" situations are a result of bad programming. If an application requires more than 2 seconds to save its state then it is likely that it is just keeping too much unsaved data around, or it is a server process for something and would be better as a service. If a logoff also results in data loss then it is also very likely that the application wasn't written robustly, since it would pretty much mean that there would be data loss if the application crashed (or the user clicked End Process in task manager).

    If an application is trying to write to a slow medium (like a WebDAV share) and the user logs off (maybe they forgot that they were writing to it) then again, that isn't a good reason to block logoff. What you would do in that situation is make sure your temporary files are properly up to date and then cancel the write and somehow set a flag so that the next time you start that application it tells the user that they logged of before the write was complete.

    To be honest though, this would end up (for me at least) in a situation where either a badly written application may lose data, or will lose data. I have a funny habit of just clicking on the force button if I logoff or shutdown my system and an application is taking too long. If it does it too often then I would most likely investigate, look for a solution or at worst just uninstall it. I have low tolerance for bad applications after all. Another thing to remember, on a laptop the battery is low and Windows starts the emergency hibernation, should it be allowed to block in this case? (Another example of a choice between possible data loss and definite data loss).

  31. Anonymous says:

    @Crescens2k, the app I use, ShutdownGuard blocks most automatic shutdowns, restarts and logoffs by default and lives in the tray. This way no installer or Windows can force a shutdown unless I approve of it. In those rare cases when I have to do scheduled or remote shutdowns or use scripts, a single click on the ShutdownGuard tray icon "unlocks" automated shutdowns so it won't be blocked any more. Unfortunately, there isn't a way for it to circumvent shutdown.exe's -f (force) switch. I have also added a UAC requirement to shutdown.exe using App Compat Toolkit. Note that this just blocks those shutdowns which are initiated programmatically/without user approval. I can still force a shutdown any time. But I guess for regular users, this would be an overkill of shutdown protection.

  32. Anonymous says:

    "Unfortunately, there isn't a way for it to circumvent shutdown.exe's -f (force) switch."

    That sounds like it's working as intended, then.  Users should have control over their computer, and that means they should be able to shut down if they want to.  Imagine if the force option was cancellable — what then?  Should the computer be held hostage by a poorly written or broken program?  Or maybe Microsoft should add a –ok-im-serious-really-force option?

  33. Anonymous says:

    @Nick, but that same switch can be called by any app or update installer that think it's cool to restart without warning. Windows cannot differentiate between automated and user-initiated shutdown, that's the problem. I have lost data many times over the years before I started using ShutdownGuard.

Comments are closed.