Image editor retains ~5 full-size bitmap copies per capture (21.0.0): 760 MB leaked per screenshot on a large desktop

Summary

With After capture task → Annotate image enabled, every capture leaves roughly five full-size copies of the captured bitmap committed in native memory, and closing the editor window releases only one of them. On a large multi-monitor desktop this is ~760 MB retained per screenshot, so ShareX reaches multi-gigabyte private memory after only a handful of captures.

I measured this directly rather than reading process counters, so this report includes a per-capture number and a breakdown of which allocations are retained.

Affected version

ShareX 21.0.0 (latest release, self-contained .NET 9.0.17), Windows 11 build 26200 x64.

Steps to reproduce

1. Set After capture tasks to Annotate image, Copy image to clipboard, Save image to file (no upload task).
2. Record Private Bytes for ShareX.exe.
3. Take one fullscreen capture (ShareX.exe -PrintScreen). The image editor opens.
4. Close the editor window (title bar X / WM_CLOSE, i.e. discard rather than Continue).
5. Wait ~30 s and re-read Private Bytes.

Expected

After the editor window is closed and its image discarded, private memory returns to approximately the pre-capture level.

Actual

Stage	Private bytes	Working set
Baseline	2,315 MB	365 MB
Peak during capture	3,457 MB	1,701 MB
Settled, editor open	3,202 MB	1,446 MB
Editor closed	3,075 MB	1,322 MB
+20 s later	3,075 MB	1,322 MB

Net retained by one capture + close: +760 MB. It does not come back; only a restart clears it.

The captured area was 7703x4329 (the bounding box of a dual-monitor desktop). At 32 bpp that is 7703 x 4329 x 4 = 127 MB per copy. Counting committed allocations of exactly that size, before and after the single capture:

	Before	After
~127 MB full-desktop bitmap allocations	3	8
Native private committed	1,844 MB	2,501 MB
Managed (.NET GC) heap committed	425 MB	524 MB
Total private committed	2,269 MB	3,025 MB

So a single capture created five additional full-frame bitmap copies, and closing the editor freed one (127 MB). The retained memory is native, not managed — the .NET GC heap accounts for only ~0.5 GB of a 3 GB process, so this is not GC retention and is not fixable by GC tuning.

Frequency

Deterministic — every capture, 100% reproducible.

A secondary consequence worth noting: because each editor window holds its image for as long as it stays open, editor windows left open accumulate too. On the machine I measured, 13 editor windows had accumulated over 45 h of normal use; combined with the per-capture retention the process sat at 2.3 GB private.

Note that private bytes here is largely cold — working set stays far lower (365 MB against 2.3 GB private) because the leaked copies are committed and never touched again. That is why this shows up as pagefile/commit-charge pressure rather than obvious RAM usage, and it is probably why several existing reports read as "high RAM but it looks idle".

Related existing issues

These describe the same underlying symptom from process-level counters only, and none has maintainer engagement:

• #8670 — 21.0.0, 2.5 GB private vs 80–140 MB working set after 46 h
• #8484 — "Increasing Memory Usage With Each Screenshot Taken"
• #8097 — closed as stale; reporter measured "~8–12 MB per screenshot" on a smaller display

I filed separately rather than commenting because those threads have been quiet for months and none of them isolates the editor path or distinguishes native from managed memory.

Possibly already addressed on develop

Two commits on develop after the 21.0.0 tag look directly relevant, though I have not built develop to confirm they fix this:

• 1889493 (2026-09-09) — Manage editor view lifecycle and dispose replaced image resources
• 8e466b7 (2026-09-11) — fixed #8842: Dispose editor resources after closing the window

If those do fix it, this is mainly a question of getting a release out, since 21.0.0 has been the current stable build since July.

In-depth investigation — method and caveats

Method. Committed memory was enumerated with VirtualQueryEx across the whole address space, grouped by AllocationBase, and split into managed vs native. The managed heap is identified as the allocation carrying the ~255 GB reservation that the .NET 7+ regions GC makes up front; everything else private and committed is treated as native.

Why this is native, not GC retention. Of 3,025 MB private committed, the GC heap region accounts for 524 MB. The remaining ~2.5 GB sits in ~275 separate native allocations of 1–127 MB, dominated by exact multiples of the capture dimensions. Settings such as System.GC.ConserveMemory or RetainVM would therefore not help.

The 127 MB signature. 7703 x 4329 x 4 B = 133,386,828 B. The allocation histogram showed exactly three such allocations before the test and exactly eight after a single capture, which is what pins the leak to per-capture image copies rather than a general allocator or fragmentation effect.

Caveats, stated plainly:

• Measured on a single machine and a single configuration. Annotate image was enabled throughout; I did not run a control capture with annotation disabled, so I cannot say whether the retention is entirely in the editor path or partly in the capture path. That isolation would be the obvious next step for anyone reproducing this.
• The editor was closed via WM_CLOSE (equivalent to the window X), not via Continue. The Continue path may dispose differently.
• Only one capture was performed, deliberately — at 760 MB each, a longer run risked exhausting commit on the test machine. The per-capture figure is therefore a single sample, not an average, though it is consistent with the 45 h accumulated total on the same process.
• Absolute numbers scale with capture dimensions. A single-1080p user should expect roughly 1920 x 1080 x 4 = 8.3 MB per copy, which matches the "~8–12 MB per screenshot" reported in #8097 and suggests the same defect has been present for some time and simply becomes severe on large desktops.