I’ve been playing with an open-source (Github-hosted) utility written by Mr. Nikolaj Schlej called CrScreenshotDxe. This utility is implemented as a DXE driver. It waits for a special hot key sequence, then scans installed GOP protocols and saves screenshots of them to any FAT32-formatted USB drives that it finds. From Nikolaj’s description:
This DXE driver tries to register keyboard shortcut (LCtrl + LAlt + F12) handler for all text input devices. The handler tries to find a writable FS, enumerates all GOP-capable video devices, takes screenshots from them and saves the result as PNG files on that writable FS.
The main goal is to be able to make BIOS Setup screenshots for systems without serial console redirection support, but it can also be used to take screenshots from UEFI shell, UEFI apps and UEFI bootloaders.
Installation in a BIOS
To use CrScreenshotDxe, you must integrate it into a BIOS build. Nikolaj suggests several approaches that can be used to do this:
- Integrate it into DXE volume of your UEFI firmware using UEFITool or any other suitable software
- Add it to an OptionROM of a PCIe device
- Let BDS dispatcher load it by copying it to ESP and creating a DriverXXXX variable
- Load it from UEFI Shell with load command
First, I tried using method #1: I downloaded the .FFS, ran UEFITool, and injected the file into a known-good BIOS image. I booted the machine, and all seemed to be going well, but near the end of POST I got a message on a black screen saying that my system would be shut down thanks to Intel Boot Guard. This struck me as a little strange, since the machine I am testing with is NOT Boot Guard fused, but nevertheless, this method didn’t work for me. Apparently UEFITool triggered something that Boot Guard didn’t like.
So, I resorted to downloading the .EFI and .DEPEX files and integrating them into a BIOS build. The exact steps you should take will depend on your BIOS vendor, but suffice it to say I simply added the .EFI and .DEPEX files into a directory, added an .INF file and a couple IBV-specific build files, and everything worked fine the first time.
Using the tool is simple: make sure you have a FAT32-formatted USB flash drive inserted, then press (Left)Ctrl + (Left)Alt + F12, and CrScreenshotDxe springs into action. The tool cleverly displays a small colored rectangle in the upper-left corner of the screen to communicate its status. Here is the legend:
- White - driver is loaded
- Yellow - no writable FS found, screenshot is not taken
- Blue - current GOP is pitch black, screenshot is not taken
- Red - something went wrong, screenshot is not taken
- Green - screenshot taken and saved to PNG file
The colored rectangles were a big help in figuring out what was happening. The PNG files are named with a date/time stamp. Example screenshots:
Nikolaj did us all a great service by posting this utility on Github. It was easy to integrate and worked flawlessly. CrScreenshotDxe will be a great tool for many different scenarios: 1) taking screenshots to improve documentation; 2) creating mockups of new features; 3) communicating with the validation group error codes seen during testing, etc. etc. etc.