Validrive results differ each run

  • SpinRite v6.1 is Released!
    Guest:
    That's right. SpinRite v6.1 is finished and released. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.
  • Announcing “BootAble” – GRC's New Boot-Testing Freeware
    Please see the BootAble page at GRC for the whole story.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


marky1124

New member
Sep 25, 2020
4
2
I have a pretty old 1GB USB stick. I don't suspect it of being a fake. I've run Validrive on it twice and both times it's reported about half a dozen different locations marked in red for 'no storage'. The marked locations differ between the two runs. One is potentially the same. Is this normal behaviour?
 
Basically mechanism behind 'no storage' = try write noise, then read noise back.

If success then no problem. Else: problem. There can be multiple causes behind not being able to read noise back from a sector.

If noise can not be read back:

If device reports error -> read error
If device reports success -> no storage, it's basically lying to us.

Primary mechanism with fake drives is not reporting errors when writing to or reading from non existent NAND. So that's the main angle of attack, write data and try read it back. If we can not read back while no error is returned by the drive then we're possible dealing with fake device. But even if not fake, it is behavior we should not encounter and therefore never a good sign.

I recover data from mainly USB flash drives and memory cards, SSDs and I see many type of weird error behaviors.

It's not uncommon for a troubled device to fail to give data when reading from a sector + lack of any meaningful error being returned. It seems to me this type of scenarios may cause ValiDrive to designate a sector as 'no storage' rather than 'read error'.

A second observation with such troubled USB flash drives is that read errors aren't perse errors at the location you're trying to read from. IOW they do not act like a traditional bad sector. One time a sector may read, the next it does not. So rather than the sector being bad, the controller/firmware is not behaving in a consistent and predictable manner. And this may explain why 'read error' or 'no storage' block location vary with each ValiDrive run.

In any case I would get rid of that USB flash drive.
 
Last edited:
I have a pretty old 1GB USB stick. I don't suspect it of being a fake. I've run Validrive on it twice and both times it's reported about half a dozen different locations marked in red for 'no storage'. The marked locations differ between the two runs. One is potentially the same. Is this normal behaviour?
It definitely should not be doing that. ValiDrive would be showing "No Storage" when it wrote some random data but did not get the same data back when it read it back. So I would definitely not trust this drive with anything important. The reason you're seeing differing locations is that ValiDrive's testing sequence is truly randomized and will never be the same twice. So whatever flaky thing is going on, it might also be about the pattern of the sequence (which is also not good!)
 
  • Like
Reactions: marky1124
But sequence does not explain why 'block 23' (for example) has different outcome in different runs. Or am I missing something obvious now?
Correct. That part is still very strange. Actually, I think I may have encountered something similar on one of my drives. I'll do some digging.
 
Correct. That part is still very strange. Actually, I think I may have encountered something similar on one of my drives. I'll do some digging.
Found it! It's my Sansumg SD card. However, I found something even stranger when I did some further testing. I'm going to reopen my ticket.


ValiDrive-v1.0.0_2023-10-05_23-02-10.png


ValiDrive-v1.0.1_2023-10-30_20-21-00.png
 
Did you check if ValiDrive is active in task manager after stopping it? I seen that happen.

And if so, does closing that instance eliminate the need for a reboot?
I just watched Task Manager while reproducing the issue, and there was only ever 1 instance of ValiDrive running. I also verified there were 0 instances after closing it. Thanks for the suggestion though. I doubt I ever would have thought to check for that :)