Automatic Test Mode: run until every core has a final value, persist per-core results, continue after resume (#106)

[kristofferkhansen]

Automatic Test Mode: run until every core has a final value, persist per-core results, continue after resume (#106)

Replaces #181 — same branch, plus fixes for three issues found during live testing on a Ryzen 9 9950X3D (details at the bottom).

Problem

Running the Automatic Test Mode (e.g. configs/Ryzen.AutomaticTestMode.Start.ini, startValues = Minimum) on a modern Ryzen frequently ends after effectively testing only the first core, reporting a Curve Optimizer value for that core alone. Two independent defects cause this:

1. Every crash restarts the whole run (this is Enhancement: Continue with the remaining core test order after automatic resume #106). The .automode file only stores lastCoreTested + voltageValues — there is no record of which cores already finished. After each reboot the script rebuilds the full core order, restarts at iteration 1, and prepends the crashed core. With an aggressive start value that hard-freezes the machine (common at -50 on Zen 4/5), the run spends its whole life stepping the first core from -50 upward and never reaches the others.
2. The only ATM "done" abort counts duplicates against a unique count. $coresWithErrorAndMaxVoltageValue is appended without a uniqueness check from both the in-loop error handler and the RESUME handler, then its .Count is compared to $numUniqueAvailableCores (and the compared value is stale — only refreshed inside the core loop). A single core pinned at maxValue across several crash/resume cycles inflates the counter until the script announces "All Cores have reached the maximum Curve Optimizer value and thrown an error, aborting!" while 15 cores were never tested.

On top of that, the finally block deletes .automode on every exit, so any values that were found only ever existed in the console/log output.

What this PR does

One new concept: a per-core state machine ($coreStates: pending → testing → confirmed / unstable, plus ignored), persisted across crashes, which drives all ATM scheduling:

• A core is confirmed after passesToConfirmCoreValue (new setting, default 3) consecutive error-free test runs at an unchanged value. Any error charged to the core bumps its value by incrementBy and resets the counter.
• A core is finished before the next one starts (repeatCoreUntilConfirmed, new setting, default 1): after a successful test run the core is re-inserted at the front of the test order — the same mechanism repeatCoreOnError already uses after an error — so its confirmation passes are collected back-to-back instead of one per full sweep of the core order. Aborting a run early therefore still leaves you with final values for the cores tested so far. Set to 0 to collect passes round-robin across the order instead (the Intel example config does, since a single voltage offset is shared by all cores there).
• A confirmed core is never tested again — not in later iterations, not after a crash/resume.
• Results are persisted immediately: the moment a core is confirmed (or terminally unstable), a timestamped line is appended to a permanent, human-readable results file next to the log — it survives crashes, reboots and later runs.
• The run ends when every core is resolved (confirmed / user-provided / terminally unstable at maxValue). In ATM, maxIterations no longer governs the loop (its default of 10000 made it meaningless there); classic-mode semantics are unchanged. Termination is provable: values increase monotonically toward maxValue, and an internal sanity limit catches pathological cores.
• Resume continues the order (Enhancement: Continue with the remaining core test order after automatic resume #106): .automode now stores per-core states, the current iteration and the remaining core order (written atomically, previous generation kept as .automode-bak until the next good write). After a crash the crashed core is retested first (with its value bumped), then the order continues exactly where it left off; resolved cores are skipped.
• knownGoodValues (new setting, e.g. knownGoodValues = 3:-25, 7:-18): declare values you already trust from a previous run. Those cores are seeded as confirmed (source = config), never tested, and marked as user-provided in the summary and results file. The results file ends with a ready-to-paste knownGoodValues line. Fatal error on Intel (per-core values are an AMD concept).
• Crash-window hardening: after a resume, the crashed core's adjusted value is persisted before any voltage is applied to the CPU (previously the crash-causing value could be re-applied first with setVoltageOnlyForTestedCore = 0); terminal results are merged back from the results file on resume, so a torn state write can never lead to retesting a confirmed core; a persisted no-progress boot counter aborts a pathological crash-reboot loop after ~10 attempts (new exit code 7) and cleanly removes the scheduled task; the startup helper falls back to the backup state generation on any primary read/validation failure.
• The end-of-run summary gains a per-core status row (OK / CFG / MAX / skipped) and the banner/exit code now reflects the actual outcome (no success banner while cores are unresolved).

WHEA errors without a usable APIC ID are no longer attributed to core 0

Convert-WheaMessageToApicId returns a negative value for any WHEA entry it cannot parse (any event id other than 18/19 — e.g. id 47, "corrected machine check", component Memory — or an entry without a Properties member). Convert-WheaMessageToCoreId fed that straight into the $coresInfo['apicIdToCore'] hash table; a missing key returns $null, and [Int] $null is 0, so every unattributable WHEA entry was silently reported as core 0. With treatWheaWarningAsError = 1 that meant a false error against core 0 whenever it was under test, and a silent "does not match the tested core" warning (APIC ID -1) for every other core — the test run then still counted as clean. The same applied to valid APIC IDs that are not in the map (possible on parts whose APIC IDs have gaps, e.g. a 5900X). Such entries are now treated as an error for the currently tested core — since no core can be ruled out, letting them pass silently would allow an unstable core to be confirmed — and the APIC ID / core are displayed as "not available" instead of a wrong number. (Found live: an event id 47 fired mid-test and was waved through.)

Fixed along the way

• The alternate core order builder produced duplicate/incomplete orders for odd physical-core counts (e.g. 5 cores → 0,2,4,2,4, cores 1 and 3 never tested — also affects classic mode). It now covers all cores for any count; even counts produce the exact same order as before.
• Split-Path -LiteralPath ... -Leaf cannot bind to any parameter set (LiteralPathSet has no -Leaf) and throws "Parameter set cannot be resolved" at runtime. Both call sites were on the crash-resume path only: one aborted every resume with a fatal error (which also deleted the .automode state), the other silently prevented re-using the previous run's log file. Both now use [System.IO.Path]::GetFileName(). (Found live: the first actual crash-resume on the 9950X3D died on this.)
• The duplicate-accepting ArrayList adds ($coresWithErrorAndMaxVoltageValue, $coresWithIncreasedVoltageValue) are now guarded.
• The stress-test-log shrink guard in Get-NewLogfileEntries no longer permanently disables pass detection if the log file is recreated smaller after a stress-program restart.
• corepairs resume: $_ used outside a pipeline (always $null under Set-StrictMode 3.0).

New settings ([AutomaticTestMode])

Setting	Default	Meaning
passesToConfirmCoreValue	3	Consecutive error-free test runs at an unchanged value before a core counts as good
repeatCoreUntilConfirmed	1	Stay on a core until it has a final value; 0 collects passes round-robin across the core order
knownGoodValues	(empty)	Per-core values to trust without testing, e.g. 3:-25, 7:-18

All are documented in configs/default.config.ini and readme.txt; the ATM example configs surface them.

Compatibility

• Classic (non-ATM) mode: control flow byte-for-byte unchanged (maxIterations, error handling, summary).
• Intel automatic voltage mode: unchanged except it now benefits from the same state machine; knownGoodValues is rejected with a clear fatal error; the Intel example config sets repeatCoreUntilConfirmed = 0 (one shared voltage offset — a core confirmed early would keep a value a later core then adjusts).
• Existing ATM configs keep working; the behavior change (run until all cores resolved, resume continues the order) is the bug fix itself.
• The WHEA change makes treatWheaWarningAsError = 1 strictly more conservative (entries that previously slipped through as core-0 mismatches now count); set it to 0 to keep WHEA entries advisory.

Validation

• Syntax: [System.Management.Automation.Language.Parser]::ParseFile clean on both changed scripts.
• A 130+ assertion harness (extracted real functions run under pwsh with StrictMode 3.0) covers the state machine, persistence/atomic-write/recovery paths, order builders (n=1..24 incl. coresToIgnore), the banner/exit-code matrix, the resume flow incl. crash-attribution ordering, and the torn-save/resume-merge scenarios. Additional suites: WHEA attribution (16 assertions, incl. the live event id 47 case and a 5900X-style APIC gap), core scheduling with repeatCoreUntilConfirmed on/off (20 assertions simulating the real loop mechanics incl. errors and duplicate orders), and the resume-only branches of the results-file initialization (23 assertions).
• A parameter-set sweep over all ~2,600 command invocations in the script verifies no cmdlet call uses a parameter combination that fits no parameter set (the Split-Path failure class); it flags the two old call sites on the pre-fix file and nothing on the fixed one.
• Multiple independent adversarial review passes on the full diff (including an external reviewer), each followed by a fix + re-verification round.
• Live on a Ryzen 9 9950X3D: partial runs incl. knownGoodValues seeding confirmed working; the crash-resume cycle is what surfaced the Split-Path and WHEA findings above. A full end-to-end run is still outstanding.

Closes #106.

🤖 Generated with Claude Code

[kristofferkhansen]

I have ran this from start to finish twice now on my 9950@X3D, seems to work exactly as intended.