Author Topic: Microsoft veteran on how to blue screen your way to better testing  (Read 36 times)

Offline javajolt

  • Administrator
  • Hero Member
  • *****
  • Posts: 35202
  • Gender: Male
  • I Do Windows
    • windows10newsinfo.com
Developers seeking a way of crashing Windows on demand for testing purposes have received a reminder from Microsoft veteran Raymond Chen: NotMyFault is your friend.

Chen predates Microsoft's current batch of operating systems, but his advice remains relevant to developers seeking a way of triggering the infamous Windows blue screen of death to test how their code will react to the abrupt stop.

The key to the error

While administrators might spend their days devising ways of staunching blue screens on user desktops, developers can change a certain registry setting, which, when activated by a user-defined combination of keys, is supposed make the operating system come to a screeching halt.

PS/2 keyboard support for the key combination turned up in Windows 2000, USB keyboards were added with Vista, and Hyper-V support came with Windows 10 1903.*

However, the magic key combination to make Windows crash is a relic of a bygone era. Chen wrote of a customer keen to automate things with a test script: "They wrote a simple program that ran as administrator and injected the appropriate keystrokes. But no crash occurred. What did they do wrong?"

What indeed. The problem lies in how the magic key combinations had been implemented. Rather than higher up in Windows, the trigger for the crash can be found lower down the input stack in the keyboard driver. Simply passing in a keypress doesn't do the trick: an actual key needs to be pressed by an actual user.

This was fine when humans did the testing, but is not so good for the automated testing made popular by DevOps-like methodologies.

Chen's advice is to turn to the Sysinternals tool NotMyFault, which will make Windows appear to fall over in a variety of ways without needing a human at the keyboard.

There are, of course, other ways of making Windows trip over its own feet. A cynic might suggest that simply letting Windows Update do its thing could well do the trick. Installing an innocent-looking patch and getting a blue screen of death is not unheard of.

Chen wrapped up the session by sticking with the retro theme and reminding developers that Dr Watson remains a thing in Windows, or at least a service named for the famed debugging tool.

"Please do not use sneaky tricks like terminating critical processes like winlogon.exe," he said.

"These failures get reported through the Watson service as a winlogon.exe crash, which creates confusion among the winlogon.exe team as they try to identify the source of a nonexistent bug."

Windows has more than enough real bugs. ®

* This is Chen's reference to the magic key combination on PS/2 keyboards, not Windows support (which has indeed been there since DOS days.)

source