The tool needed better eyes
Windows performance work becomes nonsense when the tool cannot tell what changed around a test. A slow Explorer window might come from the shell, a busy process, a cloud path, a power or thermal limit, storage delay, or firmware work before Windows even starts.
We could have applied a pile of popular tweaks and hoped for the best. Instead, we spent six layers teaching UX-ROM to separate those paths. Each profiler has bounded run time, support checks, structured evidence, and a clear statement of what it cannot prove.
This is a one-time catch-up report for work that landed after the last EXP-001 layer article. Future reports will cover four completed layers at a time. A measured improvement will still get its own post as soon as it passes validation.
What changed, layer by layer
Layer 10: File Explorer readiness
UX-ROM can now open its own private benchmark folder through Windows' documented Shell automation interface. It waits until the matching Explorer window says it is ready, then closes only that window.
Five measured runs completed. The median was 594.678 milliseconds, with a range from 323.116 to 1,068.767 milliseconds. The slow run stays in the evidence. Animations and transparency effects were already off, so we did not pretend that changing them produced a gain.
Source PR #130 merged as 4ead80f.
Layer 11: Application work without a heavy observer
The first process profiler used Windows Management Instrumentation. Its own query cost was too high: about 179 milliseconds at the median. We rejected that design.
The replacement uses the .NET process interface and Microsoft's documented process I/O counters. Its snapshot median fell to 19.303 milliseconds. A five-second Explorer observation completed 10 stable intervals. This improved the measurement tool, not Explorer.
Source PR #148 merged as b1ee2bc.
Layer 12: Storage and network conditions
A benchmark can look slower because its files moved to a cloud or network path, or because a required endpoint was not ready. UX-ROM now records those conditions without reading file content or storing raw paths and host names.
The lab path was ready on fixed NTFS storage. Five of five bounded endpoint probes connected. The median probe was 9.695 milliseconds. An older administrator-owned event log rejected the update, but the primary JSON evidence was already safe. We changed the tool so that this optional journal failure no longer erases a completed profile.
Source PR #154 merged as 1d323c9.
Layer 1: Processor limits before thermal guesses
The earlier thermal path could not identify a trustworthy CPU-package temperature. The new profiler uses documented Windows processor-performance limit signals instead. It does not call an unknown ACPI thermal zone a CPU temperature.
Six of six passive samples completed. Windows reported a 100 percent performance limit with no nonzero limit flags during that short window. The sample-query median was 298.9625 milliseconds. That means no processor limit was observed, not that the cooling system has passed a stress test.
Source PR #159 merged as 9ccb765.
Layer 2: The real storage path
UX-ROM can now identify the installed storage type and passively sample per-disk latency, queue, throughput, input/output operations, and activity. It does not open a user file or run a synthetic disk load.
The lab machine reported one healthy 256 GB SK hynix SATA SSD. Six of six samples completed. The measured query median was 293.7735 milliseconds. The idle window showed zero median latency and queue, but an idle five-second sample cannot prove that storage is fast enough for a real workload.
Source PR #209 merged as ac75779.
Layer 3: A safe firmware boundary
The latest profiler identifies BIOS or UEFI boot, records a redacted BIOS and SMBIOS identity, attempts the documented Secure Boot status query, and checks which HP BIOS management classes exist.
The ZBook reported UEFI, BIOS T76 01.24.02, SMBIOS 3.3, and 12 HP BIOS class names. The core query median was 20.319 milliseconds. Secure Boot status was unavailable without administrator rights, and UX-ROM did not ask for elevation. It read no BIOS setting instances and called no firmware write interface.
Source PR #210 merged as 8b2c53a.
What we know and what remains open
Documented facts
- Windows exposes supported Shell automation, process counters, storage providers, processor-limit counters, BIOS inventory, and firmware-type APIs.
- Those interfaces can describe one part of a performance path without granting permission to change it.
- Observer cost matters. A diagnostic tool can disturb the short interval it is trying to measure.
Lab measurements
- All six profilers completed their bounded final validation runs.
- Explorer readiness had meaningful run-to-run spread.
- The replacement process observer was much lighter than the rejected WMI design.
- No processor performance limit or active storage queue was seen in the short passive windows.
Hypotheses
- A controlled Explorer or application test may expose a repeatable foreground delay.
- Matching dependency and thermal signatures should reduce false before-and-after wins.
- A traced driver or OEM component may explain a delay that static inventory cannot.
Unresolved questions
- Which driver or OEM component adds measurable latency to a real workflow?
- How much of Explorer's spread remains after power, storage, and dependency conditions match?
- Can a single reversible change beat the pre-registered decision rule across repeated runs?
- How should pre-OS firmware duration be measured separately from Windows startup?
What was applied and how rollback works
These six capabilities are observation-only. They changed the UX-ROM PowerShell product and its tests, but they did not change Windows, a service, a scheduled task, the registry, a driver, Secure Boot, BIOS settings, or firmware.
Runtime cleanup closes only the private Explorer benchmark window. Primary evidence uses unique files so a later run cannot overwrite an earlier one. Because no Windows state changed, rollback means removing the profiler code; there is no system configuration to restore and no reboot-persistence claim.
The supported lab boundary remains the HP ZBook Firefly 14 inch G8 on Windows 11 Pro build 26200 with BIOS T76 01.24.02. Inventory fields and providers are detected before collection, so an unsupported machine should fail safely instead of receiving a guessed setting.
What comes next
The cycle now moves to Layer 4: platform drivers and HP or other OEM components. The next useful step is a bounded ownership and compatibility profile that connects device, driver package, provider, version, and measured timing evidence.
We will not update or remove a driver because its date looks old. A later change must identify the exact supported package, preserve the package and recovery path, measure one customer workflow repeatedly, verify the result after reboot when required, and restore the original state if the experiment fails.
After Layer 4, the new publication schedule groups each four completed layers into one plain-English digest. If a change produces a real, repeated speedup before then, it gets its own report immediately.
Primary sources
Sources were retrieved between July 29 and July 31, 2026.