HardwareToad

Overview

HardwareToad is a Windows hardware monitor with a Python/Tkinter UI and a self-contained .NET sensor bridge built on LibreHardwareMonitor. It shows real-time CPU / GPU / RAM / storage telemetry with live graphs, runs AVX2/FMA and Linpack-grade CPU stress, has a native DirectX 12 GPU stress engine (compute + VRAM + rasterizer), and a 15-pattern RAM stability test — all behind a token-authenticated local bridge with SHA256 integrity and Obfuscar symbol protection. Ships as a one-click Inno Setup installer; end users need no compiler, no .NET runtime, no Python.

Highlights

• ▸ Live CPU / GPU / RAM / storage telemetry with ring gauges and temperature graphs.
• ▸ CPU stress: single-core AVX2/FMA, multi-core FMA, Memory/IMC, combined, Linpack DGEMM.
• ▸ Native DX12 GPU stress engine: 16M FMA compute threads + 256MB VRAM transfers + rasterizer, with feature-level fallback (12.1 → 11.0).
• ▸ 15-pattern RAM stability test with exact error reporting — reveals unstable XMP / EXPO.
• ▸ Hardened local bridge: 256-bit token per launch, SHA256 binary check, Obfuscar-protected symbols, 127.0.0.1-only CORS.
• ▸ 11 built-in themes, per-color overrides, any installed system font, custom window sizes — all autosaved.
• ▸ Self-contained installer — end users need no compiler, .NET, or Python; auto-elevates on every launch.

Context

I wanted a hardware monitor that actually fit how I work: dark, dense, no nagware, no cloud, no account. And I wanted to understand the stack — sensors, GPU compute, stress workloads — end to end instead of gluing existing tools together. HardwareToad is the result: a Python UI I actually enjoy looking at, backed by a .NET bridge that talks to real low-level sensors and a C++/HLSL stress engine I wrote on top of DirectX 12.

Architecture

A two-process design splits responsibilities cleanly. The Python/Tkinter UI handles rendering and interaction; a self-contained .NET sensor bridge (LHMBridge) runs as a privileged child process and exposes local HTTP endpoints for sensor reads and stress orchestration. A standalone DirectX 12 executable (GPUStress.exe, C++/HLSL) handles GPU workloads — zero dependencies for end users.

• main.py — application entry point.
• core/app.py — all UI: tabs, cards, ring gauges, graphs, settings.
• core/bridge.py — HTTP client for LHMBridge (token attached, retries, typed responses).
• core/stress_manager.py — dispatches stress commands over the bridge.
• core/constants.py — single source of truth for version, colors, port.
• LHMBridge/LHMBridge.cs — C# sensor bridge (LibreHardwareMonitor + local HTTP).
• GPUStress/ — native DX12 engine: C++ source, pre-built GPUStress.exe, HLSL shaders.
• vendor/ — checked-in LibreHardwareMonitor runtime files.
• dev.bat — fast local run, auto-elevates, rebuilds the bridge when needed.
• build_all.bat — full clean release build: bridge → PyInstaller → Inno Setup installer.

Security model

The local bridge holds privileged access to low-level sensors, so it is treated as a security boundary, not a friendly helper.

• Token auth — 256-bit token generated at startup, required on every request via X-HardwareToad-Token. Rotates every launch.
• Token transport — passed via per-process env var (or temp file for elevated launches), never via CLI args visible to other local processes.
• SHA256 integrity — the bridge binary is hashed on first run; any modification blocks startup.
• Obfuscar — LHMBridge.dll symbols renamed at build time to slow down decompilation.
• Restricted CORS — origin is reflected only for 127.0.0.1 / localhost; no wildcard.

Stress engine

All CPU/memory workloads run natively in the .NET bridge — no Python GIL, no subprocesses. Threads are pinned to cores with one core reserved for UI/system responsiveness. GPU workloads run in a separate native DX12 executable.

• CPU Single Core — 1 thread, 12 independent AVX2 FMA chains, maxes single-core boost clock.
• CPU Multi Core — same FMA engine on every logical core; ~Prime95 Small FFT thermal output.
• Memory / IMC — 256MB/thread, AVX2 sequential + stride-127 + reverse passes; defeats the prefetcher.
• Linpack DGEMM — tiled 3072²3072 FP64 matmul (~58B FMAs/pass); reveals instability smaller workloads miss.
• Combined — every thread runs FMA + memory pass simultaneously for max package power.
• RAM Stability — 15 write/read patterns with exact error reporting, reveals unstable XMP/EXPO profiles.
• GPU Core — DX12 compute shader dispatching 16M FMA threads; saturates shader cores.
• GPU VRAM — continuous 256MB transfers; saturates memory bandwidth.
• GPU Combined — Compute + VRAM + Rasterizer simultaneously; maximum GPU thermal load.

UX polish

Little things that add up when you stare at this for hours while tuning a build.

• 11 built-in themes (MSI Dragon, Cyberpunk, Matrix Green, and more), each with a complete palette for cards, accents, and graph lines.
• Per-color overrides — click any colour to customise it independently of the theme.
• Any installed system font; custom window size (presets or exact W×H).
• Every setting autosaves and restores next launch.
• Raw Sensors viewer — shows every value the bridge sees. The exact names to use when adding custom sensor labels for edge-case hardware.
• Auto-elevation — UAC prompt every launch is the price of direct sensor access; no silent re-launch tricks.

Build & distribution

• dev.bat — the only command needed during development.
• build_all.bat — full release pipeline: compile LHMBridge, freeze UI with PyInstaller, package with Inno Setup.
• Version bump is one line in core/constants.py — installer version follows automatically.
• Installer registers the app to launch as Administrator by default and optionally drops a desktop shortcut.

Requirements

• Windows 10+ (64-bit).
• Python 3.11+ (source builds only).
• .NET SDK (to build LHMBridge from source).
• Inno Setup 6 (to produce the installer).
• Administrator rights at runtime (mandatory for sensor access).

Recent releases