Status: all four PowerShell capabilities were merged into the Experimental UX-ROM product and passed their test gates. They improve diagnosis. They did not make the laptop faster by themselves.

A fast-looking answer can still be wrong

A laptop may pause because a driver is busy, Windows is handling interrupts, the processor is following a power rule, or security is checking work. Those causes can overlap. A list of installed software cannot tell them apart.

That matters because the tempting fixes are risky. Removing a driver, forcing an interrupt setting, disabling Intel Dynamic Tuning, or weakening Defender may hide a symptom while creating a worse problem. We built four bounded observers first, so later tests can change one thing and know which layer moved.

What changed, layer by layer

Layer 4: who owns each driver path?

UX-ROM now joins signed driver-package records, Plug and Play health, declared driver services, and exact service state. It replaces device identity with a one-use hash and never saves names, paths, serial numbers, hardware IDs, or command lines.

The ZBook returned 250 signed-driver records grouped into 126 package identities. No device reported a nonzero Device Manager error code. The complete observer took 8.205 seconds at the median, well under its 15-second bound. One service lookup was unavailable, and 17 records reported IsSigned as false. Those fields are questions for package-specific checks, not proof that a driver is bad.

Source PR #214 merged as e568172.

Layer 5: pressure inside the Windows execution path

The new kernel-pressure profile collects 12 documented Windows counters in repeated, correlated blocks. It covers processor use, DPC and interrupt work, context switches, runnable work, paging, memory, and disk delay. DPC means deferred procedure call: work a driver schedules after a hardware interrupt.

Three blocks retained 15 samples. Median interrupt time was 0.7765 percent, processor queue length was zero, page input was zero, and disk transfer latency was 0.801 milliseconds. The observer itself cost about 1.027 seconds per complete snapshot. WPR was available, but WPA and its exporter were not, so UX-ROM did not pretend these system-wide numbers identify a driver.

Source PR #217 merged as 9e9a724.

Layer 6: what power policy is really in effect?

Windows can show a Balanced base plan while the user asks for Best Performance and the runtime reports Max Performance. Those are separate contracts, not a contradiction. UX-ROM now reads all three, plus AC and battery values for five documented processor controls.

Five snapshots agreed: Balanced base plan, Best Performance on AC, Best Efficiency on battery, and Max Performance as the effective runtime mode. Maximum processor state was 100 percent on AC and battery. Intel Dynamic Tuning was running with automatic start. These facts do not show how quickly the processor responded or whether another power setting would improve a real task.

Source PR #220 merged as 6f88b02.

Layer 7: observe security without weakening it

The protection profile records selected effective Defender, firewall, and virtualization-based security state. It also watches a fixed list of Microsoft security processes with warmed Windows counters. It does not list exclusions, threats, firewall rules, files, identities, or commands.

Defender real-time and tamper protection were on. All three active firewall profiles were enabled, and virtualization-based security reported running. Across five idle-window samples, the observed security processes used 1.5601 percent machine CPU at the median and zero median read or write input/output. That activity was not tied to a customer action, so it is not evidence that protection slowed the laptop.

Source PR #223 merged as a5fdf19.

What we learned, and what we still do not know

Documented facts

  • Windows exposes supported package, device, counter, power, Defender, firewall, and Device Guard interfaces.
  • A power-plan name, driver date, or protection-state flag does not measure delay.
  • DPC and interrupt attribution needs a trace with module and function detail, not only aggregate counters.

Lab measurements

  • All four bounded profiles completed on the HP ZBook Firefly 14 inch G8.
  • No Plug and Play error, processor queue, or paging pressure appeared in the short passive windows.
  • The requested AC power mode and effective runtime mode both favored performance.
  • Security processes showed low but nonzero CPU activity during the idle sample.

Hypotheses

  • A declared slow workflow may overlap a repeatable driver, interrupt, power, or security signature.
  • A supported package comparison may matter only when both exact package states are valid for this model and Windows build.
  • A future application test can confirm whether the effective power mode stays stable under load.

Unknowns

  • Which driver owns any repeatable foreground delay?
  • Why did one driver-service lookup fail, and what do the 17 false signature fields mean?
  • Would a real workload produce security I/O or a measurable protection delay?
  • Can one reversible change beat the pre-registered decision rule without a side effect?

What was applied and how rollback works

Only UX-ROM code and tests changed. The four profiles did not update a driver, stop a service, change power policy, alter interrupt routing, add an exclusion, change a firewall rule, weaken virtualization-based security, request UAC approval, or reboot Windows.

Every observer has bounds, support checks, unique structured evidence, explicit unavailable states, and cleanup for resources it opens. Because Windows state did not change, rollback is source-code reversion. There is no system setting to restore and no reboot-persistence claim.

The tested boundary is the lab HP ZBook Firefly 14 inch G8 on Windows 11 Pro build 26200 with BIOS T76 01.24.02. Other systems must pass their own provider and counter checks.

What comes next

The cycle now moves to Layer 8: boot, services, scheduled tasks, background permissions, and startup applications. The next capability will define a usable state and measure readiness before changing startup behavior.

A startup item will stay in place unless its owner, dependencies, launch command, management state, customer purpose, and trace evidence support a narrower configuration. Any later change needs exact-state backup, dry run, verification, rollback, and repeated before-and-after timing.

Primary sources

Sources were retrieved July 31, 2026.

Complete engineering evidence

Back to all development updates