We’re all in this together, as far as the Blocked Shutdown Resolver (BSDR) is concerned.
If a program blocks the WM_
QUERYENDSESSION
or WM_
ENDSESSION
message, then it goes into the Blocked Shutdown Resolver screen. That much is obvious. What is perhaps less obvious is that every other window that hasn’t yet replied to the message also goes into that screen, even if they aren’t the ones that are blocking shutdown.
The system sends the shutdown messages to each window in turn. If a window blocks the message, then not only does it prevent shutdown (for a time at least), but all the other programs which haven’t yet received the WM_
QUERYENDSESSION
message are also prevented from receiving it. As a result, all those other programs also go into the BSDR, not because they are doing anything wrong (yet), but because they are stuck in the queue behind the bad guy and therefore could potentially block shutdown in the future.
I assume the theory here is that it’s better to list everybody who could potentially cause a problem, rather than just listing the one who is causing a problem right now, only to frustrate the user when they resolve that problem, only to have a new window show up on the list. Shutting down the system would turn into a game of Whack-a-Mole.
Programs typically block shutdown if they need extra time to clean up (for example, closing a database or disconnecting from a server), or if they need to ask the user what they want to do with unsaved data.
If you click the Shut down anyway button in the Blocked Shutdown Resolver, then the system gives up waiting for responses from WM_
QUERYENDSESSION
messages and proceeds with shutdown. The programs that were asking questions will never get the answers, and you may end up with a corrupted database or unsaved data.
If you click Cancel, then the shutdown is canceled and you return to your desktop. You’ll want to click this button if the program is asking you a question that needs to be answered before it will permit shutdown to continue, typically a “Save changes?” dialog.
If you do nothing, then the system will automatically click the Shut down anyway button after a few seconds.
The Blocked Shutdown Resolver was added to address the common problem where you go to the Start menu, click “Shut down”, and then walk away from the computer or close the lid to your laptop. But then you come back to your computer some time later, and the shutdown got stuck because some application got stuck cleaning up or simply rejected the shutdown request, so your computer never shut down at all. In the case of a laptop, this exhausts the battery, which is really frustrating because you’ll pull out your laptop some time later so you can start doing some work and discover that the battery is dead.
One phenomenon you may observe in the Blocked Shutdown Resolver is that of programs gradually disappearing from the list. This is the flip side of the “If one program blocks shutdown, then all programs block shutdown” principle. As each program receives and responds to the WM_
QUERYENDSESSION
message, it disappears from the list.
Just because a program is on the list doesn’t mean it’s being bad. It may be on the list because it is still waiting its turn.
> If you do nothing, then the system will automatically click the Shut down anyway button after a few seconds.
As mentioned by many this seems to be not the case.
One question that could be figured out by experiments, but I'll ask anyway: Do apps receive , or is that postponed until Shutdown anyway or Cancel is chosen or all apps approve shutdown?
> As each program receives and responds to the message, it disappears from...
“If you do nothing, then the system will automatically click the Shut down anyway button after a few seconds.”
Realy? What is AutoEndTasks registry?
I really dislike that the BSDR notification is now full-screen always-on-top – on XP you could navigate to the blocking program and resolve the problem, which would let the shutdown continue normally, nowadays this isn’t possible any more.
One of the problems with the BSDR is, once it appears and is canceled, all the already properly marked as restarting programs are removed from the restart manager list.
Say you have Visual Studios and a text editor open, and one other program, that blocks via MessageBox or similar. Once Visual Studio has properly shut down the blocking program triggers the BSDR. Choose cancel, and answer the blocking question. Now triggering shut down again, the Visual...
"If you do nothing, then the system will automatically click the Shut down anyway button after a few seconds."
Why does it seem like that's not always the case?
Best example is Notepad. Basic, windows built-in Notepad. If I have an unclean Notepad session open, the BSDR will stay open forever, until I either cancel and deal with Notepad(by saving or closing), or hit "Shut Down Anyway". Since I tend to use Notepad sessions...
This reminds me of old PowerBooks/iBooks where it was common on classic Mac OS to for example drop into MacsBug during an attempt to go to sleep when the lid is closed, often causing hardware (such as the display) to be damaged.
People are asking about the order of shutdown, but my question is whether the order is specific (by design) or does the shutdown process not care? I had a case a few times when after pressing Cancel it brought me back to windows with explorer closed (it was an RDP session). I would figure "the desktop" would be specifically kept for last in case of cancelling. Luckily alt+ctrl+del (alt+ctrl+end) let me start task manager, which...
What order does Windows ask programs to shut down?
SetProcessShutdownParameters looks relevant, but I did not try.
“the system will automatically click the Shut down anyway button after a few seconds” seems incorrect, as I think I recall that screen staying visible for several minutes. I also recall it clicking the Cancel button automatically – or more precisely me walking back to the computer after several minutes and seeing the desktop with no BSDR screen on it. But it also might have changed in recent versions.
Why does it ask each program in turn, pausing for an answer, instead of asking them all, even if one blocks?
Windows asks them all. Please re-read the last two paragraphs again.
It asks them all… eventually. It only asks one at a time though, and waits for an answer from that program before asking the next program. I’m asking why it needs to happen serially instead of concurrently.
In addition to the remark about programs that rely on the serialization, you also have the problem where you click "Log off", and then a dozen apps all fight for attention to display their "Save changes?" dialogs. One wins the fight and the other 11 lose focus. It's easy to deal with the first one, but you now have to chase down all 11 of those other windows in order to shut down. (In serialized...
Because that’s how it was initially done and now some inane program depends on this.
It doesn’t even take much of a stretch to come up with a scenario for this. Consider two programs that work together, like a database and a front-end UI. The database relies on the UI to do the “Exit without saving?” prompt, and it shuts down immediately in response to the shutdown request, on the assumption that the front end already approved.
Btw, even if there exists programs written in such configuration, IMO it would need to handle the case of “database” process crashing while “UI” is still running.
Can “database” process be respawned during shutdown?
But in that case, how does Windows know which order the shutdown requests should be sent? Was it the database program that launched the UI? Was it the UI that started the database? Was it some launcher program that launched them both in some unknown order? I don't see how asking programs in sequence solves this problem. Without first-hand knowledge of exactly what is depending on what, you could end...
@Michael Taylor: If a windows update and/or a new Windows release breaks existing applications, users don't care that the app broke because it was implemented incorrectly. In the best case scenario, publishers will fix their apps...but they usually won't do so unless fixing their applications can be financially justified.
Raymond discusses this on https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41363 . Replacing "why not just block the apps" with "why not just let apps break" does not really change the...
"The order of notifications is not documented, but people have reverse-engineered and relied upon it."
If it is undocumented then that means it can change at any time. Therefore you can change this without being responsible about breaking anybody. It was their choice to rely on undocumented features. This is a risk they took.
Stop leaving "issues" in Windows just because somebody somewhere may have relied on the implementation that wasn't documented. This doesn't even make sense....
The order of notifications is not documented, but people have reverse-engineered and relied upon it.