February 19th, 2024

Why can’t I trigger a manual blue screen crash by injecting the magic key sequence?

A customer was developing an automated test that required the system to suffer a blue screen crash. They configured their test systems to crash when the ScrollLock key is pressed twice while holding the Ctrl key, and they wrote a simple program that ran as administrator and injected the appropriate keystrokes. But no crash occurred. What did they do wrong?

The key sequence for triggering a manual blue screen crash must be typed on a physical keyboard. Injection doesn’t work.

You may have gotten a clue that the physical keyboard was part of the story since enabling the diagnostic key sequence requires you to apply a different setting depending on what kind of keyboard you are using: There is one setting for PS/2 keyboards, and another for USB keyboards, and yet another for Hyper-V keyboards. It is clear that they keyboard driver is somehow involved.

There is another remark later on the page that talks about limitations of the USB keyboard driver, since it runs at a lower IRQL than the PS/2 driver.

The sequence must be pressed on a physical keyboard because it is the keyboard driver that recognizes the key sequence and triggers the crash screen. Injecting the keys into the window manager is inserting the keypresses at far too high a level in the input stack.

    Input
routing
    â­¡
    Input
processing
  â­§ â­¡ â­¦
Keyboard
driver
  Mouse
driver
  SendInput
â­¡   â­¡
Hardware
keyboard
  Hardware
mouse

The best way to trigger an artificial kernel crash is to use NotMyFault, part of the SysInternals family of tools.

Please do not use sneaky tricks like terminating critical processes like winlogon.exe. These failures get reported through the Watson service as a winlogon.exe crash, which creates confusing among the winlogon.exe team as they try to identify the source of a nonexistent bug. If you use NotMyFault, then the system recognizes that the crashes were initialted by NotMyFault, and the Windows team knows that any crashes initiated by that tool were intentional and not an indicator of a system problem that needs to be debugged.

Topics
Code

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

9 comments

Discussion is closed. Login to edit/delete existing comments.

  • amoskevitz

    Interestingly, on my computer if you go to the registry location where you would put the key that triggers the USB keystroke crash, there is a Key namedWorkNicely. It is set to 0… I guess my keyboard is mean to the other devices?

  • Piotr Siódmak

    Thanks for the tip on how to annoy people 🙂

  • Neil Rashbrook

    Fortunately NotMyFault won’t suffer any real errors!

  • Sigge Mannen

    What are they testing if they need a system crash for it to occur?

    • Rio Dio

      They look for some event and want to catch the whole system state before they lose the context. So they trigger system crash to get full memory dump.

  • a b · Edited

    Terminating winlogon.exe does not cause blue screen in modern windows since session 0 isolation. It only leads to the termination of its session and auto relogon if the session was active. I use this method to simulate logoff.exe another session when logoff.exe is not available.
    I don't know who wrote the critical process list in https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xef--critical-process-died
    but logonui.exe conhost.exe were never critical process, and neither was winlogon.exe. The blue screen after winlogon.exe termination in older...

    Read more
  • Joshua Hudson

    You mean you can’t tell the difference between terminating winlogon.exe and winlogon.exe crashing? Fix your API surface. It’s been a thorn in my side for far too long when I can’t tell that AV terminated my child process; now you feel it too.