A few weeks back, eBay had a 15% off everything sale on a Sunday, and I was feeling like I needed to make the most of it. There wasn’t too many things I could really need but I did decide that a few large microSDXC cards wouldn’t go astray.
I was looking for something with a decent amount of performance and a reasonable price, and a side positive was if it was not already tested, because that means another blog post for all of you.
I came across a Lexar 600x 64Gb MicroSDXC card from an eBay seller with >99% positive feedback who will remain unnamed, for a decent, but not unreasonable price. The cards were advertised as:
Lexar Ultra 600x 64GB Micro SDXC Memory Card Genuine Lexar card!!! Bulk package in mini plastic case.
I had to buy two to make the 15% offer, so I put in an order for two. After all, Lexar is a reputable brand, and I definitely have no Lexar cards in my collection at the moment. A little bit of homework showed that the product itself was given a press release on Lexar’s website, so it’s not as if it was entirely made up.
From past experience, if you get a fake, you’d recognize it right away. Poor quality faded silkscreening, logos with wonky proportions, text which isn’t straight or font changes are just some of the imperfections many fake cards have. Another difference is the rear etchings. As a result, I paid good attention to examine the cards themselves.
The silkscreen text was a very sharp, bright white, and it looked good. A review of an updated 633x card, which is part of their present lineup, shows rear markings that match the same formatting and are made in the same place. Looks good so far.
The two cards’ CID and CSD details are as follows:
CARD ONE cid: 284245202020202001bb193b6700da5b csd: 400e00325b590001dd3d7f800a40001d CARD TWO cid: 284245202020202001bc182a4500dad5 csd: 400e00325b590001dd3d7f800a40001d
I don’t have any Lexar cards to compare to, but checking the database shows the Vendor ID doesn’t match with any of those within the database, and the CIDs are unique due to differences in serial number, which is another positive sign. The product string is just a sequence of spaces (0x20), but that isn’t entirely unusual given that other cards have similar results.
Lets get along and start reviewing the card as per usual then …
Filling the entire card surface with random data didn’t pose any problems at all. Reading it back resulted in the same values every time as well.
HD Tune Pro with Transcend RDF8
The card doesn’t make it to the 95Mb/s that is claimed, and averages 64.3Mb/s which is quite a distance from the stated speed. I would expect about 83Mb/s judging from the contemporary 90Mb/s+ cards. Hmm.
HD Tune Pro with Kogan RTS5301
Placing the card into the reader bare failed to negotiate UHS-I mode, so the transfer rate was capped at 22.5Mb/s. Lets try using a microSD to SD adapter:
With the adapter, the card averaged 51.9Mb/s, again, falling short of the promised speeds. Given that most cards excel strongly at sequential read, this is hard to believe.
CrystalDiskMark with Transcend RDF8
Using CrystalDiskMark, the card does now reach 83.58Mb/s which is in the ballpark of other 95Mb/s cards previously tested. The other speed scores are not too bad, and are in fact quite good.
CrystalDiskMark with Kogan RTS5301
Unfortunately, it seems that the Realtek-based reader wasn’t able to extract full performance from this card.
The Trouble Begins
Imagine my surprise when, after all of this, and never having seen this before … I get this:
Yikes. H2testw believes the card is defective, with the original factory formatting, losing 2.7 Megabytes of data. The full text is as follows:
Warning: Only 61054 of 61055 MByte tested. The media is likely to be defective. 59.6 GByte OK (125032884 sectors) 2.7 MByte DATA LOST (5708 sectors) Details:0 KByte overwritten (0 sectors) 0 KByte slightly changed (< 8 bit/sector, 0 sectors) 2.7 MByte corrupted (5708 sectors) 0 KByte aliased memory (0 sectors) First error at offset: 0x0000000149faa000 Expected: 0x0000000149faa000 Found: 0x000000014dfaa000 H2testw version 1.3 Writing speed: 42.0 MByte/s Reading speed: 72.7 MByte/s H2testw v1.4
Having thought this might be because the card was incorrectly formatted (oversized), I reformatted it with SDFormatter with the size adjustment on, and data overwrite.
It still did not pass. The full report is as follows:
Warning: Only 61050 of 61051 MByte tested. The media is likely to be defective. 59.6 GByte OK (125030032 sectors) 184 KByte DATA LOST (368 sectors) Details:0 KByte overwritten (0 sectors) 0 KByte slightly changed (< 8 bit/sector, 0 sectors) 184 KByte corrupted (368 sectors) 0 KByte aliased memory (0 sectors) First error at offset: 0x00000002fafaa008 Expected: 0xfafaa02cb4af6011 Found: 0xfafaa02cb4af6001 H2testw version 1.3 Writing speed: 43.1 MByte/s Reading speed: 73.0 MByte/s H2testw v1.4
Notably a smaller amount was lost, but it really should be nothing. It’s even more interesting to see that the data was not lost at the end of the card but somewhere near the 4Gb mark.
Bouyed by this, I decided to random fill the card a few times, then reformat it again to see if I can recover the corrupted sectors. After another format, the results seem to show less failing memory.
Trying it again …. and nope. It seems to have made it slightly worse again!
After this, I did a pattern fill on the card and examined the corrupted areas. To my surprise they contained random data and were not sector aligned. That is very curious, given the nature of flash normally using pages with a size of a binary power. Maybe this indicates a dud controller, failures in the flash translation layer, the use of some compression. Another thing is that it seems that the controller being configured not to report errors even though a read is entirely ECC uncorrectable. This may make a user’s job easier in recovering from a dud card, but it masks the problems and causes silent bit-rot, which wasn’t detected by a random fill and multiple read-back test.
After that, I gave it a format … and … miraculously, the card now holds data correctly!
But that’s not where the story ends … I was still skeptical about this card – the read performance has dropped dramatically from 72.7Mb/s to 67.0Mb/s. What the hell is going on. I decide to give it another few passes … and then … it locked up on me.
The card behaved as if it was write protected, regardless of reader. I even tried using a direct slot on the Samsung ARM Chromebook and couldn’t force any writes. Instead it held the last bit of data that I had put onto it … and that was all.
This seems to be indicative that the card has entirely run out of remappable flash sectors to the point it had exhausted all spare sectors and could not continue to function, dropping back into read-only mode to allow users to recover their files and move on to another card. All of this happened in under 10 cycles.
The Mystery Deepens
This is where the “sister” card gets involved. It turns out, the sister card itself was happy, and easily passed five cycles of H2testw even with its original format.
The read performance didn’t decline or waver as much. But the card still didn’t quite show the 95Mb/s read performance that I would have expected. My confidence in the status of the cards is still shaken, and thus the results are not going to be included in the database.
It seems this is a very peculiar situation with several possibilities:
- It’s a counterfeit card, elaborately silk-screened and laser etched to meet the original’s in terms of appearance.
- It’s a defective genuine card that may have “escaped” destruction at some stage.
- It is a genuine card, albeit a bad sample that evaded quality control.
Lets consider each of these possibilities in turn:
- Generally, counterfeit cards seek to maximise profit – there isn’t much to be gained by using what appears to be a real 64Gb card to counterfeit a 64Gb card. The cost of a 64Gb card is not insignificant. Instead, maybe by remarking a lower-performance card as a higher performance card, they can gain some money, but by card standards, this card wasn’t too bad in terms of performance. Maybe they got some OEM cards from a different vendor and remarked them to look like Lexar for some quick bucks. It’s a lot of work though.
- I think it’s possible, although a supply of defective genuine cards is rather limited. My assumption is that most defects are likely caught early in production before they are properly branded and marked.
- Also a possibility, although the performance makes me question whether it’s a genuine card at all. The only way to tell for sure would be to decapsulate the card and image the die, or try some X-ray photography, none of which I have at my disposal.
Regardless, this isn’t a card I can trust.
I think the message is to test and be wary of any products you receive. You should always test your hardware before commissioning it to catch these sorts of issues. While I can’t conclusively say the card is a counterfeit, it definitely appears to be defective. The way the card corrupted data was also rather surprising, and it’s not behaviour I would expect from a Lexar card at all. The fact it took numerous overwrites for the (supposed) reallocations to occur suggest something strange going on. The write protected status in the end indicates the card itself was having an internal struggle of its own.
It has shaken my confidence in buying cards on eBay even from sellers with high positive feedback scores, specializing in memory products. I managed to return the two cards (at my cost) for a full refund, but lets just say, this was not a positive experience. I suppose you should always be wary, especially of “bulk packaged” items.