New Tool Offers Life After Windows BSOD

News
By Mark Tyson
published

There are some limitations, but this is a step towards developing the Blue Screen of Doom.

BugCheck2Linux
(Image credit: Future)

An interesting new tool for PC drops users into a Linux shell if Windows crashes. The BugCheck2Linux tool from NSG650, recently highlighted by NTDEV on Twitter, makes use of the bug check callback function in Windows to run an executable - even after a BSOD (Blue Screen of Death) crash. So, "Death" isn't the end in this case, it is just where Linux begins.

It isn't common knowledge that programs can run after a Windows BSOD, but BugCheck2Linux stretches the current possibilities of running executables via the 'bug check callback function' to fire up a completely different OS. You can read about the intended use of the bug check callback routine on the Microsoft Learn documentation site.

BugCheck2Linux runs as a driver, which in turn "runs a tiny RISC V emulator running Linux." NSG650 says that the screen output uses bootvid.dll, and the input relies upon polling of a PS/2 keyboard driver. The developer credits the ReactOS Project for bootvid documentation, mini-rv32ima for the RISC V emulator and Linux image, and OSdev Wiki for PS/2 documentation.

BugCheck2Linux

(Image credit: NSG650)

There are some pretty severe limits on the Linux install that can run after the Windows BSOD. For example, the display output is limited to 640 x 480 pixels and 16 colors, the system will only work on BIOS-based (not UEFI) systems, it runs slowly, and keyboard support has limits such as not allowing users to backspace. In other words, this BSOD tool isn't dropping you into a modern Ubuntu install.

On it's own, it is impressive to be able to continue to use the computer after a BSOD, but the future potential beyond a tiny limited Linux OS is what catches the imagination here. NTDEV raises the possibility of having a Windows PC crash into BSOD and then instantly firing up Doom to let off some post-crash steam. Perhaps it would be a more modest step to try and post-BSOD run a classic arcade title like Asteroids or Galaxian.

Trying BugCheck2Linux

If you want to try out this tool, the GitHub page where it is found provides a step-by-step guide. Basically, you must download and start the tool's driver process, so it can be ready to run if you BSOD.

In NTDEV's video above, you can see the Tiny11 developer making his Windows 11 install crash by executing winini (as Administrator) in PowerShell. Then you get to see the Linux install running post-BSOD.

This is an fun project, but please be careful with your PCs, and make sure to perform regular backups just in case.

Mark Tyson
Mark Tyson
Freelance News Writer

Mark Tyson is a Freelance News Writer at Tom's Hardware US. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.

8 Comments Comment from the forums
  • USAFRet
    A BSOD crash is an indicator of "something is wrong. Human...please fix me."

    Why would you want to keep 'running' the system, and not actually discover and fix the problem?

    Especially given the limitations of this subsystem.
    Reply
  • Metteec
    This would be useful for debugging. Unity loves to throw up BSODs for memory-related issues and during testing, each throw causes four minutes of downtime trying to debug. The last time I resolved a Unity crash issue, I threw twelve BSOD in a four hour fix. That is 48 minutes of waiting for my PC to restart, reload programs, and try again. Reducing that downtime by 20% is bad news for programmers that charge by the hour, but good news for indie developers and testers.
    Reply
  • nsg650
    Hi there! Yes indeed a bsod is used for indicating something horribly went wrong and one would usually avoid to keep the system running. The bugcheck callback is usually used by drivers to keep a record of what caused the crash probably used by device driver developers and possibly it might be used by some debuggers. Here I am just misusing the API
    Reply
  • USAFRet
    Yeah, I guess there would be some dev uses for this.

    Wasn't fully thinking the situation through.
    Reply
  • flytrap23
    "the system will only work on BIOS-based (not UEFI) systems"
    Who still runs these?
    Reply
  • Steve Nord_
    USAFRet said:
    A BSOD crash is an indicator of "something is wrong. Human...please fix me."

    Why would you want to keep 'running' the system, and not actually discover and fix the problem?

    Especially given the limitations of this subsystem.
    How many scratch installs you got?

    Because you maybe hit on the interesting bit you were hunting for. If you're fuzzing or buzzing memory protection or erstwhile DMA maybe you get the proverbial license number on a callback to a wrong ring. Also at least you could pull a little state out to see what wrong number was dialed (in a JIT engine like a Java or JS engine) otherwise, realize a little bad magic got pulled in as fine magic...
    Reply
  • Steve Nord_
    flytrap23 said:
    "the system will only work on BIOS-based (not UEFI) systems"
    Who still runs these?
    Me. <> That, you could get in a VM maybe. There's probably already advice at QubesOS not to, though? Hey, you're like 30 'this system has no official HP/Apple/Lenovo/Xiaomi/Predator/Framework battery...retina reader...and stuff' lectures away from installing netbsd fastboot.
    Reply
  • Steve Nord_
    Metteec said:
    would be useful for debugging. Unity loves to throw up BSODs for mem...
    Sounds like something that makes you want to rent a virtual cube in decommissioned Google game streaming or other virtual machine environment if not the cloud services (drawing blanks here...perforce cms? Like, hardened Android Studio??) developed for Unity devs.
    Reply