Tech stack

KillerBench is a native Windows app. The desktop app, the command line and the Engine underneath them share the same diagnostic evidence and repair workflows.

Diagnose first

KillerBench treats diagnosis and change as different jobs. Diagnosis only reads. A change happens only when you pick a specific repair or action, review its options and prerequisites, and confirm it.

The full system scan is diagnostic-only, including when a focused workflow has automatic repair enabled. Saved captures, imported logs and historical events never authorize a repair.

Bounded collection

Every native command and Windows provider runs behind fixed time, record and size bounds. A provider records its exit status, timeout, truncation, standard output and error output. A failed or truncated provider can never be read as a clean, empty answer.

Minimal retention

Collectors keep what a finding needs. Many results keep names, categories, counts, states and timestamps while leaving out credentials, command lines, full paths, account identities, network endpoints and unrelated event payloads.

Evidence you can follow

Every finding is tied to the evidence that produced it, and the report always separates what was proven from what was only observed.

Unknown is a result

Unknown means access was denied, a source was missing, a provider failed, output was malformed, a bound was exceeded, or the evidence disagreed. KillerBench shows that limitation and the next useful step instead of hiding it.

History stays history

Event records and imported logs describe what was recorded at a past time. They can point to an error code or the next diagnostic scope. They do not prove that the fault is still active.

Journals and interruptions

Before KillerBench asks Windows to make a change, it writes down what it is about to do. Each change is saved in a journal under %LOCALAPPDATA%\KillerBench.

After the change, KillerBench reads the result back and reports Verified only when Windows shows the expected state. If Windows reports success but the state did not change, the result says so and nothing is repeated.

A process can stop after Windows receives a request but before verification finishes. The pending record stays, and a later reconciliation reads fresh state to work out what happened. Reconciliation is not an automatic rollback, and it never repeats the original change. Keep the journal when an outcome is uncertain.

What it will not do

• Clear a TPM, delete protectors it did not create, or display recovery passwords.
• Change a setting that group policy or device management controls.
• Run a repair just because a historical event or imported report mentions a problem.
• Turn missing, partial or failed evidence into a healthy verdict.

Reports

Every run produces a report that you can read, filter and export. A report separates:

1. What was inspected
2. What problem was found
3. What evidence supports the finding
4. What action was proposed or performed
5. How the result was verified
6. What remains unknown or needs a restart

Raw output keeps the technical evidence with its original line numbers so you can trace any finding to its source. The Readable report summarizes the same run in plain language, with the next safe step first. HTML reports use the Killer Tools theme system and stay readable without the app. Text favors portability, and JSON keeps structured fields for another program.

Demo mode

Start KillerBench.exe --demo to try Run diagnosis on a fabricated workstation. Every workflow produces synthetic evidence and timed progress. No Windows provider is called, no repair command runs and no journal is written. Separate tool buttons outside Run diagnosis stay live, so do not use them as demo actions.

KillerBench.exe --demo-screenshot opens a view-only Full system scan report for a fixed fictional machine. Clicks in the workspace, shortcuts and file drops are blocked.

Knowledge packs

Large and frequently updated reference data lives in knowledge packs instead of the diagnostic logic: Windows and Setup error codes, vendor and device identifiers, PCI, USB, ACPI and UEFI references, network OUI vendor data, driver and support locations, and curated support links.

Each pack identifies its format, schema version, source, source revision, generation time and content hash, and KillerBench validates them before use. An unknown or invalid pack stays unavailable instead of falling back to a guess. An update downloads to a temporary location, is validated, then replaces the active pack in one step, so a failed update leaves the previous pack in place.

Knowledge data can explain an identifier or suggest where to look next. It cannot turn a historical code into a current fault, choose a driver automatically, or authorize a repair.

Localization

The interface is available in 20 languages: English, Bengali, Czech, German, Spanish, French, Hungarian, Italian, Japanese, Kazakh, Norwegian, Polish, Portuguese (Brazil), Russian, Slovenian, Turkish, Ukrainian, Vietnamese, and Simplified and Traditional Chinese. A language change applies immediately, including the section and workflow names, the welcome text and an open readable report. Any missing text falls back to English.

Evidence, Engine findings, journals and Raw output stay in English, the same as a Windows log, so a report reads the same on every machine and can be searched for exact text.

Architecture

The Engine is split into three UI-free projects. Engine.Core supplies primitives and declarative recipes, Engine owns shared workflows and evidence, and Engine.Windows registers the native providers. The desktop app, the CLI and the tests are separate hosts.

Collectors fail closed when identity is ambiguous, output is malformed, a limit is exceeded, or required authority cannot be inspected. The Engine targets Windows today and is not cross-platform. The Engine developer guide covers the API, the CLI and embedding the Engine in another .NET host.

Development status

KillerBench is in development and there is no public download yet. Repair coverage is still expanding, and native repair validation is still in progress. A successful build or simulated check does not establish native repair behavior. Disposable Windows virtual machines are used to validate each native change across Windows versions and failure states. See How changes stay safe for the full safety model.

Install, folders and data

KillerBench ships in two forms. The installer is the standard download and supports a per-user or an all-users installation. The portable edition carries its own .NET runtime and runs without installation.

KillerBench runs with the rights of the account that started it. It does not elevate itself. Start it with Run as administrator when protected evidence, such as BitLocker protectors, or a repair needs administrator access. Elevation never selects or approves a repair.

What the installer does

The installer verifies and extracts the application to %LOCALAPPDATA%\Programs\KillerBench\, or to %ProgramFiles%\KillerBench\ after an elevation prompt for all users. It adds a Start menu shortcut, an optional desktop shortcut and an Add or Remove Programs entry with a normal and a quiet uninstall. The portable edition verifies and extracts its payload under %LOCALAPPDATA%\KillerBench\Portable\ for the current run and sweeps abandoned copies on the next start.

Where things live

Journals stay on this computer, and KillerBench does not upload them. Delete a journal only after you no longer need the evidence for an uncertain outcome.

Guarded repairs

Repairs are typed operations with eligibility, execution, verification and recovery rules. They are not command strings picked out of a log line. Every supported repair follows the same sequence:

1. Collect complete current evidence.
2. Match one supported recipe.
3. Review required options and consequences.
4. Confirm administrative and policy prerequisites.
5. Recollect the decisive evidence immediately before the change.
6. Write a durable preparation record.
7. Run one bounded native action.
8. Collect fresh verification evidence.
9. Record a verified, blocked, stopped or uncertain outcome.

If the decisive evidence changes before the action runs, KillerBench stops without performing it.

Explicit choices

Repairs that depend on an option need an exact choice from you, such as a volume, printer queue, recovery-key destination, power value, package version or repair source. KillerBench never invents those values.

Managed computers

Group Policy and device management can make a local change ineffective or inappropriate. Supported repairs inspect who owns a setting and stop when that ownership is managed or unknown. Settings that a policy owns are left alone.

Automatic repair

Automatic repair only lets eligible recipes proceed. It does not bypass evidence, choose missing options, ignore policy, retry an uncertain action, restart Windows, or turn a finding that needs review into a repair.

Constants and limits

Saved logs and captures

KillerBench can investigate evidence without running anything on the machine. Drop a text log on the window, or paste its path and choose Open log. CBS, CSI and Setup lines are parsed with their timestamps, and findings link to the exact original line. EVTX and event XML files can be imported the same way.

Scan Windows Update is an on-demand, read-only collection of CBS, DISM, Panther and rollback Setup logs, update and servicing event channels, update service states, free space, uptime, pending restart indicators and selected update policy. Save capture writes the retained evidence to a .kbench file. Open capture reopens it without the original files and evaluates it again with the installed rules, so the same rules give the same findings.

Updates and signing

At startup KillerBench asks GitHub for the latest stable release, with a four second limit, and offers an update only when that release is newer. You can turn the check off with Check for updates on startup in About, or in the update prompt. The download is the package that matches the running copy, installer or portable, and its SHA-256 must match the release's SHA256SUMS.txt before anything installs. The app closes and reopens itself to finish. There is no background service.

The About card shows the version, the code-signing publisher and thumbprint, and the SHA-256 of the running executable, so you can check the copy you have.

KillerMCP

KillerBench does not include an AI agent. KillerMCP can connect one to the same Engine. The KillerMCP Options in About decide what that agent may do:

Only a person at this computer can raise the level. After an uncertain repair result, KillerMCP writes a lock, and agent repairs stay blocked until someone clears it in About.

Command line and exit codes

killerbench-cli runs the same Engine without the desktop app. Progress goes to standard error and JSON to standard output. Most commands preview by default, and a change needs --execute. Matching -recover commands review an interrupted action without repeating it. See Run KillerBench from scripts and the command reference.

No exit code certifies that a computer is healthy.

Privacy and network

Diagnostics and log analysis run locally, without an AI service or a KillerBench account. Journals and retained evidence stay in the local account's %LOCALAPPDATA%\KillerBench folders.

Actions you select can contact their destination, such as Windows Update, software download services, or recovery-key backup to Active Directory or Entra ID. The startup update check contacts GitHub, and knowledge updates and the KillerMCP installer contact their configured services. An AI client using KillerMCP may receive the reference result it asked for.

Raw logs, imported files and exported evidence can contain computer names, accounts, paths or sensitive source text. Review them before sharing, and never include recovery keys, credentials or customer data in a public report.

Glossary

Plain-language definitions of the terms used on this page, in alphabetical order.