Windows' Undocumented “Emergency Restart”(old.reddit.com)
old.reddit.com
Windows' Undocumented “Emergency Restart”
https://old.reddit.com/r/sysadmin/comments/vqcf67/windows_undocumented_emergency_restart/
49 comments
Indeed the feature is undocumented, but it's been known for some time - its goal is to mimic as much as possible the reset button, for those situations when your computer freezes up to a point where Ctrl+Alt+Del works, but literally no other process responds. Think "Background process locked up my OS, and I can't do anything short of unplugging the computer." Especially helpful on a laptop where the physical reset button is not available.
I wonder why microsoft never implemented the Magic SysRq keys like linux: https://en.wikipedia.org/wiki/Magic_SysRq_key
It'd let you safely shutdown when the computer is locked up otherwise.
It'd let you safely shutdown when the computer is locked up otherwise.
That's what Ctrl-Alt-Del is for.
They aren't exactly the same thing, I suppose, but there's enough functional overlap that if you already have one, it's hard to justify adding another. You don't want too many of these "escape sequences", because every kernel-side keyboard interrupt becomes a thing that:
* Userland doesn't get to use that keyboard shortcut any more.
* Someone might accidentally trigger, and if they don't know what's going on, they become stuck.
* It's another thing that anyone building a captive kiosk has to know how to disable.
They aren't exactly the same thing, I suppose, but there's enough functional overlap that if you already have one, it's hard to justify adding another. You don't want too many of these "escape sequences", because every kernel-side keyboard interrupt becomes a thing that:
* Userland doesn't get to use that keyboard shortcut any more.
* Someone might accidentally trigger, and if they don't know what's going on, they become stuck.
* It's another thing that anyone building a captive kiosk has to know how to disable.
The times my Linux installs have locked up, those keys never worked.
They may be disabled by distros to enhance security against physical access attacks.
It can also be challenging to actually input a magic-sysrq combo on many modern keyboards where sysrq isn't its own key, if it's labeled at all as some Fn-key contortion.
It can also be challenging to actually input a magic-sysrq combo on many modern keyboards where sysrq isn't its own key, if it's labeled at all as some Fn-key contortion.
Personally I value being able to trigger oomkiller early when a process is eating up RAM, and being able to SIGKILL kwin_x11 on Nvidia or whatever other process is wedging Linux shutdown, instead of waiting multiple minutes for systemd to give up waiting and SIGKILL it directly. In terms of physical access attacks, it's just as viable and far more powerful to add a keylogger to my keyboard or Linux distro, or pull and image my hard drive, than to gasp kill processes or sync filesystem data to disk, oh the horror!
WRT the physical security argument in favor of disabling sysrq, my assumption is it's more aimed towards defeating quick-n-dirty mischief style abuse.
Ages ago I worked with a small team of young sysadmins who would often cause trouble for one another abusing things like sysrq, or poorly configured XFree86 instances without DontZap enabled (ctrl-alt-backspace termination, to a shell when startx/xinit is being used). Most of the time nothing malicious was actually done. But when you return to your screen-locked X desktop to find a fullscreen VC with a root shell blinking back at you and an empty history, guess what you'll at least have on the back of your mind for the rest of the workday?
Ages ago I worked with a small team of young sysadmins who would often cause trouble for one another abusing things like sysrq, or poorly configured XFree86 instances without DontZap enabled (ctrl-alt-backspace termination, to a shell when startx/xinit is being used). Most of the time nothing malicious was actually done. But when you return to your screen-locked X desktop to find a fullscreen VC with a root shell blinking back at you and an empty history, guess what you'll at least have on the back of your mind for the rest of the workday?
From what I recall it needs to be enabled (or not be disabled) when the kernel is compiled and in some cases a flag must be put on the kernel command line while booting.
They always worked for me, but it's been a long time since linux has locked up on me.
What always found impressive on Windows is C-A-Del will always work.
I can name hundreds of occasions from first-hand experience where it hasn't worked in the past 26 years for me on a variety of machines in various environments.
One prominent example I've seen multiple times, is hanging in the shutdown screen where no text appears under the spinning dots, and Ctrl-Alt-Del does nothing.
Me too.
Blue screen of death, for example.
Ctrl+Alt+Del invokes WinLogon, the highest priority process, that then delivers the task manager. I believe this is a kernel invocation, so regardless of user land dysfunction, it will always work. Tthis is possibly attributable as much to convenience as it is to security -- the Secure Attention Sequence[1] is intended as a login-spoofind protection which will suspend other tasks (like a spoofed login screen) before continuing forward with user auth.
[1]: https://en.wikipedia.org/wiki/Secure_attention_key
[1]: https://en.wikipedia.org/wiki/Secure_attention_key
A group policy can be enabled on most variants of Windows (dating back to around NT 4 or Windows 2000, I think) to start with a dialog saying "Press Ctrl-Alt-Delete to begin", and pretty much nothing else, exactly for the reasons you describe.
Though Microsoft's current security recommendation is against setting that policy for accessibility reasons. [0]
Windows since 8 has worked on hardening/strengthening the "Secure Desktop" that login flows (and UAC prompts) happen on so that as much as possible malware shouldn't be able to run in those sandboxes.
[0] https://docs.microsoft.com/en-us/windows/security/threat-pro...
Windows since 8 has worked on hardening/strengthening the "Secure Desktop" that login flows (and UAC prompts) happen on so that as much as possible malware shouldn't be able to run in those sandboxes.
[0] https://docs.microsoft.com/en-us/windows/security/threat-pro...
> I believe this is a kernel invocation, so regardless of user land dysfunction, it will always work.
It may always work from the kernel's standpoint, but this doesn't necessarily make it usable.
Anything that blocks the display of WinLogon (e.g., the GPU has crashed and is unresponsive) would render this emergency restart mechanism unusable, and typically, situations like this are usually the only time I would need such a feature.
It may always work from the kernel's standpoint, but this doesn't necessarily make it usable.
Anything that blocks the display of WinLogon (e.g., the GPU has crashed and is unresponsive) would render this emergency restart mechanism unusable, and typically, situations like this are usually the only time I would need such a feature.
So what if the keypresses never get registered?
I had a situation a month ago where my computer froze up (it was a couple months old at the time) and literally nothing would respond, even control-alt-delete, but my mouse cursor would still move around. I have no idea what caused that (it was a fresh restart after installing a GPU driver) but whatever drives the cursor display must be even higher priority than C-A-Del.
Most graphics cards implement a hardware mouse cursor where the video card reads the current pointer location from memory and overlays the cursor on the screen. So I guess if the driver for the mouse and the video driver are both still running (the kernel hasn’t stopped completely) that will still work even if Winlogin is screwed to the point where it can’t show the CTRL-ALT-DEL screen.
Happy to be corrected by someone who knows more about the windows kernel. :)
Happy to be corrected by someone who knows more about the windows kernel. :)
Interesting I didn’t know that. Some part of the kernel was fucked for sure as even the hardware sleep button in my keyboard didn’t work but I guess if the display driver was functioning that would be all that was needed.
I feel like it worked more reliably in XP and below, ever since vista I’ve had less success.
With that said, system stability as a whole seems to have improved dramatically since those days, I don’t need to reach for it very often.
> Especially helpful on a laptop where the physical reset button is not available.
Are there any where holding the power button for 10-15 seconds doesn't work? This has always been a reliable technique for me, when using linux on numerous different laptops from different manufacturers.
Are there any where holding the power button for 10-15 seconds doesn't work? This has always been a reliable technique for me, when using linux on numerous different laptops from different manufacturers.
BIOS issues? Though Ctrl+Alt+Delete might not work with a BIOS acting up either.
15 seconds migh be a lotof time, depending on the situation.
[deleted]
Besides the mentioned NtSetSystemPowerState function, which this feature calls, there are also other undocumented API functions that allow to shutdown / restart the sytem immediately, like NtRaiseHardError (which allows to cause a bluescreen-like unclean shutdown with normal user permissions as a fun side-effect).
Equivalent of the old good double-press of Ctrl-Alt-Del that we used to have in Windows 9x?
Ctl+Alt+Del has been a BIOS designated interrupt for REBOOT since the DOS 3 (or even before, but that's the edge of my memory) days.
Win9x "tried" to intercept it; but was never 100% successful.
Win9x "tried" to intercept it; but was never 100% successful.
I _always_ reboot with 'shutdown /f /r /t 0', the interactive shutdown/reboot stuff is worthless
Do I understand this correctly as being the software equivalent of pushing the reset button? Or am I missing something?
I wonder what the history behind this feature is.
I wonder what the history behind this feature is.
Top comment has a link to more details. Apparently it's NtSetSystemPowerState from ntdll.
https://www.codeproject.com/Articles/34194/Performing-emerge...
https://www.codeproject.com/Articles/34194/Performing-emerge...
Sounds like the Windows equivalent of shutdown -r now
No, not really, from the OP
>After a bit of testing with Restart-Computer and shutdown /r /f, I've found that no officially-documented shutdown command or function comes close in speed -- they both take a fair bit of time to work, and importantly, they both register in the Event Log as a clean shutdown. So what's going on here?
IME shutdown -r now definitely takes it sweet time (ie. getting stuck on "A stop job is running ..."
>After a bit of testing with Restart-Computer and shutdown /r /f, I've found that no officially-documented shutdown command or function comes close in speed -- they both take a fair bit of time to work, and importantly, they both register in the Event Log as a clean shutdown. So what's going on here?
IME shutdown -r now definitely takes it sweet time (ie. getting stuck on "A stop job is running ..."
Sysinternal's "pskill csrss" used to be my last resort to reboot remote or local desktops and VMs. Saved my ass many times.
It's pretty quick on macOS.
> (ie. getting stuck on "A stop job is running ..."
Trying to unmount a manually mounted network drive after already taking down the network... very frustrating. Seeing the time remaining counter jump from 30 seconds to 2+ minutes after the first 30 seconds passes is rage inducing. Do I really need to read the jargon dense documentation for a damn init system to get my computer to behave in a sensible way? Thanks Lennart.
Trying to unmount a manually mounted network drive after already taking down the network... very frustrating. Seeing the time remaining counter jump from 30 seconds to 2+ minutes after the first 30 seconds passes is rage inducing. Do I really need to read the jargon dense documentation for a damn init system to get my computer to behave in a sensible way? Thanks Lennart.
Perhaps a closer analog would be halt(8) with the -q (BSD) or -f (Linux) option to avoid calling init(8):
https://man.openbsd.org/halt
https://manpages.debian.org/halt
https://man.openbsd.org/halt
https://manpages.debian.org/halt
On my RHEL systems:
-f / --force : "Force immediate halt, power-off, or reboot. When specified once, this results in an immediate but clean shutdown by the system manager. When specified twice, this results in an immediate shutdown without contacting the system manager."
"...all processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a drastic but relatively safe option to request an immediate reboot. If --force is specified twice for these operations, they will be executed immediately without terminating any processes or unmounting any file systems. Warning: specifying --force twice with any of these operations might result in data loss."
-f / --force : "Force immediate halt, power-off, or reboot. When specified once, this results in an immediate but clean shutdown by the system manager. When specified twice, this results in an immediate shutdown without contacting the system manager."
"...all processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a drastic but relatively safe option to request an immediate reboot. If --force is specified twice for these operations, they will be executed immediately without terminating any processes or unmounting any file systems. Warning: specifying --force twice with any of these operations might result in data loss."
Yes, that's what I was thinking of.
This is a normal reboot. If anything seems more like a reboot issued via magic system request.
Agreed, seems to be exactly this.
https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...
echo 1 > /proc/sys/kernel/sysrq # enable sysrq
echo o > /proc/sysrq-trigger # immediately power off
https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...
echo 1 > /proc/sys/kernel/sysrq # enable sysrq
echo o > /proc/sysrq-trigger # immediately power off