| Date: | June 14, 2012 / year-entry #138 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20120614-00/?p=7373 |
| Comments: | 62 |
| Summary: | Up until Windows XP, applications could intercept the WM_QUERYENDSESSION message and tell Windows, "No, don't shut down." If they were polite about it, they would also inform the user which application blocked system shutdown and why. And if they were really polite about it, they would even provide a way for the user to say, "I... |
Up until Windows XP, applications could intercept the As I noted some time ago, Windows Vista made it harder for applications to block shutdown. Applications are given two seconds to clean up, and then it's game over. Okay, now the game of walls and ladders continues. The power management folks created an escape hatch for applications which are doing things like burning a CD or controlling an industrial lathe, where shutting down the machine may not be in the user's best interest. (The user ends up with a coaster or a factory on fire.) But since they created the escape hatch, they get to control the keys to the hatch, too. The Mind you, these blocks are merely advisory. If users really want to create a coaster or burn down their factory, they can click Force shut down. One nice thing about making Windows responsible for the warning message is that if multiple applications want to block shutdown, all of them can be displayed in a single dialog, and the user only needs to click Force shut down once. Further guidance on system shutdown and the use of these functions can be found in the Application Shutdown Changes in Windows Vista document, which was the source material for most of this blog entry. |
Comments (62)
Comments are closed. |
"As I noted some time ago, Windows Vista made it harder for applications to block shutdown. Applications are given two seconds to clean up, and then it's game over. "
I'd call it: "WIndows Vista made it harder for users to let the applications proceed with shutdown". If an application (MS Word or Excel) is displaying Save File prompt, the user CAN NOT see and dismiss it. The only option is to cancel shutdown. That's SO HELPFUL (not exactly).
The new way seems much better than the old way to me.
Now you know which process is responsible, it gets a chance to tell you why, and you can choose what happens next.
Taking away a much-needed function that was abused, then making a back door because it turned out to have very necessary uses. End result: completely pointlessly breaking backwards compatibility. If a WM_QUERYENDSESSION keeps saying no, it should have automatically registered ShutdownBlockReasonCreate.
[Um, it does register it automatically: It puts the program name on the list of applications which are blocking shutdown. -Raymond]
With a 30 second kill-timeout. CD Burn takes 3 minute. Industrial lathe crazy long. Guess which program's least likely to be updated.
@Joshua If a user wants a machine shutdown they can just yank the power. The occurrence of somebody doing something critical like CD burning/Lathing and deciding here is the perfect point to shutdown, is probably massively less than people who's laptop battery died because a program decided it was too important to stop. The user chose to shutdown not Windows.
@Lex: "The occurrence of somebody doing something critical like CD burning/Lathing and deciding here is the perfect point to shutdown, is probably massively less than people who's laptop battery died because a program decided it was too important to stop."
Of course, those are just an extreme. Something like "I did work on this document and forgot to save it" is much more likely than the latter, at least for me. Considering I think I've had my battery die because it didn't shut down all of.. well, I think never.
Personally, "save?" and similar dialog preventing shutdown/log off is one of those behaviors that I actually much prefer about Windows vs other systems. If we were all in some super-happy world where all apps could easily restore their state things would be a little different, but we're not there yet.
@Lex Mitchell: Windows can shut itself down automatically if it's allowed to auto-apply updates. Or the owner company's IT department could push out a series of updates which require a restart and give the go-ahead to restart the machines, possibly accidentally including the industrial lathe that then sets the building on fire. Or some other Super Important Application could decide to shut the machine down.
There are lots of reasons that a machine might try to restart, and the local user isn't directly responsible for all of them. Or even necessarily present.
[Wait, which side are you on?]
If I could pull any arbitrary old version of Windows from the archives, buy license, install and run, I wouldn't have to care about Mr. Industrial Lathe either as I'd hand him the old Windows and call it good.
The upgrade treadmill is obnoxious.
The API doc says "For Desktop Apps" only. Do we have such back door for services also? One would imagine that an industrial lathe program does not necessarily have to be a Desktop App.
Vista forced me to developed a program which sends WM_QUERYÂENDÂSESSION to each app. And waits. I love it.
A few weeks ago I forgot to close VirtualBox beforel shutting down Windows 7. When I came back the next day, I was presented with a regular "waiting for shutdown" dialog with no particularly special message, and VirtualBox's normal "what do you want to do" dialog. I haven't tried to reproduce it, but this seems like the sort of thing that shouldn't be happening (VirtualBox should auto-save the machine state, not leave my computer on 8 hours overnight).
It's very nice that Windows 7 finally gives the user better control over the shutdown process when he's chosen to shut down. I really like that. But that just makes the years-old behavior of Windows Update look even worse by contrast.
You have no idea how many times I've come back from lunch, or from taking a shower, or some other interruption that kept me away from the computer for a moderate ( >15 mins) length of time, only to find that Windows Update has arbitrarily decided to reboot in the interim, and now I've lost everything I was working on. (It's also happened on occasion while playing a fullscreen game, because the warning dialog doesn't show up.)
This should never happen under any circumstances, particularly if any program has any reason whatsoever to not want to shut down, such as unsaved files. The computer belongs to me, not to Microsoft, and it should reboot when I say so, not when Windows Update does. Period. The notion of "implied consent" does not apply here.
And unlike the behavior of a normal shutdown or reboot, for some bizarre reason, when Windows Update does it (even in Win7,) you can't cancel it. You don't get the warning. And you can't even hit Win-R and type "shutdown -a" to cancel it. (You get a dialog box informing you that this program can't start because the system is shutting down. Did Microsoft get Joseph Heller to write the shutdown code or something?!?)
Theoretically there's a registry setting you can tweak that will make Windows Update never reboot the system without your consent. I've done it. It still happens. And given the data-destroying nature of this behavior, I'm a bit surprised that it hasn't prompted a class-action suit yet. You'd think, with a potential class comprising "everyone who has ever lost data to Windows Update," that Microsoft would have fixed this behavior waaaaaay back in Win98, but it's still there…
(Third time trying to post this. Broken blog software is broken.)
Also, why do people complain about Windows Update auto restarting? You can disable the auto restart behavior without turning off automatic updates. Just merge:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
I've heard the "Windows Update has rebooted against my will" complaint so often that I feel like I'm taking crazy pills. Am I really the only one who knows about "download updates automatically, but let me choose when to install them"?
If you assume that any update will require a reboot right after being installed (which is honestly not far from the truth) then the choice to trigger updates yourself seems obvious. You don't let Windows Update do the updates itself, because then you're essentially saying "reboot at will". Instead of letting the system pull the trigger and then keep running ahead of the bullet, just pull the trigger yourself, when it's convenient.
(To those people who say "I might forget to click the little shield, my system needs to be kept up to date" — well, you can't have your cake and eat it too. You should be happy the system reboots automatically to help you meet this goal, which is lower on my personal list than "don't throw away my session".)
@Mason Wheeler: "This should never happen under any circumstances, particularly if any program has any reason whatsoever to not want to shut down, such as unsaved files."
Personally I believe programs should start saving a document or file after the user has worked on it for a while. System shutdown is not the best time for saving files.
When Windows made it harder to block shutdown, someone broke the SetConsoleCtrlHandler function…
Our GUI application creates a console window via AllocConsole and uses the SetConsoleCtrlHandler function to register a HandlerRoutine callback for handling the CTRL_C_EVENT and CTRL_CLOSE_EVENT notifications. When these are signalled we would return TRUE to let Windows know it needed to ignore the signal and just after we would call FreeConsole to close the console window, the purpose was preventing the entire application closing when the user closed the console.
The problem started with Windows 7 when they broke the SetConsoleCtrlHandler function to stop some applications that created a console window from blocking shutdown but by doing so they broke the callback…. If the user clicks the non-client Close button or right-clicks the Taskbar and clicks Close, Windows ignores the result of the HandlerRoutine callback, closes the console and terminates the entire application – why they broke something unrelated to the system shutdown is unknown but here's nothing the user or developer can do to stop it, which is great since it broke so many legacy applications that relied upon the (previous) documented behaviour.
So how do you stop a console created by AllocConsole in a GUI process from killing your application when clicking the non-client Close button or clicking Close from the Taskbar since the SetConsoleCtrlHandler callback result is ignored?
xpclient wrote:
Oh good. I withdraw my complaint:
@dmex: Have you tried calling FreeConsole from inside the handler?
What I want to know is why was the Windows Update dialog nag period in Windows XP set to 11 minutes? Not 10 minutes, not 15 minutes, but 11 minutes. I guess Windows Update goes up to 11? At least the "Reboot Later" button had the focus so you didn't lose your work when you're typing and the nag dialog steals focus. Windows 7 experience is much better.
@Mason Wheeler
I don't know what to tell you. Those settings to disable the auto-reboot has worked fine on all the machines I have ever work with. Although, I usually apply the "NoAutoRebootWithLoggedOnUsers" one through the Group Policy MMC plugin (pointed at Local Computer), rather than directly in the registry. Maybe there is some extra magic that just poking the registry isn't doing.
@JM: When I used that setting inevitably I start an update then do something with my computer. By the time the update is done and wants to reboot I'm in the middle of something important. Then it proceeds to pester me to reboot for the rest of the day while I'm using my computer. It'd be far more convenient to get back to my computer, see that an update was installed and then and there close everything and reboot on my own.
Though now I've learned of NoAutoRebootWithLoggedOnUsers — I'll try that out tonight.
Maybe industrial lathes shouldn't have been controlled by Windows in the first place.
Not that I'm saying Windows is bad, but I'm sick of everyone using desktop OSs for everything (we've all seen screens on billboards or ATMs with the "you need to update your antivirus" message popping).
people complaining about apps shutting down system, just remove SeShutdownPrivilevge from the user, problem fixed. windows supported this forever. the current system is not perfect, but vista->windows 8 provides much better experience than xp & earlier.
It's one of XP misteries we may never know the answer. Like what was rationale behind "the search puppy", "desktop cleanup wizard double nag", and a few other such things.
[@dmex: Have you tried calling FreeConsole from inside the handler?]
That's how we've always handed the message since ~Win95, the problem is Windows 7 ignoring the result of the callback and terminating the console & application anyway.
This is our callback:
static BOOL ConsoleHandlerRoutine(
__in DWORD dwCtrlType
)
{
switch (dwCtrlType)
{
case CTRL_C_EVENT:
case CTRL_BREAK_EVENT:
case CTRL_CLOSE_EVENT:
{
fclose(stdout);
fclose(stderr);
fclose(stdin);
FreeConsole();
// We're still terminated when Close is clicked on the console window's window menu.
return TRUE;
}
}
return FALSE;
}
It makes sense to prevent applications using the CTRL_SHUTDOWN_EVENT or CTRL_LOGOFF_EVENT from preventing Windows shutdown but – why did they have to break CTRL_CLOSE_EVENT at the same time when so many applications depend on it?
There was a dialog that showed up but it was removed (or broken?), some others run into the same problem here with no solutions: stackoverflow.com/…/c-setconsolectrlhandler-routine-issue
"we've all seen screens on billboards or ATMs with the "you need to update your antivirus" message popping"
What should they use instead? Keep in mind these users/developers probably aren't specialized embedded developers… You shouldn't need to be just to display some simple information.
@Mason Wheeler: "This should never happen under any circumstances, particularly if any program has any reason whatsoever to not want to shut down, such as unsaved files."
The trouble is, too often the program's main reason is that it was written by an idiot. (It probably also has a splash screen, systray icon, shortcut on the desktop, background process holding DLLs open 'to speed up app startup', and an automatic updater you can't disable).
The fix is clearly not to run such things, but sometimes it's unavoidable.
@Dave: Why is that a problem? If anything, it will cause the system to err on the side of not rebooting without the user's explicit consent, which is a good thing.
@Mason Wheeler:
The other half of the population complains that they shut down their laptop, and then walk away, and return hours later to find the battery dead.
Why? The laptop didn't shut down, because some app with an open file prompted the user to save the file. The user never answered the prompt, so the laptop never shut down.
When you say "This should never happen under any circumstances, particularly if any program has any reason whatsoever to not want to shut down, such as unsaved files. The computer belongs to me, not to Microsoft, and it should reboot when I say so" there are people who say "Windows should shut down when I ask it; programs should NOT be allowed to block shutdown. It's my computer, and if I ask it to shut down, it should shut down."
Maybe there should be a distinction between a shutdown requested by auto-updates, and a shutdown requested by a user, but Microsoft has tried to make both camps happy. And that's not possible. Note that a partially-updated system is running with a mixture of old code and new code, and the two don't always agree on what parameters to pass when calling each other, which leads to hard crashes. So it's in your interest that the system reboots soon after applying updates. I think that the option "Download updates, but let me choose when to install them" is YOUR best choice.
"Note that a partially-updated system is running with a mixture of old code and new code"
I'm pretty sure that Windows updates are independent and atomic. If an update requires a reboot, it has not been installed yet, even partially. That would be foolish.
Patches that will be installed at next reboot is queued in registry.
It would be foolish to develop any app that is depending on any state of this queue, yes.
Yet, after some months, there's usually junk files all over the place because of broken installations.
i think of it like making your program "standard user friendly". The machine is trying to shutdown, yet your program is sitting there displaying a modal dialog. The application needs to be updated to not do that.
Until then, i have a global kill-switch that "fixes" those misbehaving programs until they are fixed (like file and registry virtualization "fixes" those misbehaving programs until they are fixed).
Then, why isn't NOTEPAD.EXE fixed yet?
@alegr1
I think Windows needs a better shutdown experience for older apps. Older apps don't know about ShutdownBlockReasonCreate and expect to be able to prompt you at shutdown. Right now there's no way to interact with these applications except canceling shutdown which defeats the purpose. There needs to be a way to temporarily hide the shutdown UI to respond to these applications.
Also the easiest way to configure Windows Updates is though the Group Policy Editor. From there you can configure all aspects of Windows Update. For instance I set Windows Update to automatically install updates but not to automatically restart and to install updates that don't require restarts immediately.
Why oh why would anyone ever run an industrial lathe on a Windows OS?
I still think that the fact that any program can programmatically call shutdown without user confirmation in Windows is a very bad behavior. Just the other day I had dozens of tabs open in IE, couple of other things open and downloads going on and I added the "Media Center" key to Windows 8 and it restarted without any warning. (I didn't have ShutdownGuard installed on that fresh Windows 8 installation). Usually, I always use ShutdownGuard which calls the above mentioned ShutdownBlockReasonCreate function. ShutdownGuard even lets the *user* customize the message that is displayed. And with Classic Shell, I can call any custom Shutdown actions on the Start Menu (e.g run a script to silently exit ShutdownGuard first and then call restart or whatever, so shutdown actions from there when I as in the user initiates it are all 1-click. No unnecessary confirmations.
Btw there is a Group Policy that can be enabled in Vista/7/8: "Turn off automatic termination of applications that block or cancel shutdown."
Evan: "If we were all in some super-happy world where all apps could easily restore their state things would be a little different, but we're not there yet."
@Evan: At least Windows beginning with Vista has a "shutdown.exe /g" switch that calls the EWX_RESTARTAPPS flag so apps which registered for application restart all automatically get restored after the restart. Unfortunately, not even all Microsoft apps register for ARR. A core app like Notepad doesn't! Google Chrome does. I don't know any other 3rd party apps that register. And sadly their state is not restored necessarily.
@640k
Maybe someone depends on that behaviour? (This is a joke by the way, but it wouldn't surprise me).
@Miff
Did you read the last link that was in the main post? If it is a non critical shutdown, if an application has a visible top level window and it returns FALSE to the WM_QUERYENDSESSION, then it will block the shutdown regardless. But, the difference here is that the Windows Vista changes means that you get told which application is blocking shutdown, and you have the force shutdown button available which does a critical shutdown.
The reason string is required if an application doesn't have a top level window and is trying to block shutdown for some reason. So this is useful if a console application, or a hidden application is being used to block shutdown without allowing the user to close it easily.
The new shutdown procedure is a cure that's worse than the problem. On Vista+ every time an application needs to prompt before it can shutdown, I have to cancel the cancel the shutdown. And the application can't even fix it by doing things the new way since the new way doesn't allow for prompts. To solve a problem that for most people doesn't even exist, a change was shoved down users' throats that evidently didn't undergo even basic usability testing.
@xpclient: Yes, I've done that. It still happens.
@JM: Yes, I've done *that* too. IT STILL HAPPENS!
And my point is that not only should it not happen when you've changed the settings, you shouldn't have to go tweaking settings to make it not happen in the first place. *Not happening should be the default.*
Maybe (maybe!) there should be a way to opt-in to automatic reboots, but even that's stretching it a little, because most systems that are meant to run unattended are servers, and you definitely don't want them going down without notice!
I highly doubt that Microsoft doesn't do basic usability testing. I believe instead that said usability testing showed that most people close their documents before shutdown, so "Are you sure you want to quit without saving?" dialogs would be rather rare and shutdown would most often be blocked by applications that need to be terminated with extreme prejudice.
Raphael:
Are you aware that Excel will prompt to save the document even if you only switched to a different page?
@Jack: Why did Iran run their uranium enrichment centrifuges on Windows 7?
Where is this so-called "30 second timer" then?
I have a terrible integrated sound card. Sometimes, when I shut down my PC, one of it's background processes stops responding. More then once, I've left my PC thinking it was shut down, only to come back to it hours later discovering that it was still on, waiting for the **Windows not responding dialog**.
If ShutdownBlockReasons are opt in, then how come they apply to a Windows dialog telling you that it had to kill a process anyways?
@Mason Wheeler: Why is that a problem? If anything, it will cause the system to err on the side of not rebooting without the user's explicit consent, which is a good thing.
That suffers from the fallacy that there is always an *** in the seat.
en.wikipedia.org/wiki/Brain_drain#Iran
@Rapheal: I thought that Raymond had a post in the last few months on why a system needs to be rebooted soon after update, but I can't find it now.
I think the DLLs that are not in use will get replaced during installation of the update; they don't get "deferred until the reboot". But if they get called by code that didn't get replaced yet, things can break.
@People thinking running a lathe on Win 7 is stupid
(Sorry if this is a duplicate post, I'm pretty sure my last one got eaten)
There is a lot more to industrial automation than boring boxes with little text-only displays and tiny keypads.
I develop software for controlling industrial equipment. The high-end controllers run Windows Embedded Standard 7, a componentized version of Win 7. It gives us plug-and-play printer support and built-in network share support. Transactional NTFS is great for recovering from power interruptions. There is good touch screen support. Customers understand the Windows application look and feel. We can use VNC and remote desktop.
Linux could do most of this, but not as easily. A lower-level embedded system wouldn't work.
We don't enable Windows Update by default, and let our customers and their administrators find the best settings if they want it on. Because we can eliminate all parts of Windows not needed for our application, the attack surface is much smaller. Most updates only affect parts of Windows that aren't even included with the system.
while MS is worrying about legitimate behavior, spyware or viruses are still able to do everything they want to regardless of what the winapi says or does.
@Mike:
What is it in *x OS that makes it more secure and immune to spyware and viruses than Windows? Explain, please. Or STFU.
Windows 7 shutdown my game in the middle of an extended play session without any warnings of any kind.
Damn you for giving a better gaming experience than linux.
@Diablo 3 player: Can't be much of a gamer if even after more than a decade you still didn't get the memo to turn off automatic reboot. Really just turn it off (i.e. only install when user gives ok whatever) when you get a new PC and that's it – also recommended for all people who leave their PCs running unattended.
@Evan You never click "shutdown" on your notebook, then close the lid and put it away? Well ok with sleep working fine for the last few years I haven't done that either, but it used to be a real problem under XP back in the day
Who shuts down their laptop when it's not plugged in and then walks away from it?! I'm either in a controlled location like my home or office and plugged in, or in an uncontrolled location where I'm not going to leave my laptop unattended. Not saying that MS shouldn't do anything to appease that half of the population, but maybe something else like "if the system is trying to shut down for more than a couple minutes and it is not plugged in, then hibernate" would be better. But that seems like way too complex of a policy to hard code…
@dave: "That suffers from the fallacy that there is always an *** in the seat."
No it doesn't. Part of the argument is that if there's *not* someone there, then they didn't authorize the shutdown and it shouldn't happen. You may disagree with that, but I think both positions are perfectly reasonable.
@raphael: "I'm pretty sure that Windows updates are independent and atomic. If an update requires a reboot, it has not been installed yet, even partially. That would be foolish."
The reason that the reboots are required in the first place is so Windows can update files that are in use and locked. How can the system tell if a file is in use before just going for it? My understanding then is that an update may or may not require an update depending on what's currently running!
(I guess the system could try to grab locks on all the files and only if that succeeds, do the update.)
@algr1: "Are you aware that Excel will prompt to save the document even if you only switched to a different page?"
Um, what Excel? 2007 didn't in my little test I just did.
@voo: "@Evan You never click "shutdown" on your notebook, then close the lid and put it away? Well ok with sleep working fine for the last few years I haven't done that either, but it used to be a real problem under XP back in the day "
Ah, I guess I can see that. I basically don't ever click shutdown, only sleep/hibernate/restart. I've realized that in the past, but that fact's applicability to this situation didn't occur to me.
"The other half of the population complains that they shut down their laptop, and then walk away, and return hours later to find the battery dead."
I'm firmly in that camp; for a while, I was infuriated by my own (non-Windows) laptop failing to suspend when I shut the lid. It would appear to sleep, go quiet, turn off the screen … then 20 minutes later, standing on the train home, I wonder why my back is getting uncomfortably hot. (If I remember correctly, the graphics driver was actually crashing during the sleep attempt, livelocking as a result. Not nice. Graphics drivers do seem to be the culprit in far too many problems these days!)
If a Windows shutdown breaks your lathe and burns the building down, is that equipment safe to use at all? How will it handle a plain old system crash (which of course terminates the lathe control program without the slightest warning, let alone the seconds Windows gives), hard drive/power supply/fan failure …
@jas88, blame Vista/7/8 for it. When hibernating, they don't show the progress bar. For notebooks that don't come with any LEDS and have minimal design, it's hard to tell the OS hibernated fully and powered off. I ranted about it but the Windows team no longer listens as everyone knows: social.msdn.microsoft.com/…/35c0b733-878e-4a13-9a26-6e08bb5e6dc6 It takes a while to hibernate systems with 16GB RAM.
Any application that still prompts for a user to decide whether or not to save work when a shutdown message arrives is, quite simply, doing it wrong. Disk space is cheap. Automatically preserve the current state and resume it when the app is next open. And if your app has been running for more than about two seconds since it last saved state, it's setting itself up to lose the user's work anyway.
We really ought to have moved on well beyond these kind of silly trivial issues a long, long time ago.
@xpclient: A progress bar is pointless. Once the user has initiated a hibernate by closing the lid (or indeed in the UI after reviewing the blocking app dialog), the system should hibernate. Nothing short of a unexpected power failure midway through writing the disk should prevent it. The progress bar is a solution to entirely the wrong problem.
The watchdog turns on the crowbar circuit, causing about $10,000 damage. Now if we actually lost
power, this is a non-issue for the obvious reason.
Andy, given a choice between "making it always work" and "showing a progress bar so we know when it's done", I'd prefer "making it always work", but assuming that isn't possible, I'll take the progress bar.
@xpclient: "blame Vista/7/8 for it. When hibernating, they don't show the progress bar."
I seem to recall reading that the screen is turned off to save power. The justification is that it could be the difference between a successful hibernate and a failed one due to power loss. This is especially likely because hibernate is often triggered as a response to critically low battery levels, so not much power is generally remaining when it's done. So while you complain about the lack of a progress bar, others would complain that it was using unnecessary power.
My last laptop was a Lenovo with a sleep LED that would blink while it was hibernating. I'd wait until it stopped blink it, then pack the laptop to avoid any shock to the hard drive. Now that I have an SSD, I don't even worry about that. That's when I hibernate – usually I suspend…
Yeah, once the PC I was using was upgraded to an SSD, I turned on safe suspend (sleep+hibernate) and never looked back. Though I could switch to a full hibernate model since resuming from SSD is pretty damn fast. Might not even be measurably slower, either.
"once the PC I was using was upgraded to an SSD, I turned on safe suspend (sleep+hibernate) and never looked back"
My problem with that is I'm dumb and I suspend the computer when I wasn't ready yet, so I have to immediately turn it back on. That is:
I forgot to <insert important task that only takes 5 seconds to do>, because I'm absent-minded. Probably I remember it while the computer is still suspending.
I immediately resume the computer.
I do the task.
A minute later, I suspend again.
If I did safe/hybrid suspend, wouldn't I have to wait for the hibernate to finish writing to disk in step #3 before I can resume from suspend? That would annoy me. It would be nice if there was a way to abort the hibernation and just resume right away.