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.
Guess what, the shell already has support for skipping rundll32 and giving you the dll name: ASSOCF_REMAPRUNDLL
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)
I don’t see why this is so surprising. If a shell extension hangs, then that causes Explorer to hang. (And of course a shell extension that hangs is already misbehaving.)
Of course you’re going to blame an extension and not those who desgined shell extension interface.
40 years later and they still aren’t sandboxed nor do they run in a separate process, not to mention that Microsoft is again abusing its monopoly position and internal knowledge by making UWP file explorer extensions packaged as inbox apps (starting with Windows 11 24H2) and giving them system privileges that other vendors’ UWP store apps can’t ever hope to get.
Re: “mother process”. There is no such thing in many cases. Many shell extension points use or even require in-process COM servers, so the extensions run in the Explorer process. When Explorer calls an in-process extension, it’s subject to the extension’s mercy.
Since Explorer houses the extensions I’d think it takes them out behind the barn after a certain grace period. It’s the mother process after all.
But then some extension developer would probably come crying when the extension gets shot down.
You really can’t win there.
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...
Even worse, what happens when the executable name is "rundll32.exe" or similar? By the time you're getting into windows without titles blocking shutdown, you're getting into the domain of buggy software - and there's no guarantee that buggy software is buggy in the right sort of fashion.
Similarly, showing you that "C:\Windows\System32\rundll32.exe" is blocking shutdown isn't going to help identify the application; you could try showing the full command line, but what if the DLL that got invoked by rundll32.exe modified that (which it is allowed to do), resulting in the DLL name not being in the command line?
And worse, if...
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...
You failed to fully read the problem.
The apps affected in question didn’t call ShutdownBlockReasonCreate.
They didn’t “not follow the documentation” by not providing the handle to a main window when calling it. They just haven’t called it.
It’s a helper window in the application that’s hung for some reason.
Rodger that, good point.
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..