shutdownBlocker.exe is simple program that intercepts & blocks shutdown / restart / logoff commands. It protects from user mistakes, poorly designed installers (those lacking a 'restart later' option), and even windows itself (looking at you, 10).
It works by registering a ShutdownBlockReasonCreate() reason and objecting to WM_QUERYENDSESSION messages. It can optionally be set to consume all calls to shutdown.exe and MusNotification.exe (among other things, this blocks Windows 10 Update restarts); but this requires running the app as an administrator. A full rundown on how this stuff works is below the changelog.
.NET Framework 4.0 or better; Get it from Microsoft.
Unpack the app to a folder; run it. (A settings file will be created in the program folder.) Then click the Block or Allow button.
If you wish to block shutdown.exe or MusNotification.exe restarts (to suppress Windows Update restarts), you will need to run the program as an administrator. As of v1.2 We automatically ask the OS for this (you'll get a UAC prompt); The app will also warn you if it's not been run as an admin.
The program must be kept running to work. You can send it to the notification tray by using the 'Hide' button, the escape key, or if upper right close button. Optionally you can hide the tray icon (in settings) for completely invisible operation.
You can have the program start up automatically via a check-box in settings; this uses a scheduled task for auto-start. Remember though, if you move the app, you should re-create the scheduled task (Uncheck 'start with windows', hit ok, then check it again).
Command Line Usage:
If an instance of the program is not already running, starts the program and immediately hides it.
Starts the program and enables blocking.
Starts the program and disables blocking.
Some folks have asked how to uninstall... To do so, run the app, and in settings do the following:
Make sure "Start with Windows" is unchecked.
Make sure "Add shortcut to Start Menu" is unchecked.
Then you can quit & delete the folder the app is in. That's it. Uninstalled.
(Really, this is about the same amount of work as going through an uninstall wizard from the control panel.)
Version 1.2.2; 2017-03-08
- Added: Hibernate command added to right click menus (tray menu and general app right-click menu)
- Changed: tweaked some build options.
- Changed: systemsettings code moved to debug mode, seems like it's no longer needed in new builds?
Version 1.2.1; 2016-11-29
- Fixed: Quitting without hitting 'allow' could have left some blocks active. Now quitting should unblock everything.
Version 1.2; 2016-11-25
- A couple fixes to elevation (admin rights) should prevent unblocked shutdowns: Our app now asks for the highest privileges it can get. UAC prompts abound, but this way we ensure all blocking options are available. Next, to ensure automatic starts happen with the highest privileges the "Start with Windows" method was changed to use task scheduler. This method requires an initial run-as-admin to invoke; But should automatically elevate afterwards. Also: To work around a windows bug (notification icon sometimes not shown), we wait 30 seconds after log-in to start our app.
- Added: Context menu options to shutdown or reboot immediately. Context menu is now also available by right clicking the main app.
- Changed: Some UI fluff was updated. Mostly they way we store window position.
- Fixed: Working on Windows XP.
Version 1.1; 2016-03-24
- MusNotification.exe intercepts added.
- SystemSettings.exe closer added. In windows 10, SystemSettings.exe goes into a suspend mode when it's not in use. This would be fine, but there are a bunch of bugs associated with this behavior, like delays (due to timeouts) when global hotkeys are pressed. So we now close systemSettings.exe if we see it suspended. What does this have to do with shutdowns? Nothing, but this project was open when I needed to fix the issue.
Version 1.0; 2016-02-02
- Initial Release
Notes on Blocking Windows Shutdowns
There are four generals cases/kinds of shutdown that I know about, with increasing difficulty of handling each...
Standard User & Application triggered shutdowns: The old way of blocking these was to process WM_QUERYENDSESSION messages in your message loop and return false on them. Newer versions of windows more or less ignore this; but fortunately they also introduce a much superior api for blocking: ShutdownBlockReasonCreate / ShutdownBlockReasonDestroy. Easy to use and nicely baked into the shutdown UI. No trouble there.
Local shutdown.exe calls: These will ignore both the blocking methods above, so special handling is required. The AbortSystemShutdown() function will abort a shutdown triggered via this method, but:
- I cant find a way of being notified of when a shutdown.exe shutdown has been triggered. So knowing when to call AbortSystemShutdown() is problematic. But even worse:
- AbortSystemShutdown() works only if the shutdown is given a positive timeout. By providing a 0 second timeout and using the force parameter an unstoppable shutdown can be initiated.
Because of the timeout issue, I'm inclined to resort to the nuclear option: Remove the use of shutdown.exe altogether. This can accomplished by setting a debugger redirect via the "Image File Execution Options" key in the localmachine registry hive. Since shutdown.exe is rarely used not much functionality is lost, so this is a viable option; although it does require administrative privileges to implement.
Windows Update Scheduled Reboots: These are the nasty ones the Windows 10 update added that were rebooting people in the middle of games, calls etc... Hopefully those issues are/will be gone; but lets look at how to block em anyway. These are done via scheduled tasks, (the task name is "system32\tasks\Microsoft\Windows\UpdateOrchestrator\Reboot". When it runs, the task executes the command "C:\Windows\system32\MusNotification.exe Reboot" to actually restart the machine. There's no UI and no obvious way to abort once the task is run. So we can either poll task scheduler and disable or defer the reboot task, or we can intercept MusNotification.exe as above in #2.
Remote shutdown.exe calls: Obviously, we can't block remote shutdowns in the same way we can local ones. Disabling the remote registry service will prevent them, but removing that functionality does quite a bit of collateral damage... So it seems the best we can do here to to make repeated calls to AbortSystemShutdown() (on a 900 ms delay loop) and hope the remote caller provided a timeout.
Note the standard user-triggered shutdown is also the easiest one to block; more evidence Microsoft hates its users.
This software includes code or resources from the following sources:
Includes Icon by Icons8. Licensed under the terms of: Icons8 License
This software is distributed as-is, without any representations or warranties of any kind.
The author of this software imposes no additional license terms or limits upon its use or redistribution.
Send to firstname.lastname@example.org