validrive says the drive is great, but its actually not.

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. 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 please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • 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.)

z80

New member
Oct 8, 2023
1
0
i have a no name 64gb drive that shows up in validrive as actually full spec. however when i go to write too it, it really dosnt want to write. go to delete, fails. when i check the drive via windows properties, it says 10gb is used, but when i look at the properties of the files on it, 360mb. i suspect something else heinous is going on. id love to send the drive or get walked through finding out myself where the issue lies. seems like an issue validrive, a drive validator, should have caught.
 
I would assume the controller on this one is failed, or the flash is EOL as well.

However I can see one issue is some drives with fake firmware that allocates a chunk for partition and FAT, then the rest is simply used to round robin keep the latest files written, overwriting older stuff, while keeping the FAT entries for it there and looking valid, but reads will come back for the current modulo x data. A way to solve this would be to randomly (about every 512M I would say) keep a hash of a page, and every time you go over the 1G mark read all of those previous LBA units again, and compare the hash, and if valid, then store the hash of the next LBA again and continue. Then after completion read all that table again, and this will then give a good confidence the drive actually stores data. Hash mismatch on a read you immediately fail the drive, unless it had a read error. Read error you fail it with read error, if there was mismatches then fail, saying the drive appears to discard data that is older, and show a table of the LBA units, the expected hash, and the current hash. I very much doubt that the drive fakers will put in firmware that will look for this behaviour, it is easier to just ignore, as they figure that nobody will return them before the taillight warranty is over.
 
  • Like
Reactions: z80
Try testing the drive with one of the other tools that exist. (Even SpinRite 6.1 if you have one of the pre-release versions working.) There is the h2testw program that does a deeper test than ValiDrive does (testing the entire contents, not a statistical sample.) https://h2testw.org/ (Please be VERY CAREFUL on that site because the ads there look like real download buttons and may lead to unfortunate results.) This site as a list of many tools, but I have never tested any, so am vetting none: https://www.geckoandfly.com/22803/detect-fake-usb-flash-drives-sd-cards-ssd-disk/
 
Last edited:
i have a no name 64gb drive that shows up in validrive as actually full spec. however when i go to write too it, it really dosnt want to write. go to delete, fails. when i check the drive via windows properties, it says 10gb is used, but when i look at the properties of the files on it, 360mb. i suspect something else heinous is going on. id love to send the drive or get walked through finding out myself where the issue lies. seems like an issue validrive, a drive validator, should have caught.
I understand your point -- but that's expressly NOT what ValiDrive is for. You could certainly argue with the name, suggesting what something that calls itself "ValiDrive" should do... but then, the phrase "a drive validator" is also subject to wide interpretation. So, for the record, we KNOW what ValiDrive is for, right? Even if it not what you want it to be for in this puzzling instance. It is ONLY intended to check for the presence of declared storage across a drive's media. And, as its documentation clearly says, it's only performing a spot-check.

We DO have something that can check the entire drive... it's called SpinRite! <g>
 
I had a similar problem as the original post, i have a 128GB sandisk micro sd card, I tested it with H2testw and it shows that the drive is in fact only 7.4GB. But when i tested it with validrive it came back as ok.
I wanted to try validrive since with bigger drives it takes a long time to use other software.
From what i can see in the logs of the drive I tested, it seems that information is only discarded once the real drive is full. So on my drive i can store about 7GB of date, but once i go over that it will be lost.

I've added screenshots of the too tests also.

Thank you for the work you do with these programs it very much appreciated.
 

Attachments

  • H2testw.png
    H2testw.png
    20 KB · Views: 128
  • validrive 1.png
    validrive 1.png
    77.1 KB · Views: 131
I had a similar problem as the original post, i have a 128GB sandisk micro sd card, I tested it with H2testw and it shows that the drive is in fact only 7.4GB. But when i tested it with validrive it came back as ok. I wanted to try validrive since with bigger drives it takes a long time to use other software.
Hey Pierre: As far as we know, SanDisk is a company we can and should trust. I strongly doubt that they would have any involvement in any kind of subterfuge. So, assuming that your SanDisk MicroSD is really from SanDisk and not a high level forgery (which we've never seen before) I would bet that the card is 100% authentic, that ValiDrive is correctly doing what it was designed to do, and that what you have is a defective card with errors which H2testw is misinterpreting.

(And nice job on the ValiDrive "dialog stretch" image! (y) )

If I come back to this for a ValiDrive v2, I would change the program's logic to read all 576 locations first. Write them all with unique signature patterns, read back and verify all of the signature patterns, then restore all of the original data. This would do several things: It would make ValiDrive immune to falsely passing a drive that was aliasing any of the tested sectors (though as far as I know, doing that is an urban myth that has persisted because it certainly is possible, though we have never encountered any evidence of it.) And be performing all reading and writing "all at once", I suspect that ValiDrive could run far faster on many drives where it is very slow today.

But even so, what people really want is a "SpinRite for USB under Windows." -- they want a test of USB mass storage to assure them that a drive is not only the size it claims to be, but also a reliable place to save their data. ValiDrive was intended and designed to only perform the "drive size" assurance task. :)
 
I have 2 fake drives that get all green in ValiDrive.


1) Sansumg 2 TB SD card. H2testw shows it's really 8 GB.

1698433066369.png


1698433157354.png


1698433180673.png


2) Delaihe 980 EVO 4 TB SATA SSD. I haven't run h2testw on it yet. To scan it with ValiDrive, I attached it to an M.2 to full-size SATA adapter, then a SATA to USB adapter.

1698433221428.png


1698433245320.png
 
we have never encountered any evidence of it.
@Steve:

You seem convinced that there are no drives with FIFO type behaviours despite the fact that several people have pointed out they have such drives. Perhaps you should offer to acquire one of these drives to put your doubts to rest. In the mean time, I think you should make a clear note in the ValiDrive FAQ (or in the program itself) that it is not doing an exhaustive test (and potentially recommend a program that does do such a test) and so ValiDrive can be fooled by drives like these. The last thing we want is people being convinced their drive is good by ValiDrive, only to then find out the hard way that much of their content is now gone because they wrote a lot of content and the drive only retained a little of it.
 
I would happy to acquire any of these drives to see for myself. If @ColbyBouma can/will provide link(s) for their purchase I'll be glad to follow in his footsteps, as I have previously, to grab some to characterize their behavior. (y)
 
It turns out ValiDrive can detect the fake area of my Sansumg SD card. I had encountered a bug in ValiDrive without realizing it.

This bug seems to happen when I stop a test, quickly close ValiDrive, then run another test. More detailed steps are available in the ticket.


@z80 Please reboot your computer and try running ValiDrive again.
 
UPDATE: Two “impossibly inexpensive” NVMe drives from AliExpress have arrived (1TB and 4TB) and they are indeed quite suspicious. I've opened an exploration tracking issue in GRC's GitLab for ValiDrive to contain my findings. The various SD cards which were also ordered have not yet appeared.

(Note that I do not plan to duplicate my findings here. I'll be doing that over in GRC's GitLab.)