SnipBoard Support Report - Batch 1

# SnipBoard Support Report - Batch 1

**Product:** SnipBoard 0.81.0.0 (`0.81.0+496e53e83c16951ead6fd5d20ab070582915cd16`)
**System:** Windows 11 Home build 26300, 40 GB RAM (39.8 GB visible), system-managed page file on C:
**Date:** October 18, 2026

*These reports are compiled by my AI staff in Clairvoyance. I review them before sending and can provide
more detail on any item. - Craig Gunhouse*

**Summary**

- **SB1-1 (bug):** after about 41 hours of running, SnipBoard held **27.2 GB of private memory and about
13.6 million handles**, which used up the PC's memory and slowed the whole system. A normal close didn't
work, and after a forced close the process didn't finish exiting until Windows was restarted. Windows'
own leak detection had flagged SnipBoard earlier that day. We don't yet know what triggers it.
- **SB1-2 (minor):** the Win+Shift+T hotkey fails to register at every start.

---

## SB1-1: memory and handle leak (27.2 GB, about 13.6 million handles)

**When:** noticed October 18, 2026, about 12:55 CDT. SnipBoard had been running since October 16, 19:37
(41.4 hours). The PC didn't sleep in that period (no sleep or wake events in the Windows System log).

**What we saw** (Windows process counters, read with PowerShell `Get-Process`, at 13:01 CDT):

| Measure | SnipBoard (PID 27928) | Fresh start, for comparison |
|---|---:|---:|
| Private memory | **27.2 GB** | about 0.14 GB |
| Handles | **13,607,424** | about 1,300 |
| Working set (peak) | 0.5 GB (24.6 GB) | about 0.2 GB |
| Threads | 53 | about 50 |
| CPU time | 8,409 s over 41 h | |

**Effect on the PC:**
- Free RAM was 0.01 GB, and committed memory was 88.1 of 89.3 GB (98.7%).
- The disk was saturated by paging: % disk time 643, average queue length 45.
- Windows grew the page file from about 10 GB to 50.5 GB, so free space on C: dropped from 67 GB to 21.4 GB.
- CPU use was low (20% in total; SnipBoard was the top process at 7.6%), so the slowdown came from memory.

**Windows' leak detection:** at 10:34 CDT, about 2.5 hours before we noticed, Windows Error Reporting
logged a resource-exhaustion leak report for SnipBoard: event 1001, `RADAR_PRE_LEAK_64`, `Snipboard.exe`
0.81.0.0, Report Id `b7be488e-6855-413d-bd85-5af1e3835dcb`, fault bucket `1594686025144445042`. No report
file was kept locally.

**SnipBoard's own log** (`%LOCALAPPDATA%\Stardock\Snipboard\SasLog.txt`) shows only the normal start-up
lines and `[SuspendWatchDogTask] Executing.` every 8 hours, with nothing unusual during the period.

**Closing it:**
1. At 13:04, a normal close didn't respond within 15 seconds, so the process was ended.
2. It then stayed in an exiting state, with 1 thread and 27.2 GB still committed, for at least 8 minutes,
until we restarted Windows at 13:13. We assume releasing 13.6 million handles was slow, but haven't
confirmed that.

**Since the restart:** SnipBoard ran from 13:18 to 14:41, sampled every 15 minutes. Private memory went from
136 MB to 217 MB and handles from about 1,300 to 1,483, with no sign of the leak. At the earlier average
rate (about 330,000 handles an hour) it would have reached several hundred thousand, so the leak doesn't
seem to run all the time. Something may trigger it. (We closed and restarted SnipBoard at 14:41 and 14:51 to
collect the attached logs.)

**What we don't know:** what triggers it, and what kind of handle leaks. We can't link it to a specific
SnipBoard action yet.

**Questions:**
1. Is this a known issue in 0.81?
2. What would help you diagnose it? For example, a handle breakdown by type when the count starts climbing
(we can run Sysinternals `handle.exe -s`), a dump, or particular settings.

**Attached:** `Batch-1.zip`, SnipBoard's log folder `%LOCALAPPDATA%\ClipboardBridge\logs` (10 files: daily
`clipboardbridge-*.log` from October 11 to 18, `sas.log` and the current session file), collected with
SnipBoard closed on October 18 at 14:51 CDT. We left out the clipboard history and identity files because
they hold private data; we can provide more if you need it.

**Our workaround:** restart SnipBoard. We now sample its memory and handle count every 15 minutes, and get
a warning above 8 GB or 1 million handles.

---

## Small observations

### SB1-2 (minor): Win+Shift+T hotkey unavailable at every start

At each start on October 18 (13:04, 13:18 after a Windows restart, and 14:41) SnipBoard's sync log
(`%LOCALAPPDATA%\ClipboardBridge\logs\clipboardbridge-2026-10-18.log`) records
`Hotkey Win+Shift+T is unavailable`, then `RegisterHotKey failed — the combination is likely in use by
another application` (Win32 error 1409) and `Failed to create message window 'ClipboardBridge.Hotkey'`.
Win+V registers normally. We haven't found which program holds Win+Shift+T (TechSmith Snagit is running
here, but that's unconfirmed). It doesn't appear related to SB1-1; we mention it because the failure also
reports a message window that couldn't be created.