Hey,

i my agents could trace this problem down to Handy and hope this information helps you find the issue, if there is one:

Windows: fan ramps up while locked with Handy running; WebView GPU process toggles timer resolution ~134 times/second

Summary

My laptop's fan ramps up to what sounds like maximum speed after I lock Windows with Handy running. Closing only Handy prevents the issue; with Handy open, I can reproduce it.

An ETW trace shows Handy's WebView2 GPU process requesting and releasing a 1 ms timer resolution about 134 times per second, during almost exactly the screen-off interval. This is a possible mechanism to investigate, not proof that the timer changes cause the fan noise.

Environment

Versions below are from the September 11, 2026 capture:

• Handy 0.9.3.
• WebView2 150.0.4078.65, from Handy's process command line.
• Windows 11; full OS update revision not captured.
• HP ZBook Studio 16 G9, 20 logical processors.
• Intel Iris Xe, driver 32.0.101.7077; NVIDIA RTX A1000 Laptop GPU, driver 32.0.15.7371.
• AC power, Balanced power plan, plugged-in sleep set to Never. I lock the screen with Win+L, rather than selecting Sleep.

Steps and comparison test

1. Run Handy during normal laptop use.
2. Stay plugged in and lock Windows with Win+L.
3. Wait several minutes. The fan ramps up.
4. Close only Handy, leave other applications running, and repeat the lock test. The issue does not occur.

I once failed to reproduce immediately after restarting Handy, but subsequent Handy-open versus Handy-closed tests reproduced the difference. I do not know whether prior dictation, microphone use, or elapsed runtime affects the trigger.

Expected: Handy should remain quiet in the background when I am not using it, including while Windows is locked.

Trace evidence

All times are September 11, 2026, UTC+02:00:

• Handy GPU-process timer cycling: 14:31:27-14:37:49.
• Windows screen-off interval: 14:31:31-14:37:50.
• Fan ramp-up: approximately 14:37.
• Unlock: 14:37:50.

The process was msedgewebview2.exe, PID 24524. These command-line fields identify it as Handy's GPU process:

--type=gpu-process
--webview-exe-name=handy.exe
--webview-exe-version=0.9.3
--user-data-dir="%LOCALAPPDATA%\com.pais.handy\EBWebView"

Provider: Microsoft-Windows-Kernel-Power

Event: SystemTimeResolutionChange

For PID 24524:

• 25,598 events with RequestedResolution = 10000 (1 ms in 100 ns units).
• 25,598 events with RequestedResolution = 0.
• 51,196 changes total, about 134 per second during the sequence.
• A decoded nonzero-request example has RequestIgnored = False.
• The cycling ended one second before unlock.

Handy's WebView renderer, PID 2088, also generated approximately 1,100 timer-resolution changes per minute in several intervals.

Whole-machine sampled CPU usage shortly before unlock was around 9-14%, spread across several processes. These measurements do not establish Handy's power consumption, and timer-event counts are not GPU-utilisation measurements.

Capture limitations and available diagnostics

I recorded with:

wpr -start GeneralProfile -start GPU -filemode

The trace covers 14:29:37-14:38:51, with zero reported lost events. It is about 19.9 GB. WPR itself accounted for 98% of disk writes, around 30 MiB/s through much of the locked interval, so recording overhead may have amplified the captured fan noise. The issue also occurred without WPR running.

I did not measure fan RPM, temperatures, or package power. I cannot yet distinguish a Handy issue from a WebView2 or driver interaction.

I retained the ETL and decoded event summaries. The raw trace contains personal paths and unrelated corporate information, so I have not attached it publicly. I can review and redact a focused export of the events maintainers need.