DVLS grinds to a halt when a user opens DPM

Hello,

Thanks for the detailed report.

We have seen a few different patterns that produce the symptom you describe, and the fastest way to narrow it down is to correlate the DVLS server side with what the DPM client is doing at the moment of the spike.
Could you share the following, please?

1) The exact DPM desktop version and the DVLS server version.
The DVLS version is visible in the Devolutions Server web interface top-right user menu, and on the main dashboard of the Devolutions Server Console.
The DPM version is shown at the bottom of the main window and in Settings, About.

2) A DVLS server support package taken shortly after one of these freezes.
Full procedure here: https://docs.devolutions.net/resources/customer-support/generate-a-support-package-in-devolutions-server-console/
In short, open the Devolutions Server Console, go to the Support section, choose Generate support package, review the included logs, click Generate, and save the produced .zip file.

3) The DPM client log covering the same window as the freeze.
If your DPM build does not offer an in-app export, please open a support case with us, and we will point you to the current log path for your specific DPM version so we can get the right file.

4) The number of vaults the affected user can access, and the entry count per vault.
The Vault dashboard in the DVLS web interface shows the entry count for each vault, so a quick per-vault list is enough. Please also indicate whether any of those vaults are PAM vaults.

5) Whether entries or folders use custom image icons.
Custom icons are stored as image data on each entry or folder, and a vault that carries many of them can meaningfully increase the payload DPM has to fetch on connect, which by itself can produce a short server-side spike.

If custom icons are in use, an approximate count of entries or folders that carry one would be helpful.
While you gather those, three things you can check in parallel that often shorten the investigation.

First, enable HTTP logs on DVLS (https://docs.devolutions.net/server/knowledge-base/how-to-articles/enable-devolutions-server-http-logs/) and check whether you see a burst of requests to /api/vaults/null/entries returning HTTP 400 during the freeze window.

That specific pattern points to a known DPM 2026.2.0 startup path (for internal reference only) that has already been addressed in a newer DPM build, and moving to the latest DPM desktop resolves it.
Second, check the DPM client log for a "Bad state: RefHolder not initialized" entry near startup. If that line is present, it confirms the same pattern.

Third, if you have any vault with more than roughly 4,000 entries, please note it. DVLS starts to show noticeable pressure around that threshold, and a full refresh from Workspace or DPM against a very large vault can look exactly like a short server hang from the RDM side.

For reference, DVLS log locations and how to raise their verbosity are documented here: https://docs.devolutions.net/server/knowledge-base/how-to-articles/enable-the-devolutions-server-log-files/ and https://docs.devolutions.net/server/web-interface/administration/configuration/server-settings/general/logging/
Once we have the versions, the support package, the DPM client log, and the vault or icon breakdown, we can confirm whether this maps to the DPM startup burst, a custom-icon payload cost, a large-vault refresh, or something specific to your instance.

All files could be sent to service@devolutions.net

Best regards,

🎁 AI Maturity Survey — 2 minutes of your time Enter to win a $1,000 CAD Amazon gift card or a Mindstone training course. 👉 https://survey.alchemer-ca.com/s3/50606209/d87f0b7d503e