Every known issue — and the two-click fix

Expected for preview builds — the preview isn't code-signed yet, so Windows shows the blue filter for any new publisher it doesn't know. Nothing is wrong with the file.

1. Click More info (the underlined text, not the big button).
2. Click Run anyway — now visible on the right.
3. Optional certainty: compare the SHA-256 on the download page — if it matches, the file is byte-identical to ours.

Get-FileHash .\ProofTune-0.1.0-preview.1-win-x64.msi -Algorithm SHA256 Signed releases won't trip this screen at all.

Your machine applies a stricter SmartScreen policy (managed by an organization, or the setting is at "Block"). Either ask your admin to allow the file, or right-click the MSI → Properties → tick Unblock → OK → run again. The "Unblock" checkbox only takes effect when the file was downloaded from the internet.

Edge/Chrome warn on any fresh unsigned installer — it's reputation, not a detection. Choose Keep / Keep anyway. To reassure: the file we ship is hashed on the download page; compare anytime, and VirusTotal is one upload away if you want third-party eyes.

A broken download always fails the hash check — that check is why we publish it. Re-fetch the file and compare (Get-FileHash …).Hash. If it still mismatches, the mirror copy is stale; ping back and we'll bump it. Never install a partial MSI.

Settings → Apps → search ProofTune → Uninstall first, then run the new MSI. The installer uses the same UpgradeCode so a true upgrade is seamless, but a direct re-run of the same product always asks you to uninstall first — that's standard MSI behavior, not a bug.

Windows Installer refuses to overwrite files whose FileVersion is equal. If you're seeing this, remove the app via Settings → Apps (clean per-user removal — nothing sticks behind), then install the new candidate. Later preview releases bump assembly versions precisely to avoid the trap.

Almost always a XAML-resource load failure. Open %LOCALAPPDATA%\ProofTune\logs\preview-trace.log — the last lines say exactly which resource failed. Then Settings → Apps → ProofTune → Repair. If the log is empty or the folder doesn't exist, reinstall over the top — the installer self-heals the payload.

GPU-composition hiccup on the local machine. Close it, wait 2 seconds, and launch again from the Start menu shortcut. If it persists: Settings → Apps → ProofTune → Repair. (We ship self-contained; nothing on your machine needs updating for this app.)

Use the same log at %LOCALAPPDATA%\ProofTune\logs\preview-trace.log — the nav.* / optimize.* traces show exactly which card was rendering. Then restore defaults (there's a one-click restore on the very page) and re-open. The page never crashed the system — the process is contained to itself.

Preview builds don't register an autostart entry — by design. Launch from the Start menu whenever you need it. (The startup manager shows your existing entries and lets you disable them — that's one click less on every sign-in.)

That's the honest result — it only counts profile temp/cache files older than 24 hours and skips anything locked or in use. Zero means your profile is already tidy. (Run it a week later and you'll see actual numbers.)

Approval changes take effect at the next sign-in — the current session has already read them. Sign out & sign in, or restart Explorer (taskkill /f /im explorer.exe && start explorer.exe) to force an immediate reread of the approval stamp.

Correct — the documented default for those policy-adjacent values is absent. Restoring means deleting the value so Windows falls back to its built-in policy. This is the difference between restoring and writing an opposite value (which some tools unfortunately do).

The heartbeat only advances when the walk moves to a new directory — a very dense folder stalls it visually. It's bounded and cancelable: click Cancel. The busy bar is proof the process is alive; there's no lawn to mow.

It targets menu delay and animation durations — most visible in long cascades of menu opening. Drag a title bar, right-click a file, hop Alt-Tab. If you prefer stock, the restore button reproduces the documented defaults on the very next click.

No. Prove it on your own machine: netstat -ano | findstr "<PID>" Run the app, exercise every feature, watch the output stay silent. Our manifest — installed next to the app — lists every file that ships and every gate run.

Only things under your account: seven visual settings, four privacy values, startup approval stamps, and stale profile caches. Machine-scope registry hives, other users' profiles, services, drivers and power plans are architecturally untouched — the app never even asks for elevation.

Not yet — that's the "closed" in Closed Technical Preview. What you get instead: the candidate manifest, per-build hashes, gate logs per build, and an installer database you can inspect with any MSI reader. The public release plan includes source publication.

Diagnostics read support-policy values (editions, builds) to tell you what features are available on your machine — read-only probes, never writes. Every touch is journaled, and the privacy preset never writes policies — it only writes values the Windows Settings app itself toggles.

Settings → Apps → ProofTune → Uninstall. Files, shortcuts, logs — all packaged inside the installer with matching removal. Unlike most tools we never created services, drivers, or scheduled tasks, so there is nothing left to hunt. Restart to drop the shell's file locks if Windows complains about "files in use".

Close every ProofTune window first (check the tray). If you still get the error, run msiexec /x "{ProductCode}" /forcerestart — the restart cleanly releases the locks.

Human-level: each Settings page in the app has restore buttons (performance defaults, privacy defaults, startup entries). Even simpler: uninstall — since the install scope is per-account and no machine artifacts exist, nothing persists after uninstall. Your journal is local too.