The support forum

Bvckup2 Fails to Recognize Fingerprinted Removable HDDs Randomly

Doequer :

May 05, 2021

Hello, the past days I'd been trying your program with a set of removable hard drives, and I noticed that despite I have chose have them tracked with the "fingerprint" feature, every now and then it is needed a "manual" update of my part, regarding a little section of the generated fingerprint code. I bet this happens because not all the times I use the very same "SATA>USB 3" adapter with the same disks. Is there a chance to improve this behavior, in a way that manual task isn't needed anymore? I mean, all the disks have a unique serial number which identifies them individually, and which is part of that "fingerprint" as far as I know, but still they are not detected as such all times by the program.


Alex Pankratov :

May 05, 2021

There are some enclosures that for reasons unknown override disks native serial numbers with random values. This is not fixable. The only way around this is to use tracking by volume label.

Next time this happens, go into the Device Tracking config window, copy existing ID, then refresh it, copy the new one and let me have a look at both.

Doequer :

May 05, 2021

I see, the times when this happens, only a little bit of the last part of the code changes, so  I will do what you said next time.

By the way, I was going to create a new topic, but since maybe it is a related issue, I will tell it here directly:

Sometimes, despite the drives being present and operative, Bvckup2 will still asks for "destination" or "source" disks, and those times there is no "fingerprint" changes involved, but the program will not recognize the disk unless I close it completely and open it again.

Might it be a related issue?

Alex Pankratov :

May 05, 2021

The way the program works is that it does a full scan of the storage stack on launch and then it relies on device/volume events to keep it up to date, incrementally, with specific device/volume queries.

In your case it sounds like the device arrivals or volume mounting events are not correctly (or reliably) dispatched by the OS. This should not be happening, it's certainly a serious issue. These events are generally dispatched by respective device drivers, so something as simple as updating them may resolve the problem.

In earlier versions it was possible to force the program to periodically do a full scan of the storage stack, but it was removed, because event-driven updates were working very reliably.

What you can do is to check if the program in fact "not seeing" your drives or if it might be something else. All storage device and volume related activity is logged in %LocalAppData%\Bvckup2\bvckup2-storage.log. It will show the device/volume events received by the program, followed by the updates triggered by these events, followed by a dump of program's view of the storage stack. It should be fairly easy to make sense of what's going on.

Doequer :

May 06, 2021

Earlier today I noticed something that might be the cause of the issue I talked about in my second message of this thread:

Some backup jobs get put into a "Waiting for the original destination device..." state, after I change the next setting:

"Better performance>Write-chaching policy".

No fingerprints changes at all, but the backup jobs remain in that state till I shutdown and execute the program again. I examined the "bvckup2-storage.log" and saw the disk's fingerprint was altered at least once, from this:

| removable | 3BEE7880.NTFS.100000.1D1C0D00000.ZK200NG1________      | \Device\HarddiskVolume26

To this:

|           | 3BEE7880.NTFS.100000.1D1C0D00000                       | \Device\HarddiskVolume26

And then it went back to the original state.

I usually look into that specific setting each time I connect a hard disk to a different adapter, since although most times the previous setting is still valid, sometimes I see it isn't applied; in these last cases, although the program detects the setting was applied, it doesn't become aware the disks are still there.

Alex Pankratov :

May 06, 2021

The last bit is a serial number of the disk as read from the disk. The fact that it is sometimes readable and sometimes it's not means a bug in the disk/enclosure driver or firmware  =>  you can't use device tracking by ID for this disk.

That said, if you are not running bvckup2 "as admin", consider trying that. This tends to resolve issues with various low-level OS queries, because a fair amount of drivers don't handle un-elevated requests correctly.

Doequer :

May 06, 2021

Hello, just to be sure about what you have explained:

Since this issue happens with all the disks I have tried as well as adapters, is it normal that after applying the "caching" policy, involved disks become temporarily "invisible" to Bvckup2? And that it will be needed to shutdown the program in order they get recognized each time that feature is activated?

This is about some disks suddenly becoming unrecognized by the program, so the other issue about "changing" fingerprints remains to be investigated by me.

Alex Pankratov :

May 06, 2021

Changing the Removal Policy should not cause the serial number of a removable disk to change or become unreadable. So, no, this is not normal.

Doequer :

May 07, 2021

OK. I looked into the storage log one more time, but this time using a different disk, and I saw although the last bit of the disk's serial number disappears momentarily after applying that policy, Bvckup keeps detecting it just fine afterwards, but the disk gets another "volume number":

This when the disk is connected:

| removable | CDE09D40.NTFS.100000.1D1C0D00000.WD-WCC4M3ZX39D2_      | \Device\HarddiskVolume23

This after applying the policy:

|           | CDE09D40.NTFS.100000.1D1C0D00000                       | \Device\HarddiskVolume23

And this a few milliseconds later:

| removable | CDE09D40.NTFS.100000.1D1C0D00000.WD-WCC4M3ZX39D2_      | \Device\HarddiskVolume24

If I eject the disk safely and then re-connect it (without physical disconnection), there will be no need to shutdown/execute Bvckup2 again, the disk will be recognized fine again. So, since this happen specifically when I apply the removal policy only, I bet the device tracking by ID might still be used.

Doequer :

May 07, 2021

Curiously enough, I just noticed using that the very same adapter, there was a disk which despite not having that policy enabled, its serial number wasn't changed at all after applying it; having only its "volume" number altered, and remaining always present in Bvckup's job.

By the way, I forgot to say I always run the program with administrator privileges and that the adapters uses no "special" drivers but Microsoft's ones.

Alex Pankratov :

May 09, 2021

What's the dock model/vendor? Not IcyDock by any chance?

Doequer :

May 10, 2021

It is a "JMicron JMS578" bridge controller based adapter cable.

Doequer :

May 29, 2021

Just a little bit more of information regarding this issue, after what happened earlier today when connecting a hard disk:

1- I connected a disk which in the relevant job, had a "S" as last assigned drive letter and HWID fingerprint enabled. As per the storage log, it gets a "G" drive letter first:

G: | Fixed     | Yes | 08DA-175D | JOB TITLE                | removable | 08DA175D.NTFS.100000.1D1C0D98200.ZFL2W67L________      | \Device\HarddiskVolume98

Then, around one second later, the "A" drive letter, which is the right one, as being the current one assigned by the system:

A: | Fixed     | Yes | 08DA-175D | JOB TITLE                | removable | 08DA175D.NTFS.100000.1D1C0D98200.ZFL2W67L________      | \Device\HarddiskVolume98

And it keeps like that, both times the right HDD serial number being shown (despite the long underline).

2- The job keeps showing a "Waiting...." message; so, I look into its configuration. The next value is present as HWID fingerprint:


Which despite belonging to the right disk, isn't exactly correct, having its last part filled with "bogus" numbers.

And on that same screen, after pressing the "update" button, the fingerprint value change to the next one:


Which belongs to a completely different drive, that currently is connected to the system, and has assigned the "S" drive letter. I didn't update it, since that's clearly wrong.

3- I closed the program and then open it again, but it remained in the very same condition.

At this point, I noticed there is no way the program assign the correct HWID fingerprint, since every time I try to update it, it wants to change it to that from another drive (S).

By the way, I have another job which involves the current drive "S" as a destination drive, and has its HWID fingerprint correctly assigned.

Since I don't remember facing this issue exactly like that before, I will try to figure out how to proceed in this case and give you a heads up should I fix it.

Doequer :

May 30, 2021

OK, I have finally sorted out the issue. I had to enter manually the correct HWID fingerprint, exactly as it appears in the storage log. The same one that for some weird reason, the program refused to update automatically.

Luckily enough, I was paying attention when I dealt with this issue, since in case I had just let the program update the HWID fingerprint by its own automatically, the whole content from another backup disk would have been erased to get that from a wrong source HDD instead.

Alex Pankratov :

Jun 02, 2021

OK, thanks for the detailed write up and the follow up.

New topic

Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms