Windows: memory grows ~100 MB/s while dictating, to 5+ GB (regression of #1268?)

What happens

On Windows, Hex's memory grows fast while dictating. It reaches 3–6 GB within a minute of launch, then settles around 2–4 GB. It used to stay far lower. Dictation still works, but the HUD also fails more as memory grows (#1793).

This started on November 13 (EST). Memory was normal through November 12. Update history (EST), from the versions folder, Windows' Compatibility Assistant list of executables that ran, and Release run numbers (dev-N = run N−100):

dev-881 (ceb07a1a, built Nov 9)
dev-941 (7f54733e, built Nov 11): last good build, used until Nov 12, 11:35 PM
dev-1001 (4793e168): installed Nov 12, 11:35 PM. First bad build.
dev-1008: Nov 13, 10:58 AM
dev-1009: Nov 13, 11:08 AM
dev-1011 (73e08baa): Nov 13, ~12:39 PM

Regression window: 7f54733e..4793e168 (dev-941 → dev-1001).

The symptoms look like #1268 (8–12 GB on Windows), but the trigger is new (8–12 GB on Windows, closed after 9c2dec35 made the HUD keep one GPU device across dictations).

Environment

OS: Windows 11 Home 10.0.26300 (x64)
GPU: NVIDIA GeForce RTX 3070 Ti. The window and HUD draw on wgpu Dx12; the speech model runs on Vulkan.
Hex: dev channel, direct install. Seen on 0.0.0-dev-1009 and 0.0.0-dev-1011 (73e08baa).
Model: Parakeet Unified English (parakeet-unified-en-0.6b-Q8_0.gguf, 697 MB), streaming on the GPU
Labs on: Vocabulary biasing, Live chapters, Unload model when idle
Shortcut: Ctrl+Shift+Space, Hold

Measurements

Get-Process hex, sampled every 5 s. The process started at 12:40:46 local (17:40:46Z). I dictated almost without stopping:

time (local)  working set  private
12:41:11      3565 MB      4440 MB
12:41:16      3795 MB      4762 MB
12:41:21      4252 MB      5242 MB
12:41:26      4627 MB      5628 MB
12:41:31      4838 MB      5682 MB
12:41:41      4838 MB      5640 MB   (between dictations: flat)
12:41:56      5018 MB      5840 MB
12:42:06      5025 MB      5834 MB
~12:45        4090 MB      4900 MB   (idle; settles but stays high)

The previous process (dev-1011, started 12:39:46) was at 5130 MB working set / 5917 MB private after about 50 s and one 20 s dictation. Threads stay around 62–65 and handles around 890, so this isn't a thread or handle leak.

Memory grows by about 75–100 MB/s only while a dictation records, and stays flat between dictations.

Matching log events (`%LOCALAPPDATA%\hex\logs\process.log`)

17:40:49.758  INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti
17:40:50.785  INFO hex::transcription::engine: reloaded the speech model model=ParakeetUnifiedEnglish load_ms=1031
17:40:57.826  INFO hex::transcription::engine: finished live stream audio_ms=7880 feeds=46
17:41:00.401 ERROR hex::rune_hud: dictation HUD can't show reason=shown but presented no frame in 1500 ms; surface: Dx12 on NVIDIA GeForce RTX 3070 Ti (DiscreteGpu), PreMultiplied, Bgra8Unorm
17:41:11.000  INFO hex::transcription::engine: finished live stream audio_ms=12236 feeds=72
17:41:15.082  INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti      <- 3.57 → 4.25 GB over the next 6 s
17:41:29.902  INFO hex::transcription::engine: finished live stream audio_ms=14990 feeds=86
17:41:51.016  INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti
17:42:03.496  INFO hex::transcription::engine: finished live stream audio_ms=6490 feeds=38
17:43:27.589  INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti

The HUD builds a new painter (and with it a GPU device) about 4 s after each dictation ends. That fits PAINTER_IDLE releasing it (#1542). Each rebuild comes right before a memory jump and the HUD's "no frame" error (#1793).

Suspects (not confirmed)

dev-941 was fine, and it already contains the HUD painter release (e2434e09, #1542), the transcribe.cpp bump (36e0a1ee, #1580), and the Unified English padding (a5d3cf87, #1633). Those are unlikely causes. dev-1001 → dev-1011 changes only Whisper trimming and a speech-detector refactor, with no dependency changes.

Main suspect: the Rune bump 069ea6fc (#1661), in dev-941 → dev-1001. It moves Rune from a7cea169 to d6715352 (260 commits) and newly patches wgpu-hal, winit, and accesskit_windows with Rune's forks. The Rune commits in that range that touch Windows overlays, surfaces, presents, and GPU memory:

1a219d16 Overlay: one turn decision, and a surface that is made, parked, hidden or live (r15)
34c920b4 overlay draw scheduling backoff (r89); eec851cb uncovering keeps a missed frame's retry (r252)
d9b45a57 Frame: present times, the spin guard and the present worker as explicit state machines (r41)
223a965f (Windows: hovering the Hex window causes whole-screen VRR/G-SYNC brightness flicker on OLED #689) / 9b2cb52b (Distinguish left and right modifiers in chord shortcuts (e.g. Right Command + Right Option) #710) Windows: first frame drawn on the CPU, then the GPU takes over
bf8a5982 (macOS: Hex says "You're all set" while the speech model is still downloading #676) Windows: D3D12 alone; 9ce8c2b0 (Release prep: Hex 3.1.0 version and notes #674) smaller D3D12 descriptor heap
98c75014 (Use speech models already on this computer (#594) #819) a window at rest gives back GPU memory
fb73041d / b12800ee parked layer targets (r281)

Other runtime changes in 941 → 1001, which are less likely: 689e5b35 (Labs: keep the microphone open after dictating), 81174501 (cut long clips at the quietest point), ff3751dd (Paste Last on a failed paste), a3e786db (correction order and stop-time context).

The HUD rebuilding its painter and device after each dictation (HUD draws, above) now goes through the new Rune overlay and surface code. That would explain both this growth and the HUD presenting no frame (#1793).

A quick check: run dev-941 and dev-1001 side by side with the same dictations.

Expected

Memory stays close to the model plus the window and one HUD device (about 1–1.5 GB), and doesn't grow with dictation time or the number of dictations.

Update: Hex now also hangs ("Hex is not responding"; Windows Error Reporting AppHangB1, hang type 134217728). It has happened twice, both times about 11–12 s after a dictation finished, with the Settings window open:

Hang	Build	Last log line (dictation completed)	WER hang report	Gap
Nov 13	dev-1011	17:40:24Z	17:40:36Z	12 s
Nov 14	dev-1027	17:01:35Z	17:01:46Z	11 s

Nov 13: the process was at about 5 GB working set when it hung. Windows closed it and Hex relaunched 10 s later.
Nov 14: this was a fresh process. It launched at 17:00:17Z, opened the window, and its first dictation ran 17:01:23–17:01:35Z. Then nothing was logged until the hang. There was no presented no frame error this time, and the process is gone, so there's no memory figure. A hang 85 s after launch suggests it isn't only a slow leak over a long uptime.

Log for the Nov 14 run (process.log):

17:00:17.820  INFO hex::rune_ui: window draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti
17:01:23.016  INFO hex::rune_hud: HUD draws gpu=wgpu Dx12 on NVIDIA GeForce RTX 3070 Ti
17:01:23.143  INFO hex::rune_hud: dictation HUD surface surface=Dx12 on NVIDIA GeForce RTX 3070 Ti (DiscreteGpu), PreMultiplied, Bgra8Unorm
17:01:24.848  INFO hex::transcription::engine: reloaded the speech model model=ParakeetUnifiedEnglish load_ms=1837
17:01:35.094  INFO hex::transcription::engine: finished live stream audio_ms=12260 ... feeds=70
17:01:35.101  INFO hex::windows::dictation: completed Windows dictation job audio_ms=12260 latency_ms=248
(nothing more; WER AppHang at 17:01:46)

A UI-thread hang just after the HUD hides, while the window is open on the same Dx12 device, fits the suspected Rune overlay, surface, and present changes from the 069ea6fc bump (see the description, and #1793). WER kept only Report.wer (no dump).

Builds affected so far: dev-1001, 1009, 1011, 1018, 1027. Last good: dev-941.

Upstream: anomalyco/rune#887 (an overlay's memory grows with animation on NVIDIA). I added the likely cause and a probe there: anomalyco/rune#887 (comment)

In short: since Rune #844 (in Hex's 069ea6fc bump, dev-1001), Windows swap chains hold one frame and wgpu no longer waits on the frame-latency object (DontWait). Windows wait through window::slot, but overlays like the HUD never wait, so the HUD's frames pile up while it animates.

A Hex build (dev-1027's commit cdf38590) against Rune d6715352 plus a bounded 100 ms wait before the overlay acquires each frame:

33 s dictation: peak 416 MB working set / 1.35 GB private, settling at 312 MB / 1.06 GB
without the probe: 5.1 GB / 5.9 GB after one ~20 s dictation

The HUD drew normally, and the wait never reached the 20 ms logging threshold. This is one run; more back-to-back runs to follow. The fix belongs in Rune (overlays taking a window::slot); Hex would then bump its Rune pin.

fix(windows): pace the dictation HUD to one frame per display frame

fix(windows): pace the dictation HUD at about 60 Hz (#1828)

on windows the recording popup had nothing slowing it down, so while you dictated it redrew as fast as the cpu allowed. every one of those frames held some gpu memory until the gpu caught up, which is the climb you saw while recording. when the popup closed, hex then waited for that whole backlog to clear, which is likely the freeze with settings open.

now the popup draws about 60 times a second and stops asking for frames once it's gone, so memory should stay flat while you dictate and closing it shouldn't stall the window.

fixed in #1828, it'll be in the next dev build

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

memory was growing because the dictation hud on windows kept drawing frames without waiting for the gpu to catch up, so they piled up while it animated. the hang a few seconds after dictating was hex waiting for that pile to drain when the hud hid.

now the hud waits for room before each frame, the same way the main window does, so it can't pile up.

if memory still climbs on the next dev build, say so here and we'll reopen.

fixed in #1832, it'll be in the next dev build

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Navigation Menu

Repository navigation

Windows: memory grows ~100 MB/s while dictating, to 5+ GB (regression of #1268?) #1796

What happens

Environment

Measurements

Matching log events (`%LOCALAPPDATA%\hex\logs\process.log`)

Suspects (not confirmed)

Expected

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows: memory grows ~100 MB/s while dictating, to 5+ GB (regression of #1268?) #1796

Description

What happens

Environment

Measurements

Matching log events (%LOCALAPPDATA%\hex\logs\process.log)

Suspects (not confirmed)

Expected

Activity

maharshi365 commented on Nov 14, 2026

maharshi365 commented on Nov 14, 2026

thdxr commented on Nov 14, 2026

thdxr commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Matching log events (`%LOCALAPPDATA%\hex\logs\process.log`)