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

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

xpclient — Tue, 29 Nov 2011 16:14:43 GMT

@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.

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

Nick — Mon, 28 Nov 2011 20:42:29 GMT

"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?

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

xpclient — Mon, 28 Nov 2011 14:57:57 GMT

@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.

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

Crescens2k — Sun, 27 Nov 2011 14:02:35 GMT

xpclient:

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).

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

NB — Sat, 26 Nov 2011 17:18:50 GMT

@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 ;)

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

Joshua — Sat, 26 Nov 2011 17:12:02 GMT

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

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

xpclient — Sat, 26 Nov 2011 11:00:44 GMT

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.

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

Horst Kiehl — Fri, 25 Nov 2011 21:42:43 GMT

@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: blogs.msdn.com/.../9193695.aspx

By the way, this reminds me of this post: blogs.msdn.com/.../5465592.aspx

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

voo — Fri, 25 Nov 2011 17:54:12 GMT

@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.

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

Ooh — Fri, 25 Nov 2011 17:17:37 GMT

@xpclient: Ah, you refer to Raymond's "The checkbox: The mating call of the loser"

blogs.msdn.com/.../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]