The evidence question
Can three short blocks of inbox Windows counters identify a supported kernel, scheduler, memory, storage, interrupt, or DPC/ISR change that improves startup or responsiveness on this exact ZBook?
No. The counters preserve system-wide activity, but they do not attribute DPC or ISR duration to a module, function, device, or call stack. They were not captured around a declared customer workflow or readiness endpoint.
That rules out using these numbers to select a driver, timer, HPET, scheduler, interrupt-affinity, memory, storage, page-file, boot, power, service, policy, or registry recipe.
Repeated raw screening blocks
The non-elevated collection recorded three consecutive blocks. Each block contained five one-second samples for eight counters.
| Counter | Block 1 | Block 2 | Block 3 | Median of block medians |
|---|---|---|---|---|
| Processor time (%) | 12.9596 | 7.0698 | 1.9478 | 7.0698 |
| DPC time (%) | 0 | 0 | 0.1926 | 0 |
| Interrupt time (%) | 0 | 0 | 0 | 0 |
| Interrupts/sec | 4135.1839 | 427.9419 | 418.2872 | 427.9419 |
| Processor queue length | 0 | 0 | 0 | 0 |
| Context switches/sec | 7336.9694 | 486.9684 | 468.7190 | 486.9684 |
| Memory page reads/sec | 0 | 0 | 0 | 0 |
| Current disk queue length | 0 | 0 | 0 | 0 |
The raw sample ranges included 0 to 0.1953 percent DPC time, 0 to 0.3883 percent interrupt time, 311.6000 to 4527.3966 interrupts per second, and 332.3045 to 8454.5740 context switches per second.
These numbers describe only the preserved 15-second interval. They are not thresholds, targets, proof of a problem, or proof of health. The variation between blocks is itself a warning against treating one short sample as a normal state.
Why the result is not a baseline
- Engineering automation was active.
- No formal idle settling or workflow reset occurred.
- No startup, sign-in, shell, network, device, application, or workload readiness endpoint ran.
- Layer 1 did not establish a thermal-readiness gate.
- Counter collection overhead was not qualified.
- No ETW trace, module/function attribution, symbols, or call stacks exist.
The observation applies to the recorded HP ZBook Firefly 14 inch G8 SKU, Windows 11 Pro build 26200, BIOS T76 01.24.02, AC-connected power observation, and Balanced power scheme. English counter paths were available on this installation; Microsoft notes that counter names are localized.
The supported attribution path
Microsoft documents that the Windows Performance Recorder General profile captures context switches, disk I/O, DPC, interrupts, hard faults, memory information, kernel queues, process and thread activity, ready threads, and sampled CPU profiles.
Windows Performance Analyzer then provides DPC/ISR views by CPU and by module and function. Microsoft's CPU Analysis guidance recommends zooming to the interval of interest, identifying high-duration module and function entries, and reviewing stacks. It also demonstrates that DPC/ISR activity can be unrelated to the performance problem being investigated.
wpr.exe is available on the lab computer. wpa.exe and xperf.exe were not detected. This unattended run did not install a toolkit, start an ETW trace, or elevate.
A later Layer 5 experiment needs a Windows-build-compatible Windows Performance Toolkit, tool and collector version records, lost-event checks, overhead qualification, sensitive-trace handling, a declared workflow interval, repeated raw traces, module/function attribution, and stack analysis.
Evidence ledger
Documented facts
Get-Counterreads Windows performance-counter instrumentation.- WPR General records DPC, interrupt, scheduling, memory, and disk events.
- WPA can group DPC/ISR duration by module and function and expose stacks.
- Driver DPC/ISR timing guidance uses kernel tracing, workload exercise, lost-event checks, and trace analysis.
Lab measurements
Three five-sample blocks were preserved with timestamps and medians. They are labeled pre-protocol screening and are not baseline-eligible.
Hypotheses
A driver may produce DPC/ISR work that overlaps a readiness delay. The early higher counter block may reflect active automation or transient background work. Neither explanation is tested.
Unresolved questions
- Which workflow and readiness interval should bound the trace?
- Which WPT build supports Windows build 26200?
- What collection overhead and lost-event rate occur?
- Which modules, functions, and stacks overlap a repeatable customer-visible delay?
Configuration and rollback status
No configuration was changed, so rollback is not applicable to this report. A later modification still requires support detection, original-state capture, dry run, apply, verification, structured logging, idempotence, exact rollback, rollback verification, and reboot-persistence testing.
Defender, firewall, Windows Update, BitLocker, Secure Boot, recovery, management, HP support and update functions, drivers, services, tasks, registry, page file, power, firmware, and boot configuration remain untouched.
Primary sources
All sources were retrieved July 27, 2026.
YouTube briefing
Presenter: This hour recorded three short blocks of Windows kernel and DPC/ISR screening counters.
The counters varied between blocks, but a system-wide number cannot name a driver or prove a customer-visible problem. This was not a startup run, thermal readiness is unresolved, and measurement overhead was not qualified.
Microsoft's supported attribution path uses WPR traces and WPA views by module, function, and stack. WPR is present, but WPA and xperf were not detected, so no trace was started.
No optimization was applied. Layer 5 remains inconclusive, and the next hour investigates supported power-management and performance-policy surfaces.
Source and next layer
The next hourly cycle position is layer 6: power management and performance policy.