ThreadPilot v1.7.4

Changelog

All notable changes to ThreadPilot are documented in this file.

v1.7.4 - 2026-08-26

Chores

• Bump to 1.7.4 (de40640)

Features

• Resize custom masks on a CPU change, and edit a rule's cores from Rules (406352f)

Refactoring

• Delete ReviewRequired, keep the check, point it at saved rules (9875f7c)

• Delete the CPU preset generator, which nothing resolved (15055cd)

What's Changed

• ThreadPilot 1.7.4 — masks that follow the CPU, rules you can finish editing by @PrimeBuild-pc in #56
• Delete ReviewRequired and the dead preset generator, keep the check by @PrimeBuild-pc in #57

Full Changelog: v1.7.3...v1.7.4

ThreadPilot v1.7.3

This release started from a single user report: a CPU assignment was applied, saved as a rule, and on the next launch of the game nothing seemed to happen. The rule was being applied — in a mode that changes nothing you can see. Pulling that thread turned up a family of related problems, and they are all fixed here.

If you had a rule that seemed to do nothing

Your saved rules are migrated automatically the first time you launch 1.7.3.

Windows offers two ways to steer a process onto specific CPUs: a real affinity mask, which is a hard constraint and is visible in Task Manager, and CPU Sets, which are only a scheduling hint and leave the affinity mask untouched. The old "ThreadPilot automatic" mode used CPU Sets. Version 1.7.1 changed the default to Affinity Mask, and 1.7.2 moved existing profiles over — but rules already saved kept the mode they were captured with, forever. So a rule saved before 1.7.1 kept applying an invisible hint on every process start, indistinguishable from a rule that never ran.

Those rules are now moved once, automatically. If you had a rule that "did nothing", it should simply start working. Rules where you deliberately chose CPU Sets or Ideal Processor are left exactly as they are.

Saved rules are no longer invisible

Rules saved from the Process tab context menu had no interface at all — you could create them and nothing else. The Rules page now has a Saved process rules tab that lists them, spells out what each one applies, and lets you edit, disable or delete them. It also says plainly how they differ from the power plan rules next to them, which are a separate system.

Two related fixes:

• "Apply CPU assignment and save as rule" no longer silently drops your memory and I/O priority from a rule that already had them.
• Saving a rule for a process now records the settings that are actually on it, rather than partially overwriting what you saved a minute earlier.

Buttons that did nothing, or lied

• "+ Custom" in the affinity picker did nothing at all — it looked for a UI element that has not existed for several versions. It now opens the CPU Masks page, which is what its tooltip always promised.
• Clearing CPU Sets left the core chips showing the assignment that had just been removed, so a rule saved right after captured the wrong cores.
• Successful actions left no trace. Applying an assignment or a priority set a confirmation and then wiped it before you could read it, while failures stayed on screen. Confirmations now stay up and fade on their own — for CPU priority, memory priority, I/O priority and registry enforcement too, not just affinity.

System Tweaks

• Ethernet power saving and interrupt moderation reported themselves unavailable with a raw Windows error on many machines. A single network adapter the app could not read — VPN and vendor virtual adapters ship with tighter permissions — aborted the entire scan, even when every real Ethernet adapter was readable. They are detected properly now.
• Memory Integrity (HVCI) read only one registry location, which several Windows builds leave empty, and reported "not exposed by Windows". It now reads where the running state actually lives.
• Those failures used to display a raw framework message. Errors go to the log; the card gets a sentence you can act on.
• Three buttons on that page were unreadable in dark theme — near-white text on near-white chrome. Fixed.

Windows and masks

• Restoring a maximised window left it filling the screen, so it had to be dragged back by a border. It now returns to the exact size and position it had before, on the monitor it was on.
• Custom CPU masks drawn on a different CPU used to keep selecting the old cores under a name that no longer described them. The Masks page now names the ones that need a look. Built-in masks are re-derived automatically; the ones you drew are yours, so ThreadPilot asks instead of redrawing them.

Notes

Rules are applied by ThreadPilot while it is running, including when it sits in the tray — closing the window keeps it working. Quitting from the tray stops it, and restores what it changed, which is what the "Reset process changes on exit" setting controls.

No configuration is lost by updating, and nothing needs to be re-created by hand.

---

Download: ThreadPilot_v1.7.3_Setup.exe (installer) or ThreadPilot_v1.7.3_Portable.zip (portable). Verify with SHA256SUMS.txt.

Full changelog: v1.7.2...v1.7.3 · #55

ThreadPilot v1.7.2

A follow-up to v1.7.1 that closes the gap which stopped that release reaching the people who needed it.

What was still wrong

v1.7.1 changed the shipped default CPU assignment mode from ThreadPilot automatic to Affinity Mask, because Automatic applies only Windows CPU Sets: a soft scheduling preference that leaves the affinity mask shown in Task Manager unchanged.

But a new default only applies to a profile that has no stored value. Everyone upgrading had one, so they kept Automatic and kept seeing an affinity feature that appeared to do nothing.

Verified against the published 1.7.1 build:

existing profile (settings.json present) -> DefaultCpuAssignmentMode = 0  (Automatic)
fresh profile    (settings.json absent)  -> DefaultCpuAssignmentMode = 1  (Affinity Mask)

What 1.7.2 does

• A one-time migration moves a stored Automatic to Affinity Mask on first launch, and records that it ran.
• A one-time notice, styled like the rest of the app and shown in your language, explains that the mode changed and why, with a shortcut to Settings. It appears only for profiles the migration actually moved, and only until you acknowledge it.
• Your choice is respected afterwards. The migration never runs twice, so selecting ThreadPilot automatic again is kept.
• Fresh installations are unaffected — they already ship with Affinity Mask and see no notice.

Robustness

• A failed settings write is no longer fatal. Previously it fell into the load handler's catch, which replaced the profile just loaded with defaults and silently swallowed the notice. It is now retried on the next launch.
• An out-of-range stored mode repairs to the shipped default rather than to Automatic, so corrupt data is not reported back to you as a choice you made.
• The notice is queued behind the first-run startup suggestion rather than stacked on top of it, and takes keyboard focus when shown.

Verification

721 unit tests, covering an upgraded profile, a fresh profile, every non-Automatic mode, idempotency, a deliberate return to Automatic, a corrupt stored value, and a failed migration write.

The full chain was also driven against a real build through UI Automation on a seeded 1.7.0 profile: migration applied, notice queued behind the startup suggestion, revealed on dismissal, acknowledged, persisted, and absent on the next launch.

Downloads

File	Purpose
ThreadPilot_v1.7.2_Setup.exe	Installer (recommended)
ThreadPilot_v1.7.2_Portable.zip	Portable build, no installation
SHA256SUMS.txt	Checksums for both files

Full changelog: v1.7.1...v1.7.2

ThreadPilot v1.7.1

A patch release that makes the CPU affinity feature do what its name says.

A user reported that applying a rule did nothing to a process's affinity. They were right, and for more than one reason.

The headline fix

Applying a saved rule, or a core mask from the Rules tab, now changes the affinity mask Windows actually enforces.

Two defects combined to hide this:

• SetProcessorAffinity silently substituted a Windows CPU Sets hint for the hard affinity write it was asked to perform, while its caller read the affinity back and compared it. The apply therefore always reported a verification failure — and the affinity was never changed. Reproduced on a 16-CPU machine: requesting cores 0–1 left the process at 0xFFFF and returned a failure.
• The shipped default assignment mode was ThreadPilot automatic, which applies only CPU Sets: a soft scheduling preference that leaves the affinity mask you see in Task Manager untouched. It was reported to the user as "Affinity applied successfully".

The default is now Affinity Mask, and a CPU Sets result states plainly that it is a soft preference and that Task Manager will not reflect it.

Existing rules keep the mode they were saved with. If a rule still isn't taking visible effect, open it and pick Affinity Mask.

The controls were not on screen

The CPU assignment mode picker and the Apply CPU Assignment button — both added in v1.6.0 — were placed inside a side panel that had been collapsed since v1.2.0. Neither had ever been reachable in a shipped build. The only way to apply affinity was the process-list context menu, and the only way to change the assignment mode was the default buried in Settings.

That is precisely why the reporting user had no way to reach the control that would have fixed their problem.

Both controls now live in the Advanced Affinity Picker, which opens expanded. The 326-line collapsed panel is gone.

Also fixed

• "Save Current Settings as Rule" no longer saves a rule pinned to every CPU. It captured the core selection only while edits were staged, and otherwise fell back to a process affinity that the soft modes never changed — producing a rule guaranteed to do nothing.
• Automatic mode no longer installs CPU Sets that an existing hard affinity prevents Windows from honouring. Windows never schedules a process outside its affinity mask whatever CPU Sets are set, yet the read-back still "verified". It now applies the hard affinity, which can genuinely replace the restriction.
• Saved rules resolve CPU Sets against the current topology instead of trusting the CPU Set IDs stored when the rule was created. Those IDs are opaque and can name a different processor after a hardware change; a stale rule now reports an invalid topology rather than silently pinning the wrong CPUs.
• Affinity masks that include CPU 63 are no longer discarded. They are negative as signed 64-bit values and were being rejected by magnitude comparisons.

Interface

• The per-CPU cells in the Advanced Affinity Picker are read-only chips instead of checkboxes, with a hint explaining that a selection is staged through the pending core mask. They were never clickable — they only looked it. The chips keep their accessible name and report selected, not selected, or unavailable.
• System tweak toggles are larger and state ON or OFF inside the track, replacing the unlabelled 40×20 switch. The label is localized and widens the control rather than being clipped.
• Saving a rule from the process context menu now explains that the rule is re-applied automatically when the process next starts, and that these rules are separate from the Rules tab, which manages process-to-power-plan associations.

Localization

Corrected "core mask" mistranslations in the Italian, Spanish, French and Russian locales, and German phrasing for the Rules tab and power plans.

Notes

• Memory Integrity, hardware-accelerated GPU scheduling, and windowed-game optimizations still show a link to the relevant Windows page instead of a toggle. Those are deliberately left to Windows.
• Applying affinity to a process protected by anti-cheat still fails, by design. ThreadPilot reports it and does not attempt to bypass protection.

Verification

707 unit tests, including new regression tests that fail against the previous implementation. The affinity fix was verified end to end against a live process: requesting cores 0–1 now moves it from 0xFFFF to 0x3.

Downloads

File	Purpose
ThreadPilot_v1.7.1_Setup.exe	Installer (recommended)
ThreadPilot_v1.7.1_Portable.zip	Portable build, no installation
SHA256SUMS.txt	Checksums for both files

Full changelog: v1.7.0...v1.7.1

ThreadPilot v1.7.0

ThreadPilot v1.7.0

ThreadPilot 1.7.0 expands Windows gaming and device controls, adds persistent per-process I/O and power behavior, and prepares the release pipeline for trusted Authenticode signing.

Highlights

• Control Game Mode, CPU Core Parking, supported CPU C-State behavior, USB selective suspend, pointer precision, supported Ethernet power-saving properties, interrupt moderation, and GPU MSI Mode.
• Open the correct Windows pages for Memory Integrity, HAGS, and windowed-game optimizations without silently weakening Windows security.
• Set memory and I/O priority per process and preserve them in persistent rules.
• Prevent system sleep while a selected process is running through a Windows power request that is released automatically.
• Restore backed-up device-driver values when supported tweaks are turned off.
• Open community power-plan and support links on demand, or report a problem directly through GitHub Issues.
• Use every new control and support action in all seven supported languages: English, Italian, German, Spanish, French, Russian, and Simplified Chinese.

Power-plan distribution change

ThreadPilot no longer bundles the 89 third-party .pow files previously shipped with the application. Those files were publicly available, but no reliable per-file license or redistribution permission could be verified. Removing them keeps the signed release payload compatible with the SignPath Foundation requirement that distributed components have clear open-source redistribution rights.

This does not remove functionality or user data:

• Power plans already imported into Windows remain installed and active.
• An upgrade does not delete .pow files left by an earlier ThreadPilot installation.
• Manual .pow import remains available.
• The new More plans? action opens the ThreadPilot community Discord only when the user clicks it; no plan is downloaded automatically or included in the signed package.

Compatibility and safety

• Existing rules remain compatible; all new persistent options default to off.
• Ethernet and GPU controls only modify properties already exposed by the installed driver and require administrator privileges.
• Hardware and driver behavior varies. GPU MSI Mode and some Windows graphics or security changes may require a restart.
• Memory Integrity remains a user-controlled Windows Security setting.

Validation

• 701 automated Release tests pass, including XAML compilation and localization-key coverage for all seven languages.
• The final portable and installer artifacts contain zero .pow files.
• A Windows 11 Hyper-V gate passed portable launch, clean install, normal launch, system-tweak apply/restore, upgrade, and uninstall checks without ThreadPilot application errors.
• A real 1.6.0 to 1.7.0 installer upgrade preserved all 89 legacy .pow files byte-for-byte and did not change the active Windows power plan.

Signing status

Release artifacts remain unsigned while the SignPath Foundation application is pending. The automated build, test, packaging, checksum, SBOM, and publishing flow remains in place, including its existing optional Authenticode path. The SignPath-specific integration will be added and tested separately after approval.

ThreadPilot v1.6.0

ThreadPilot 1.6.0 expands CPU assignment controls while keeping the previous ThreadPilot behavior as the default.

What's new

• Four assignment modes: ThreadPilot automatic, Affinity Mask, Ideal Processor, and CPU Sets.
• ThreadPilot automatic remains the default and preserves the established CPU Sets → safe Affinity fallback behavior.
• The global default and per-process rule overrides are saved persistently.
• Affinity is topology-aware and supports processor groups and CPU indexes above 63 through per-thread assignment.
• Ideal Processor distributes selected CPUs across threads with deterministic round-robin assignment and verification.
• Explicit CPU Sets and Ideal Processor modes never use a hidden Affinity fallback.
• Reserved CPU Sets are shown as read-only information; ThreadPilot does not modify the global Windows configuration.
• UI guidance and mode descriptions are available in all seven supported languages.

Compatibility and safety

Existing settings and rules remain compatible and continue in ThreadPilot automatic mode. ThreadPilot does not widen an existing hard affinity restriction automatically; switching to a soft mode can require restarting the target process. When automation monitoring is disabled, Ideal Processor and multi-group Affinity affect only threads present at apply time.

Validation

• 689 automated tests passed in Debug and Release.
• CI DevSecOps, CodeQL, packaging, and the final artifact smoke test passed.
• All four modes were tested on a Windows 11 Hyper-V VM.
• Multi-group topologies and CPU indexes above 63 are covered by synthetic tests.

Known limitation

The installer and application executable are currently not Authenticode-signed, so Windows may display an Unknown publisher warning. SHA-256 checksums are included with the release for integrity verification.

Full comparison: v1.5.3...v1.6.0

ThreadPilot v1.5.3

Changelog

All notable changes to ThreadPilot are documented in this file.

v1.5.3 - 2026-08-11

Chores

• Remove temporary file (cddc7b0)

Documentation

• Add supported language badges (7cefb8c)

• Consolidate language badges (10d9130)

What's Changed

• docs: add supported language badges by @PrimeBuild-pc in #47
• docs: consolidate language badges by @PrimeBuild-pc in #48
• Fix/audit reliability hardening by @eakkawut in #46
• Prepare release v1.5.3 by @PrimeBuild-pc in #49

New Contributors

• @eakkawut made their first contribution in #46

Full Changelog: v1.5.2...v1.5.3

ThreadPilot v1.5.2

ThreadPilot v1.5.2

This release completes the Automation Monitoring fixes introduced in v1.5.1 and consolidates the related process-monitoring configuration.

Fixed

• Fixed an issue where Automation Monitoring could start again after the user had disabled it.
• The disabled state is now persisted correctly across application restarts.

Improved

• Removed duplicate WMI, fallback polling, and polling interval settings from Rules & Automation.
• Application settings are now the single source of truth used by the monitoring runtime.
• Clarified the separation between event-based WMI monitoring and periodic fallback polling.
• Preserved compatibility with existing ProcessPowerPlanAssociations.json files containing the removed fields.

Validation

• Release build completed successfully.
• All 645 automated tests passed.
• Packaging metadata, installer build, smoke tests, GitHub Release publication, and WinGet publication completed successfully.

Full Changelog: v1.5.0...v1.5.2

ThreadPilot v1.5.0

ThreadPilot v1.5.0

ThreadPilot 1.5.0 adds five languages, refines the Windows 11 experience, and makes future updates one-click.

Highlights

• Italian, French, German, Spanish, and Russian translations, with automatic Windows language detection.
• One-click updates checked at every enabled startup: consent once, then ThreadPilot downloads, verifies, installs, and restarts automatically.
• Reliable startup detection and persistence for supported Windows system tweaks.
• Native Windows power API handling for Core Parking and C-States.
• More neutral Windows 11 styling for tweaks, dialogs, and selected items.
• Fixed saving pending settings from the navigation/close confirmation dialog.

Existing settings, profiles, masks, rules, imported power plans, and logs are preserved during upgrades.

Validation

• 634 automated Release tests passed before release preparation.
• CI and CodeQL passed for both feature pull requests.
• Release single-file publish, smoke test, and Inno Setup compilation passed.

ThreadPilot v1.4.4

ThreadPilot v1.4.4

Patch release focused on reducing ThreadPilot's foreground and background runtime overhead while preserving process automation and persistent CPU-priority verification.

Measured improvements

Compared with the official v1.4.3 build on the same system and using the same Release profile:

• Approximately 80-100% lower background idle CPU in measured tray scenarios, reaching 0% in the final idle sample.
• Approximately 8% lower CPU overhead during process churn with 80 short-lived processes.
• Approximately 4-5% lower hidden working-set memory.
• Approximately 12-13% lower peak handle usage while hidden.
• Approximately 85% fewer external command launches during visible startup, reduced from 27 to 4.

Results vary by hardware, Windows configuration, active page, and workload. The Process page remains intentionally more active while visible because it refreshes live process information.

Runtime changes

• Cached persistent-rule snapshots in memory and pre-matched process starts before expensive enrichment.
• Disposed process handles consistently and cleared PID-scoped caches on process exit.
• Deferred initialization of inactive Power Plans, Rules, Settings, Tweaks, and Logs pages.
• Reused the process monitor's initial snapshot and PID/start-time-validated static process metadata.
• Parsed the active plan from a single powercfg /list call and limited periodic power-plan refresh to the visible Power Plans page.
• Suspended Log Viewer collection updates while hidden and changed log flushing to one-shot scheduling.
• Added WMI recovery backoff while preserving fallback polling reliability.

Compatibility and safety

• Persistent rules, process start/stop tracking, and lazy diagnostics remain covered by regression tests.
• CPU-priority verification and the bounded retry introduced for issue #32 are unchanged.
• No default ThreadPilot affinity limit was enabled.

Validation

• Release build completed with zero warnings and zero errors.
• All 581 automated tests passed before release preparation.
• CI and CodeQL passed for both performance pull requests.
• NuGet dependency audit found no known vulnerable packages.