w0a changes Windows settings — registry values, power plans, driver calls. It writes nothing at kernel level, installs no driver of its own, injects no code into games and reads no game memory. Every registry and power-plan change is recorded with the value that was there before, and reverts in one click.
Three steps
1. Run it. There is no installer: a single executable, right-click, "Run as administrator". Administrator rights are needed because the settings being changed are machine-wide — a per-user process cannot write them.
2. Measure first. Open Benchmark, play a minute or two of the same map, and take a capture before you change anything. This is the step people skip, and skipping it is why so much of this field is folklore.
3. Apply, then measure again. Turn on what you want — one switch at a time if you want to know which one did what — and take a second capture on the same scene with the same in-game settings.
How undo actually works
Before a value is written, the old one is read and appended to a log at %ProgramData%\w0a\backup.json, together with the key, the value name, its type, and whether it existed at all. Writes are grouped into checkpoints, so a batch you applied on Tuesday can be reverted as one unit without touching what you did on Wednesday.
The log lives in %ProgramData% rather than in your user profile because the revert runs elevated, and it takes its instructions from that file. For the same reason the file is not a free-form script: only paths on an allow-list compiled into the application can be reverted, so a tampered log cannot be used to write somewhere it should not.
The Fix page is the second half, and it does not depend on the log at all. Each card writes the Windows default back unconditionally — so a machine can be repaired even if w0a never touched it, or if the log was deleted, or if something else changed the value. That is also why the Fix page is allowed to delete values the rest of the application may not write.
The full undo procedure, step by step
What it refuses to do, and why
No kernel-level values. The Session Manager memory-management keys — paging executive, large system cache, NTFS memory usage, timer resolution requests — are refused outright, and a test in the build fails if one is ever added. The Fix page keeps the right to delete them, because an old installation from some other tool has to be repairable.
No MPO or TDR keys. Overlay test mode, overlay disable, TDR delay and TDR level are not written. On a real machine those froze CS2, and the registry page sets TdrDelay back to the Windows default rather than raising it.
No injection, no game memory. Nothing is loaded into a game process and nothing reads one. The only game files written are the CS2 config and the Steam launch options you ask for on the Launch Options page, and both are backed up first. We still cannot make promises on behalf of any anti-cheat vendor — but none of the behaviour they look for is behaviour this program has.
No driver of its own. CPU temperature and RAM timings need ring-0 reads that Windows does not expose. For those, and only if you approve it, the signed PawnIO driver is installed — it reads and never writes. Decline it and those two readings are simply unavailable.
How it measures
Frame times come from Windows' own event stream. There is no overlay, no hook and no injected DLL: the same events the operating system already emits are consumed and turned into average FPS, 1% low, and stutters per minute. The 1% low is the figure that matters — an average can rise while the game feels worse, and that is exactly the case a single average hides.
Input latency is measured from real mouse movement: the report interval is timed as reports arrive, so the polling rate shown is what the device actually delivers rather than what its box claims. Alongside it, the DPC and ISR time of every driver on the machine is sampled, which is what lets a stutter be traced to the driver causing it instead of guessed at.
Before and after are paired. Results are stored as pairs, and a comparison is only offered when both captures exist. A number with nothing to compare it against is not evidence of anything.
How to read the latency figures
Why it goes quiet during a match
Reading a graphics sensor takes a lock inside the graphics kernel. Polling every two seconds while a game is running produced a visible hitch on a real machine — the tool advertising smoother frames was itself costing frames. So hardware polling stops the moment a full-screen application is in the foreground and resumes when it is not. The same rule applies to the bus scans and the process walks.
Everything starts switched off
On a fresh installation every background engine is off — priority boosting, background balancing, reserved cores, the indexer hold, the sleep guard. Each is a deliberate choice made by you, on its own switch, and each says what it will do before it does it. An engine that fails five passes in a row stops itself and says why rather than failing quietly for the rest of the session.
What is not measured, and what is not promised
How much any of this helps depends on the machine, the game and the network route, and w0a does not pretend otherwise. There is no "10x FPS" claim anywhere in the product. Network changes cannot improve a route that is already saturated; a CPU already sitting at its power limit will not clock higher because a plan changed. What the tool guarantees is narrower and checkable: it says what it changed, it changed nothing else, and it can put every one of those changes back.