I have update client to version 2.5.27 about 2 weeks ago.
Now is the third time that the client get stuck. Trying to open the client shows the in english (translated from italian): Error. Backup currently cannot be performed.
To make client functional again, i need to reboot the PC. Killing and restarting the client using Task Manager do not solve the problem (tryed also to turn off my antivirus firewall). After restarting, the client works correctly for about 2 days, then crash again.
After crashing, trying to use the function ‘Access to backups’ from the tray icon menu, generates this error:
Error getting server URL. Unable to access files.
On the log i see:
2026-01-17 19:09:26: ERROR: Program abort (SIGABRT)
2026-01-17 19:09:26: ERROR: Fatal exception code 0 at address 0x00007FF9835DA80A
2026-01-17 19:09:27: ERROR: Fatal exception (APPLICATION CRASHED). Crash dump written to “C:\WINDOWS\TEMP\UrBackup\v2.0.0-20260117-190926-8152-9608.dmp”
no other log is present after the crash, occured at 19:09:27 local time, and the last seen on the server i the same time.
Will send the dump file via email.
My configuration is:
CLIENT:
- OS: windows 11 25H2
- Urbackup client version: 2.5.27
- File system: NTSF
SERVER
- Version: 2.5.35
- OS: docker container on Debian Linux
Note that i have another PC on the same network, equipped with Windows 11 25H2 but client version number 2.5.26. The error seems not to occur, and client runs without problems from many days.
I can confirm this Behaviour. I had to backup a bunch of Windows 2025 Servers and get the same error. Switching back to 2.5.26 fixes the problem. Running 2.5.27 on a Windows Server 2022 works like a charm, 2025 does not.
Windows 25H2 client 2.5.27 crashes on all updated clients from 2.5.26 on Incremental Image Backups, I guess because they take much longer than incremental file backups. My workaround for now is to modify the Urbackup Client Service recovery settings to restart the service on first, second and subsequent failures i.e. changed from default “take no action”. Looking through the client changelog, “Properly detect Windows 11 to switch over to using a thread to prevent sleep” is likely the cause of this crashing disaster as 2.5.26 had no such issue. I’d roll back to 2.5.26 until this is fixed but it seems that my usual Winget update -r is going to pull and install 2.5.27 again ….
Hmm weird, the installer must have somehow failed to update it then, the client says the right version, I’ll re-run the installer manually… once it finishes downloading at 20kB/s for some reason