Bottom Line: 760 MB Was a Real Reading, but It Was Not a Normal Universal Baseline
The useful evidence is the contrast. One Windows 11 24H2 system showed the Zima client around 760 MB, while another installation showed roughly 191 MB. That means “Zima Client always uses 765 MB” is not supported. Treat the high reading as a per-version/per-workload memory investigation.
Record the Client Version Before Comparing Memory
The IceWhale reply immediately asked for ZimaClient and ZimaOS versions because memory behavior can change across releases. Current ZimaClient is actively updated, so a 2025 Task Manager screenshot should not be used as a 2026 baseline. The ZimaClient installation is the current client entry point.
Measure Private Working Set Over Time, Not One Screenshot
Task Manager's Memory column is useful but can include different process behavior across Electron/WebView helpers. Watch the process for several minutes after startup, during file browsing, backup, remote access and idle periods. Microsoft's Process Explorer gives more detailed process-level visibility.
Check Whether Memory Keeps Growing
A stable 300–700 MB footprint and a process that grows from 200 MB to multiple GB without returning memory are different problems. Record memory every few minutes and note which action triggers growth. A leak report needs a trend, not only a large number.
Separate Backup Activity From Idle Client Usage
ZimaClient can handle device discovery, remote access, quick actions and backup. A backup scan or active transfer may legitimately use more memory/CPU than an idle tray process. Pause backup, wait for the client to settle and compare again.
The ZimaClient device access provides the current feature context.
Test a Clean Restart Before Reinstalling
Exit ZimaClient completely, confirm its helper processes disappear, relaunch it and measure again. If the high usage only appears after days of uptime, note that duration. If a fresh launch immediately returns to the same unusually high number, collect logs/version information for support.
Do Not Compare Two Sync Clients by RAM Alone
Synology Drive and ZimaClient do not implement identical architectures or feature sets. RAM matters, especially on 8–16 GB Windows PCs, but the useful comparison is resource use during the same task: idle, syncing a folder, remote access, backup scan and active transfer.
Windows Efficiency Mode Is a Workaround, Not a Fix
Windows may allow an application to run in Efficiency mode, but that primarily changes scheduling/power behavior. It does not explain why memory is high or repair a leak. Use it only if responsiveness/power matters while you collect evidence.
What to Include in a Useful High-Memory Report
Include Windows build, ZimaClient version, ZimaOS version, memory after fresh launch, memory after 30–60 minutes, which ZimaClient features are active and whether the footprint drops when backup/remote features are idle. The ZimaOS backup helps define one of those test states.
For deeper Windows evidence, Windows Performance Recorder can capture a time-based trace when memory grows only after prolonged syncing or backup activity. That is more useful to developers than comparing two isolated Task Manager screenshots.
FAQ
Is 760 MB normal for ZimaClient?
The source thread shows it can occur, but another system used about 191 MB, so it is not a universal baseline.
How should I measure a memory leak?
Track memory over time and identify whether it continually grows during repeated actions or long idle periods.
Does Windows 11 24H2 cause the problem?
The report occurred on 24H2, but one case is not enough to establish Windows 24H2 as the cause.
Should I reinstall ZimaClient?
First restart it cleanly and test the current version. Reinstall only after version and process behavior are documented.
What data should I send support?
Client/OS versions, Windows build, screenshots, memory trend, active features and steps that reproduce the growth.
