Tech stack

KillerShot needs Windows 11 (build 22000 or later) on x64. Window capture uses the Windows Graphics Capture API, and the minimum keeps that one path for every user instead of a fallback that cannot see covered windows.

The capture pipeline

1. Freeze. When a shortcut fires, KillerShot hides its own editor if it is open, waits for the desktop to repaint without it, and copies the whole virtual desktop in one pass. The list of monitors and the visible windows, topmost first, are recorded at the same moment.

2. Choose. Region mode shows that copy on every monitor, one image pixel per device pixel, so the selector itself can never appear in the result and a menu that closes when you click stays in the picture. Monitor and all-monitor modes crop straight from the copy without showing anything.

3. Window. Window mode asks Windows Graphics Capture for one frame of the window, which includes the parts other windows cover. The rounded corners Windows 11 draws are filled from the frozen desktop behind them, so the picture has no transparent or black corners.

4. Output. The finished bitmap goes to the clipboard, the Recent history and the output folder, according to your settings. A cancelled capture produces nothing and leaves the clipboard and the last mode as they were.

Pixels, DPI and scaling

KillerShot runs per-monitor DPI aware (PerMonitorV2), so every coordinate it handles is a physical screen pixel. A selection that crosses a 100% monitor and a 150% monitor is still a plain rectangle of real pixels.

Every capture is stored as a 96 DPI bitmap, so WPF never rescales it for the monitor it is shown on, and the file you save has exactly the pixels you selected. An image you open from disk is copied into a 96 DPI bitmap for the same reason.

Clipboard and files

A capture is put on the clipboard twice in one data object: as PNG, which keeps every pixel for apps that read it, and as a standard bitmap for everything else. The data stays available after KillerShot exits. A clipboard held by another program is retried briefly, then reported.

Saved files are written to a temporary name and then moved into place, so a failed write never leaves a cut-off image behind.

The recording pipeline

A capture thread reads the recorded rectangle on a steady clock through Windows Graphics Capture, with one capture session for each monitor the rectangle covers, and hands each frame to an encoder thread. Only the recorded part of each monitor is copied off the graphics card, so recording every monitor keeps the frame rate you set. When the encoder falls behind, frames are dropped rather than letting the clock drift, and paused time is cut out of the timestamps.

MP4 frames go to the H.264 encoder built into Windows. The video size is rounded down to even numbers, which H.264 needs. Sound is captured on its own clock and filled with silence when nothing is playing, so sound and picture stay in step.

Large MP4 recordings. The H.264 encoder in Windows accepts frames up to 4096 x 2304 pixels: 36,864 blocks of 16 x 16 pixels with no side over 4096, the frame size limit of H.264 level 5.1. One 4K monitor fits. A larger area is scaled down to fit before it reaches the encoder, keeping its shape, so three 1920 pixel screens side by side at 5760 x 1080 come out at 4096 x 768. GIF recordings keep the full size.

GIF frames are reduced to a palette per frame and only the area that changed since the last frame is stored. That keeps a recording of a mostly still screen small.

Rendering

The About card (F12) has a rendering choice: Automatic, Hardware or Software. Automatic uses software rendering during Remote Desktop and remote-control sessions, where hardware rendering can show a black window. The choice applies the next time the window opens.

What is not captured

Content an app marks as protected, such as some streaming video, comes out black; Windows withholds it from every screen capture. A minimized window cannot be captured in window mode. A desktop capture of an HDR monitor is converted to standard range by Windows and can look washed out.

Command line and KillerMCP

The command line is compiled into KillerShot.exe and runs behind its --cli switch, in its own process, without the tray, the shortcuts or the single-instance claim. It uses the same capture, recording and file code as the window. See the command reference.

KillerMCP runs those commands for AI agents and passes back the JSON they print. It never asks for overwrite and leaves the clipboard alone unless asked. See the KillerMCP page.

Privacy & footprint

KillerShot has no account, no analytics and no update check. It makes no network connections on its own. The release notes link on the About card opens the GitHub releases page in your browser.

The clipboard is the point of the app, so captures follow your Windows clipboard settings, including clipboard history and sync if you turned them on. Captures are written to disk only in the Recent history and the folders you choose.