Optimize performance, reduce latency and clean up Windows 10/11 with a few clicks.
SysTuneX shows exactly what it changes, saves your original settings and lets you roll everything back.
Π ΡΡΡΠΊΠ°Ρ Π²Π΅ΡΡΠΈΡ Β· Download Β· Build from source Β· Report an issue
Windows tuning tools usually fall into one of two categories:
- one-click optimizers that do not tell you what they changed
- giant collections of registry tweaks copied from old gaming guides
SysTuneX takes a different approach.
Record before write.
Before SysTuneX changes a registry value, Windows service, DNS configuration, power scheme or boot option, it records the actual previous state.
Rollback restores your previous configuration, not an invented "default".
No undocumented magic tweaks. No silent failures. No pretending that every machine benefits from the same settings.
Go to the:
Download:
SysTuneX.exe
SysTuneX is published as a self-contained win-x64 single-file executable.
You do not need to install .NET.
Each release includes SHA256SUMS.txt.
Get-FileHash .\SysTuneX.exe -Algorithm SHA256Compare the result with the checksum included in the release.
SysTuneX requests elevation automatically because system tuning requires access to the registry, Windows services, networking, power configuration and boot settings.
The executable is currently not code-signed, so Windows SmartScreen may display a warning.
| Area | What SysTuneX does |
|---|---|
| Dashboard | Live CPU and memory monitoring, tuning status, Quick Optimize and full restore |
| Profiles | Ready-made tuning profiles for different gaming and workload scenarios |
| Gaming | Game Bar, Game DVR, fullscreen optimizations, mouse acceleration, CPU scheduling and more |
| Windows 11 | VBS, HVCI, hypervisor, Recall, Copilot, widgets, search features and other build-aware settings |
| Services | Safe service tuning with the original startup configuration recorded before changes |
| Privacy | Telemetry, advertising ID, activity history, suggestions, location, clipboard sync and optional telemetry hosts blocking |
| Network | Nagle tuning, network throttling and DNS latency testing |
| Cleanup | Temporary files, update caches, crash dumps, shader caches, thumbnails and other disposable data |
| Game mode | One switch that stops background services, raises the power scheme and frees memory β and undoes all of it |
| Automation | Game mode follows the game, or a schedule, without either one undoing what you switched on by hand |
| Sensors | GPU temperature, load and fan through NVML; CPU temperature from the ACPI thermal zone where firmware exposes one |
| Tray | Live counters on hover and the game mode switch in the menu |
| Before/after | Record the machine either side of a change and see exactly what moved |
| Diagnostics | Persistent logs, verbose logging and a complete diagnostic report |
| Change log | Full history of recorded changes with individual or complete rollback |
SysTuneX includes workload-specific profiles instead of applying the same configuration to every PC.
| Profile | Focus |
|---|---|
| π― Competitive FPS | Minimum input and background latency |
| π Battle Royale | Network latency and asset-streaming workloads |
| π Open World & RPG | Long sessions, CPU availability and reduced background I/O |
| ποΈ Racing & Simulation | Frame-time consistency and latency |
| π₯ Streaming & Recording | Gaming performance without starving OBS or capture workloads |
| π Maximum Performance | Includes advanced changes for users who understand the trade-offs |
Profiles automatically skip tweaks that do not apply to the current Windows build.
Advanced changes are never silently mixed into normal safe optimization.
One switch on the dashboard. It stops the background services the catalog grades as safe, raises the power scheme and frees memory.
It is deliberately not "apply a profile under another name". A profile writes registry values that survive a reboot and are undone from the change journal. Game mode only does things that can be undone immediately: services are stopped, not disabled, so their start type is untouched and the next boot is exactly as it was, and the previous power scheme is recorded and put back. Nothing it does needs a reboot, so switching it off really restores the machine instead of leaving it half-tuned.
The session is written to disk, so an interrupted one can still be turned off and restored rather than stranding a dozen stopped services.
Turn on automatic game mode and SysTuneX watches for a game starting: twenty-five are recognised out of the box, and anything else is a one-field addition by executable name.
A schedule holds game mode on during a window of the day, optionally on chosen days. It is evaluated against the clock once a minute rather than set as timers on the two edges β a timer misses its moment whenever the machine sleeps through it, and a missed edge would leave game mode stuck on. A window that ends before it starts runs past midnight and belongs to the day it began.
Neither undoes what you switched on by hand. Turning game mode on yourself at 23:05 outlives a schedule that ended at 23:00, and a game exiting does not end a session you started.
Automation runs only while SysTuneX is open. Doing it with the app closed would mean a Windows service, and a background service that stops other services is a much bigger thing to ask someone to trust.
GPU temperature, load and fan speed come from NVIDIA's NVML, which ships with the driver and needs no install. CPU temperature comes from the ACPI thermal zone where firmware exposes one β that is a board thermal zone rather than the CPU package, and the dashboard says so.
SysTuneX ships no kernel driver, and will not. Reading a CPU package temperature properly needs a ring-0 helper, and the off-the-shelf ones are on Microsoft's vulnerable driver blocklist and trip anti-cheat. That is not a trade worth making in a tool people install to play games.
So a reading appears only when a sensor actually answered. Where none does, the card says so and why β a missing reading is not zero degrees. AMD and Intel GPUs report no temperature yet; their vendor libraries are not wired up, and saying so beats inventing a figure.
Record the machine before a change and again after it, then compare the two. The result names every tweak that became applied, every service that started or stopped, and a changed power scheme.
It is not a performance measurement and does not pretend to be. SysTuneX cannot see frame times; for those, run the same benchmark on both sides and compare it yourself. Memory and process counts are reported only when they move further than they drift on their own β listing a 3 MB difference as the effect of a tweak would be a lie dressed as data.
SysTuneX is built around reversibility and visibility.
The previous state is journaled before the system is modified.
If a registry value existed before SysTuneX changed it, its original value is restored.
If the value did not exist before, rollback removes it instead of inventing one.
Tweaks are classified by risk.
Advanced changes require explicit confirmation and explain the possible consequences before being applied.
Windows 11-specific settings are only offered where the corresponding feature actually exists.
Failed registry writes, service operations and system commands surface their real error instead of being reported as successful.
SysTuneX calculates the target paths, file count and total size before cleanup.
The rollback journal is stored at:
%ProgramData%\SysTuneX\backup.json
It records the state required to restore supported changes, including:
- registry values
- Windows service configuration
- DNS settings
- power configuration
- boot-related options
The Change Log page can restore individual entries or roll back the recorded configuration.
The journal can also be exported as JSON.
Application logs are stored in:
%ProgramData%\SysTuneX\logs
SysTuneX keeps one log file per day and retains logs for seven days.
Messages shown in the UI are logged as well, so the interface and diagnostic log describe the same event.
Enable Verbose logging to additionally record registry reads and executed system commands.
The Build a report function collects useful troubleshooting information such as:
- Windows build and edition
- hardware information
- elevation state
- recorded changes
- recent application logs
Startup failures are additionally written to:
%ProgramData%\SysTuneX\errors.log
SysTuneX includes several network-oriented tuning functions.
Available providers include:
- Cloudflare
- Quad9
- OpenDNS
- AdGuard
SysTuneX measures response latency before you choose a resolver.
Settings such as Nagle's algorithm are applied where Windows actually stores them - per network adapter.
- Windows 10 version 1809 / build 17763 or newer
- Windows 11
- x64
- Administrator rights
Availability of individual tweaks may depend on:
- Windows version
- Windows edition
- build number
- hardware
- installed drivers
Unsupported tweaks are filtered instead of being blindly written.
| Component | Technology |
|---|---|
| Language / Runtime | C# / .NET 9 |
| Desktop UI | WPF |
| UI framework | WPF UI 4.3 |
| Architecture | MVVM |
| MVVM toolkit | CommunityToolkit.Mvvm 8.4 |
| Dependency injection | Microsoft.Extensions.Hosting |
| Windows integration | Win32 API, Registry, WMI |
| System tooling | powercfg, netsh, bcdedit, ipconfig |
| Testing | xUnit |
| CI/CD | GitHub Actions |
SysTuneX separates operating-system logic from the desktop interface.
SysTuneX/
βββ src/
β βββ SysTuneX.Core/
β β βββ Abstractions/
β β βββ Models/
β β βββ Native/
β β βββ Services/
β β βββ Tweaks/
β β
β βββ SysTuneX.App/
β βββ Controls/
β βββ Converters/
β βββ Localization/
β βββ Resources/
β βββ ViewModels/
β βββ Views/
β
βββ tests/
β βββ SysTuneX.Core.Tests/
β βββ SysTuneX.App.Tests/
β
βββ .github/workflows/
Contains system operations and tuning logic without a dependency on the WPF UI.
Contains the WPF interface, navigation, resources, localization and view models.
System changes are performed through the Core services instead of directly from the UI layer.
Every push and pull request is validated on a Windows GitHub Actions runner.
The pipeline performs:
Restore
β
Build
β
Core tests
β
WPF startup tests
β
Publish win-x64
β
SHA256 checksum
β
Release artifact
The WPF startup suite creates the real application, loads its resources and constructs the main window and pages.
This catches runtime XAML failures that a successful compilation alone cannot detect.
Releases are published from the default branch only. A release cut from a feature branch would
describe code nobody has merged, and would leave its tag on a commit that may never reach main.
- Add a
## vX.Y.Zsection at the top ofCHANGELOG.md. - Put the same version in
release.version. - Merge to
main.
CI then builds, tests, publishes SysTuneX.exe and SHA256SUMS.txt, and creates the release
with only that version's changelog section plus the shared footer.
A version with a suffix β v2.5.0-rc1 β is marked as a pre-release; a plain v2.5.0 is not.
Re-running the job on an unchanged version only refreshes the assets, so it is safe to repeat.
Requirements:
- .NET 9 SDK
- Windows for the complete WPF test suite
Clone the repository:
git clone https://github.com/Anton-Babaskin/SysTuneX.git
cd SysTuneXRestore and build:
dotnet restore
dotnet buildRun the Core tests:
dotnet test tests/SysTuneX.Core.Tests/SysTuneX.Core.Tests.csprojRun the startup tests. These need a real WPF stack, so they only do anything on Windows:
dotnet test tests/SysTuneX.App.Tests/SysTuneX.App.Tests.csprojPublish a self-contained executable:
dotnet publish src/SysTuneX.App/SysTuneX.App.csproj `
-c Release `
-r win-x64 `
--self-contained true `
-p:PublishSingleFile=true `
-p:PublishReadyToRun=trueSysTuneX changes system configuration. It does not promise a specific FPS increase.
If you want to measure whether a configuration improves your system, compare the same workload before and after using metrics such as:
- average FPS
- 1% and 0.1% lows
- frame-time consistency
- input latency
- DPC / ISR latency
- CPU and memory utilization
- network latency and packet loss
Use the same game scene, graphics settings and test duration for both runs.
Issues and pull requests are welcome.
When adding or changing a tweak:
- keep system operations out of the UI layer
- record the original state before modifying it
- distinguish between an absent registry value and a value set to
0 - validate Windows build requirements
- prefer documented Windows APIs and policies
- add or update catalog tests
SysTuneX modifies Windows settings related to performance, networking, privacy, services, power management and system behavior.
Although supported changes are recorded for rollback, no tuning tool can guarantee identical results across every Windows installation, hardware configuration or software stack.
Review advanced changes before applying them and consider creating a Windows restore point when testing development builds.
SysTuneX is released under the MIT License.
Built for people who want to know what their optimizer actually changed.