I have a windows client version 2.4.8 at idle time it uses one core per 100%
Could you create a memory dump of the process while this occurrs? (howto: https://support.microsoft.com/en-us/help/931673/how-to-create-a-user-mode-process-dump-file-in-windows )
it always consumes 100% of a single core
link to memory dump.
Thanks! Could you send the client log file as well?
debug.7z (47.9 KB)
Sorry, no hints yet w.r.t. the cause
Could you capture a bit of what UrBackupClientBackend.exe does with https://docs.microsoft.com/de-de/sysinternals/downloads/procmon and send that as well?
I am experiencing the exact same issue. Windows Client version 2.4.8, Windows 7 64-bit PC.
Logfile.7z (559.4 KB)
Windows 10 x64 1903 18362.418
No hints either. Could be it is caused by ipv6. If you add
C:\Program files\UrBackup\args.txt and it doesn’t occur that would confirm this.
Well I’ll try. If I restart the service it stops using the CPU at 100% for a while.
After IPv6 is disabled, everything is fine.
Same issue here.
I have UrBackup client running for 1 or 2 years and the CPU issue didn’t occur so far.
Problem started just yesterday, UrBackup client was stuck as using a full CPU thread all day long. I wasn’t sure if it was actually working on idle.
Disabling IPv6 resolved the issue.
(and restarting the client backend service)
Could someone create a few memory dumps while the thread is at 100%? (see https://docs.microsoft.com/en-gb/archive/blogs/debugger/what-is-a-dump-and-how-do-i-create-one#to-create-a-dump-using-task-manager how)
Hopefully that shows where it loops…
I will send you the memory dump via email.
I cannot send you any email:
Disabling ipv6 via args.txt did not fully resolve the problem. No backup could be done.
Disabling ipv6 on the network adapter (and restoring args.txt) helped. Backups are working normally again.
Here is one dump.
Edit: Removed. Thanks. got it.
Try firstname.lastname@example.org . Thanks!
Can’t see a problem yet
What would also be helpful would be a procmon log of the UrBackupClientBackend.exe process. Please restart the service while procmon is logging, so it logs the startup: