If you try to shut down Windows, and there’s a program that is not allowing the shutdown to proceed, then the Blocked Shutdown Resolver (BSDR) shows a list of windows that includes the one that is processing the shutdown notification, as well as the windows who are waiting for their turn to process the shutdown notification. For each window, the information looks like this:
| 🎼 | Contoso Composer | ← Window title |
| Burning a CD | ← passed to ShutdownBlockReasonCreate |
|
| ↑ | ||
| Window icon | ||
The program controls all the parts of the presentation. The description comes from the window title. The icon come from the window icon. And the subtitle comes from the string that the program passed to the ShutdownBlockReasonCreate function.
If the program did not call ShutdownBlockReasonCreate, then a generic system-provided string is used like “This app is preventing shutdown” or “This app is preventing you from restarting.”
But why is the description sometimes blank? Who would create a window with no title?
Programs often create windows that they never intend to show to the user. It might be a helper window that exists to receive messages or to act as an anchor for positioning another window. Since the program knew that the window would never be shown to the user, it didn’t bother giving it a title.
Except that the Blocked Shutdown Resolver shows the title.
And if the title is empty, you get a blank string.
So, programmers, give your windows useful titles, even the ones you never thought would be shown to the user.
On rare occasions I have Explorer showing up in that list. No active shell operation (e.g. copy dialog), and no mapped network drives which could time out.
How can that be? A shell extension maybe? But those should by definition completely obey Explorer (wishful thinking)
Using a process name isn't much more helpful then the window title. To someone reading this blog post it might make sense but to a typical user it won't. Process names may not have any relation to the actual application (e.g. vss.exe, devenv.exe, conhost.exe). Furthermore Windows, by default, doesn't even show file extensions for known files so if an end user wanted to "find" the executable then they probably wouldn't be able to find it.
Given a process name, determining what app it goes with requires heuristics. Showing the file path could be one option. The hope here is that either...
Is there any way to make Windows shutdown become restart, or restart become shutdown, either through code or system configuration?
@Raymond Why, pray tell, is Blocked Shutdown Resolver even considering windows without title instead of say falling back to owning process name?
Somebody would have to implement it. And that’s not going to happen.
I agree that you should always give your windows titles, even if they are not to be shown in the GUI. This also helps during debugging, may be good for accessibility reasons, etc.
I also agree that the OS should use the executable file name or something similar in case of no window title. (Is there any particular reason that makes such a fallback unfeasible?)
Reading the documentation of , I note that should be "[a] handle to the main window of the application."
But shouldn't the main window of an app always have a title? Or are people simply not following...
Yes! Please! This has plagued me for so long with some random background helper oem junk refusing to let my computer ever restart cleanly. The icon is just the default mfc one too, which also isn’t any help. Please just tell me it’s ManufacturerAudioHelper.exe or whatever, so I can remove that thing from my system and complain to the developers!
For the purpose of showing what’s blocking shutdown, showing an empty string to the user hardly seems useful. I would have expected the Blocked Shutdown Resolver to fallback to something like the executable name or at the very least /something/ useful to the user..