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.
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?
Thanks for the tip on how to annoy people 🙂
Fortunately NotMyFault won’t suffer any real errors!
What are they testing if they need a system crash for it to occur?
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.
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...
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.
But maybe there’s a bug in the system that accidentally calls TerminateProcess on winlogon.exe. Still needs to be debugged to confirm that it’s a false alarm.
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/registry-entries-for-silent-process-exit
Have you given this a try? I doubt it works with AV though, as it is implemented solely in user mode, inside TerminateProcess. It does not work if AV calls NtTerminateProcess.