Memory Leak

Windows Version Number: Windows 11 25H2 (build 26200),
App Version: 4.0.7.2,

Hello,

I am experiencing significant memory leaks with Multiplicity that are causing various system issues. I have monitored the system and put together a report detailing what I’m seeing for review.

I really need to get to the bottom of this. If we can’t identify and resolve the issue, I may need to move to a different solution, as the current behavior is becoming a major problem and is making Multiplicity difficult to use reliably.

Please review the attached report and let me know what we can do to troubleshoot this further.

Bug report: MPRDP64.exe leaks committed memory until the system commit limit is exhausted
Product: Stardock Multiplicity 4.0.7.2 (per SasLog.txt)
Component: `MPRDP64.exe` "Multiplicity remote control", file version 4.0.7.1
Severity: High. Brings the whole system to commit exhaustion, after which unrelated applications fail to allocate memory and crash.
Reproducibility: Every session observed (two separate boots, four process instances)
---
1. Summary
Each `MPRDP64.exe` instance (one per connected peer PC) keeps growing its private committed memory without releasing it. Almost none of that memory stays in the working set, so it is backed by the page file. On a 64 GB machine, two instances reached 68.4 GB of commit combined (46.6 GB and 21.7 GB) after 72.9 hours. That drove system commit to 98.8% of the commit limit (127.4 GB of 129.0 GB) while physical RAM was only 57% used.
Handle and thread counts stay flat. This looks like a heap/virtual-allocation leak, not a handle or thread leak.
2. Environment
Item Value
OS Windows 11 Enterprise 10.0.26200 (UBR 9457), x64
CPU AMD Ryzen 9 5950X, 16 cores / 32 threads
RAM 64 GB
Page file System-managed, single file on the system drive (~56–65 GB)
GPU NVIDIA GeForce RTX 3080 Ti, driver 32.0.16.1692
Displays on this PC 1
Network 10 GbE wired adapter
Multiplicity peers 2 peer PCs connected (one `MPRDP64.exe` per peer)
Installed Multiplicity binaries (64-bit)
File File version Date
MPRDP64.exe 4.0.7.1 2025-09-10
MultiSrv64.exe (service "Multiplicity", LocalSystem, Auto) 4.0.5.0 2025-09-10
Multipl2_64.exe 4.0.0.0 2025-09-10
MP64.exe 4.0.0.0 2025-09-10
MPRDISP64.exe 4.0.5.0 2025-06-19
MultiPLV64.exe 4.0.1.0 2025-09-10
Driver64.exe 1.0.0.1 2024-12-17
Process layout observed
`MultiSrv64.exe`: session 0, running as the service
`Multipl2\_64.exe`: session 1, started at logon
`MPRDP64.exe` × 2: session 1, running as the interactive user (not SYSTEM). The command line is `MPRDP64.exe <peer computer name>`, one instance per peer. The parent process had already exited when inspected.
`MP32.exe` and `MP2Drag.exe`: session 1, small (1–2 MB private), not growing
3. Evidence
3.1 Incident capture (3-day uptime)
Captured by a monitoring agent when system commit crossed 98%. The two instances were started 7 minutes after boot and ran for 72.9 hours.
Process Private (committed) Working set Virtual size Handles Threads Page faults
MPRDP64.exe, instance 1 46.64 GB 54 MB 53.5 GB 1,014 121 1,603,044
MPRDP64.exe, instance 2 21.74 GB 53 MB 28.4 GB 1,026 121 703,003
Largest non-Multiplicity process (a 3D game) 16.52 GB 5.36 GB — 1,869 81 —
All other 503 processes combined ~32 GB
System memory at capture
Metric Value
Commit charge 127.4 GB
Commit limit 129.0 GB (98.8%; peak 128.3 GB)
Physical RAM in use 36.8 GB of 63.9 GB (57.5%)
Available RAM 27.1 GB
Page file available 1.6 GB
Over those 72.9 hours, the average growth was 0.64 GB/h (instance 1) and 0.30 GB/h (instance 2). Without Multiplicity, system commit would have been about 59 GB (46% of the limit).
About 12 hours before the capture, while commit was already high, a separate .NET application on the system crashed inside `coreclr.dll`. This fits the pattern of allocations failing under commit pressure, but no causal link was established.
3.2 Reproduced after reboot
After a reboot, the two `MPRDP64.exe` instances were relaunched. They started at 12:37:19 and 12:41:09 local time. The first started 6 seconds after `MultiplicityConfig.exe` was opened (per SasLog.txt). In the earlier session, the instances likewise started within a minute of `MultiplicityConfig.exe` being opened.
Spot check about 1.8 hours after launch
Instance Private Working set Growth over 90 s Implied rate
Peer A 7.15 → 7.18 GB 588 MB +26 MB ~1.0 GB/h
Peer B 2.12 → 2.34 GB 394 MB +230 MB ~9.0 GB/h
5-minute time series (11 samples, 30 s apart), taken shortly after the spot check
Instance Private start → end Growth Rate Working set Handles Threads
Peer A 7.18 → 7.25 GB +70 MB ~0.8 GB/h 588–592 MB 1,019–1,022 121
Peer B 2.66 → 2.79 GB +140 MB ~1.6 GB/h 414–423 MB 1,017–1,024 121–122
Growth per 30-second interval (MB):
Peer A: `0, 0, 69, 0, 0, 0, 0, 0, 0, 0`. It grows in discrete ~69 MB steps, which suggests one large allocation (e.g. a frame or transfer buffer) made periodically and never freed.
Peer B: `41, 12, 46, 4, 7, 8, 9, 3, 4, 6`. It grows continuously in small increments, with occasional larger bursts.
Throughout, private commit only rises while working set, handle count and thread count stay essentially flat.
The rate is bursty: Peer B measured ~9 GB/h over one 90-second window and ~1.6 GB/h over the following 5 minutes. It likely depends on activity on the corresponding peer, such as screen/cursor/clipboard traffic, but this has not been isolated yet.
4. Expected vs actual
Expected: `MPRDP64.exe` memory stays roughly flat during a long-running peer connection.
Actual: private commit grows without bound, from tens of GB up to the system commit limit. Working set stays small, so the memory is either never touched or is paged out and never freed. Nothing is reclaimed until the process is closed.
5. Steps to reproduce
PC on Windows 11 25H2 (build 26200), Multiplicity 4.0.7.2, with 2 peer PCs connected.
Leave the connection running (open Multiplicity Config once so the `MPRDP64.exe` instances start).
In Task Manager → Details, add the "Commit size" column, or run:
```powershell
Get-CimInstance Win32\_Process -Filter "Name='MPRDP64.exe'" |
Select ProcessId, @{n='PrivateGB';e={$\_.PrivatePageCount/1GB}}, WorkingSetSize, HandleCount, ThreadCount
```
Watch the private/commit size of each `MPRDP64.exe` for several hours. It rises steadily while the working set stays small.
After 1–3 days, system commit approaches the limit ("Your computer is low on memory" / applications crash).
Workaround: closing Multiplicity (or ending `MPRDP64.exe`) releases the memory immediately. The leak starts again when the connection is re-established.
6. Additional diagnostics available on request
The reporter can capture any of the following if it helps:
A full process dump of `MPRDP64.exe` after it has grown (e.g. `procdump -ma`)
A Sysinternals VMMap snapshot showing whether the growth is heap, private data (VirtualAlloc) or mapped memory
A longer time series correlating growth with activity on each peer
Results with individual features toggled (clipboard sharing, file drag/drop, remote screen view, audio)