BUG .. CBT client causes "Restart required" EVERY startup (unless all volumes selected)


#1

In addition, it ALSO shows CBT active for the ONE volume it’s NOT set to be active, and the ones set to use it are shown as “Without CBT”, and yes I’ve run an image over those (and not the one showing active) and rebooted multiple times!

Windows 10 Pro x64 all updates current.

I have:
Run the windows troubleshooter rebooted as it said - no change
Uninstalled the client - rebooted - blessed silence from the notification bar
reinstalled the client - issue back
rebooted 3 times - notice that I need to reboot at EVERY BOOT including the third one
set it to not use CBT - issue STILL there

this is the one client where I actually need CBT but it WILL NOT WORK without extremely annoying popups - and then it’s random about if it shows active or not.

How do I either:
get it effing working

or
Cause UrRbackup to serve the NON-CBT client to that specific machine
Note that that’s the worst case option, I’d actually like CBT working on this box.

I only have the machine on site for a limited time and need to fix this NOW, not the week after next when I can’t access the machine!

@uroni this has been going on for MONTHS ever wonder why I’m not buying more licences for more clients? I would if I could get it to WORK.

I’m also getting warnings in the event log Event 225 src Kernel-PnP urbctctl_lock.exe .. stopped removal or ejection of STORAGE\Volume\{........}#....... lots of them.

Setting CBT to disabled also has no effect.


#2

Sorry you are having issues. To solve the problem the client (debug) log would be useful.
If possible, could you post it or send it?

This post describes how to change the client to debug logging, where it is stored and where to send it to if posting is not possible: Having problems with UrBackup? Please read before posting

Thanks!


#3

Sorry, been a bit busy chasing other issues for producing a debug log, however, It would appear the problem is somewhere in the logic between the settings on the server, and how Windows or the client handle loading the driver.

Reason I say that is that every configuration I tried which excludes drive M* produced this issue, the moment I gave up trying to exclude it from CBT & set volumes to “ALL” the problem disappeared.

As such, and being under some pressure to return the PC (My niece is missing her games/Facebook/etc :wink:) I’m disinclined to try excluding M again (just specifying C,D) to see if the issue comes back. I’ll just live with a volume being tracked pointlessly for the time being.

  • I don’t need or really want to track M, it stores locally produced drive images for fast local recovery and thus doesn’t need to be backed up.