The secure attention key is designed to make login spoofing impossible, as the kernel will suspend any program, including those masquerading as the computer's login process, before starting a trustable login operation.

Why cannot other programs simulate control+alt+del?

What is the reason behind this?

  • see stackoverflow.com/q/886076/866172
    – Jalayn
    Jul 27, 2012 at 11:45
  • 1
    IIRC (and my memory is rusty, this comment might be enough to give you some google search terms) it is from way back in DOS. It was the only keystroke sequence that a program could not add an interrupt to. Back in the day a TSR program like Sidekick could add an interrupt handler (to 09h?) that would register its key sequence. When the user pressed the sequence then Sidekick could intercept it and then display itself. Ctrl-Alt-Del on a DOS system would reboot it, so maybe Microsoft decided not to let anyone else use it. Maybe the folks over at superuser or serverfault could help
    – jqa
    Jul 27, 2012 at 12:46
  • 1
    And Bill Gates even apologized for the 3 finger salute... ;-) cnn.com/2013/09/26/tech/innovation/… May 22, 2020 at 12:32

4 Answers 4


Larry Osterman wrote about "Why is Control-Alt-Delete the secure attention sequence (SAS)?" back in 2005. The answer is so short that there is no real need to summarize it, although I am eliding a few side notes.

When we were designing NT 3.1, ... we needed to have a keystroke sequence that couldn't be intercepted by any application. ...

It turned out that the only keystroke combination that wasn't already being used by a shipping application was control-alt-del, because that was used to reboot the computer. And thus was born the Control-Alt-Del to log in.

So there you have it, the reason why Ctrl+Alt+Del was chosen for the secure attention sequence.

Most likely on DOS there was no real technical reason why you couldn't possibly have caught Ctrl+Alt+Del and used it for some other purpose, but nobody in their right mind would have done that in a DOS application since it would break so much of users' expectations of how their computers worked. Note that Windows 3.x (when running in 386 Enhanced Mode; I don't think it did so when running in Standard Mode, and certainly not Win 3.0 in Real Mode) caught and handled Ctrl+Alt+Del, which demonstrates that it could be done even when running on top of BIOS + DOS. Probably the code that did the grunt work for that was just a few assembly language instructions, hooked to the appropriate interrupt vector, which looked for DEL with the CTRL and ALT modifiers set, doing a bit of magic if it found that particular combination.

As for simulating it, I'd go with "why would you want to?". I do recall reading somewhere (maybe it was at Larry Osterman's blog, maybe it was somewhere completely different) that technically the secure desktop is a separate session started and maintained by the Windows initialization code, and thus inaccessible to any non-privileged process. That said, apparently there is a SendSAS() function in SAS.DLL (which on Win7 is in System32) wich will simulate the user pressing Ctrl+Alt+Del; see SendSas Step by Step for a short code example. Caveat: I haven't tried that one myself.

  • i read Larry Osterman before...but i want more information.i I would not know "how impelemnt it" i want know why i can't do this!
    – AminM
    Jul 27, 2012 at 15:33
  • 2
    @JesonPark: you can't do it for the simple reason that the designers of Windows don't want you to be able to do it. Jul 27, 2012 at 18:01
  • It seems this is only for Windows!...
    – AminM
    Jul 28, 2012 at 6:38
  • @JesonPark: yes, you are correct, this is a issue specifically related to the Windows OS. Jul 28, 2012 at 12:43
  • 1
    @JesonPark Linux has no concept of a secure attention sequence the way Windows does. Some desktop's login manager might, though. (And that has nothing to do with the subject matter of Programmers.SE.)
    – user
    Jul 30, 2012 at 11:27

Why it cannot be intercepted:

  1. Because it would be a huge security risk. Imagine an application which launches at logon. It shows a false logon screen to the user and invites the user to enter a password. To avoid this scenario, you often have (in business environments or on Windows Server) to press Ctrl+Alt+Delete before logging in; this ensures that you're not entering your password in a false logon screen.

  2. Because Ctrl+Alt+Delete is known for being the last resort where a full-screen application hangs and you cannot switch to another one (Alt+Tab) or to the start menu (Win). If Ctrl+Alt+Delete is intercepted too, the only way to exit such application would be to power down/unplug/force reboot the PC.

Why it cannot be simulated:

  1. Because you don't need it. You can already do whatever you want with the user session (given enough privileges), including the logoff.

  2. Probably because it's difficult to implement. Since those keys cannot be intercepted, it might be that for the same reason, a piece of software (aside drivers) cannot emulate those keys.

  • 6
    You explain why it should not be intercepted, not why it is impossible, or what mechanism prevents it.
    – Useless
    Jul 27, 2012 at 12:04
  • 1
    @Useless: The OS prevents it, because it should not be intercepted. Now, how is it implemented internally? I have no idea, and I imagine that only developers from Microsoft who work on Windows core know those internals. Jul 27, 2012 at 12:10
  • 1
    @MainMa:tanq for response but as UseLess say :"how is it implemented internally??" you say "Since those keys cannot be intercepted..." i want to know how those keys cannot be intercepted!
    – AminM
    Jul 27, 2012 at 15:29
  • 1
    They can be intercepted. VMware implements this with their "enhanced virtual keyboard" feature.
    – MichaelGG
    Apr 8, 2014 at 7:51
  • 1
    @MichaelGG: I imagine that VMware installs drivers and intercepts the keys at driver level. The question, on the other hand, is about applications, not drivers. Apr 8, 2014 at 11:49

In a comment to another answer you said the answer explained why it shouldn't be intercepted, but you are asking why it can't, not why it shouldn't be intercepted.

Maybe I'm pointing out the obvious, but it can't be intercepted simply because that's how windows was designed. The OS obviously intercepts it, and it simply refuses to pass that event on to applications. It was a design decision by the makers of the OS.


The answer is that it can be intercepted -- you just have to do it before it gets to Windows (i.e at the driver level or the firmware of the device). The reason you can't intercept it once the OS has it is because the OS doesn't allow it.

  • as i say i know this...but how??and Michael Kjörling in first answer say about this!
    – AminM
    Jul 28, 2012 at 19:47
  • 1
    See the answer by Bryan Oakley...in short, the OS somewhere has an If statement...
    – jmoreno
    Jul 29, 2012 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.