Byte for byte validation failed

[hime3]

Restored Win11 OS in new (1 week) desktop PC.
Byte for byte validation failed– 3 bytes.
During more than 20 years using Terabyte Unlimited backup/restore, byte for byte validation has never failed.
Read KB article.
Installed HD & added Crucial SSD automatically run TRIM.
No memory issues.
No Chkdsk issues.
Continued to use PC.
No apparent software or OS issues yet.
Any way to determine 3 bytes importance?
hime

[TeraByte Support]

You probably have a memory issue but could be in the chipset/cpu caches or less likely the drives/cables. It can be a real pain to find some of these, especially when coming from the mobo/chipset/cpu.

You would look at the lba it occurred on, run tbiview and use the option to search file for lba (or there is also a utility on the download site to do it to a live filesystem).

[hime3]

Thank you for TBIView suggestion. lba displayed [567296-996118527].
Reviewed TB free tool list. No tool text referenced lba.
lba is completely new territory. Searched, but unable to find how to use lba or relevance of number displayed to validation failure.
Can you suggest where I will find lba discussion/use material?

[TeraByte Support(PP)]

The LBAs you would search for are the ones shown with the error in the log. In TBIView you would open the image and search for each one. Note that if the image is being deleted because it failed, you can enable the "Retain Failed Backups" option in IFW's general settings.

The utility for a live system is on the ftp site (findlbaf.zip).

[OldNavyGuy]

Restored Win11 OS in new (1 week) desktop PC.
Byte for byte validation failed– 3 bytes.
During more than 20 years using Terabyte Unlimited backup/restore, byte for byte validation has never failed.
Read KB article.
Installed HD & added Crucial SSD automatically run TRIM.
No memory issues.
No Chkdsk issues.
Continued to use PC.
No apparent software or OS issues yet.
Any way to determine 3 bytes importance?
hime

I've noticed the same thing since Version 3.60 (now on 3.61a)

No Memtest86+ errors as well.

The only workaround I've found so far is to disconnect the target external USB drive, reboot, and then connect it after Windows has rebooted.

Then the image validates byte-for-byte just fine.

Interestingly, others work fine on backups and validations...without the external drive gymnastics.

Since they use VSS instead of Phylock, I'm wondering if there was a Phylock regression introduced.

[TeraByte Support]

if you have an error, there is an error, it doesn't matter if something else can't find a problem, or memtest86+ finds it or not, if you're lucky it does so quickly. Rebooting probably just changes the memory areas used or fixes a driver issue (full power cycle may be good too). You have to change the cable/device/port (use one directly on mobo not the case) if you think it's USB related, you have to chkdsk /f the source/target, you need to change out memory, and then the mobo/cpu, once the faulty hardware is removed, the error goes away for good. For driver / software /virus related issues, you can do backups / validations from boot media. When something has worked for a long time then a problem starts, that's exactly how it goes when hardware begins to fail.

[OldNavyGuy]

I'm familiar with how to troubleshoot issues like this, and all of that has been done.

I run IFW using Task Scheduler, so to suggest using boot media for other than testing is ridiculous.

Everything seems to point back to IFW/Phylock.

There is a Knowledgebase article about disconnecting the external drive, rebooting, and then connecting the drive after reboot...so it's a known issue.

https://www.terabyteunlimited.com/kb/kb ... ce-issues/

It's interesting that other imaging software does imaging and validates with no issues...using VSS

I'll test IFW using VSS, since that would be a better comparison. *

Given there is a KB article, and other users (including the OP) are experiencing the same thing...everyone can't be experiencing hardware issues.

* EDIT: IFW using VSS imaged and validated with no issues.

[TeraByte Support]

The USB article has to do with USB in general and IFD/BIBM.

It's hardware or a driver. You don't get validation errors otherwise.

[OldNavyGuy]

The USB article has to do with USB in general

None of that (disconnect, reboot, reconnect) was necessary using VSS.

So, if byte-for-byte works using VSS...and not with Phylock...that doesn't indicate hardware.

When the $USNJrnl issues were happening on 3.58 and 3.59, you guys were insisting it was something on the user's end.

I would agree that it's likely a driver issue.

I'll continue to test with IFW/VSS...one successful run is not enough to trust the software long-term.

Something has changed...never saw this in 3.57 (skipped 3.58 and 3.59) until 3.60.

These are fully-patched Windows 10 22H2 systems.

Wouldn't be the first time Windows updates caused issues with IFW.

You may want to take another look at 3.61a and Phylock.

[TeraByte Support]

Check the order and contents of drivers in upperfilters https://www.terabyteunlimited.com/kb/kb ... g-phylock/

If any lower level driver is changing data on the drive not flowing through phylock then validate will catch it. You can see the changes in the log if log level is high enough and you can find the file using the lba in tbiview.