I'm glad the OP has changed his mind and is spending more time on this.

Since no-one else seems to have mentioned it, I'll explain the "elephant in the room" that I was trying to point out before: None of the evidence being provided, agrees with this being a 256MB USB stick! (Comments from a customer are not evidence - they are opinions .)

I politely disagree that the minor over-sizing of the CHS values in the partition table is relevant here (sorry Franc, I'm unconvinced) - both the CHS size and number of sectors value (0xF7FF) are approx the same 30-ish MB size. Neither is a 256MB value!

Plus, this is not a unique case - I've seen the CHS values multiply out to a slightly larger number of sectors than the partition size, several times before. As long as the CHS values are greater than or equal to the number of sectors value, then obviously the partition "fits" in that CHS region of the disk.

The OP has created a disk image and again, that's approx 31MB in size - not a 256MB value! You could try accessing sectors at around, say, 200MB and I expect you'll get an I/O error. If you don't, then that doesn't explain why you only got a 31MB disk image. Getting an error trying to read from a sector at around 200MB (anything above 32MB) would also show that the customer didn't just run "Partition Magic" or Paragon or whatever, and shrink the partition & the filesystem on a 256MB USB stick.

Now in sector 0x20, the BPB again confirms that the filesystem is also 30MB (0xF7FF sectors - BPB offset 0x13/0x14) - exactly the same size as the partition size given in the partition table, and again confirming that this is not a 256MB filesystem!

Furthermore, the BPB shows that the FAT16 cluster size being used is 2kB (4 sectors - BPB offset 0x0D) which is an impossible value for a 256MB FAT16 filesystem (there would be too many clusters, at that cluster size), but is correct for a 32MB stick.

The questions that I tried to lead the OP towards thinking about, are that the original customer needs to supply more history of this IMHO, to explain what they did before supplying the stick to the OP, and to explain why they claim that this filesystem was 256MB in size, in the past. The clear inconsistency is not from the various bits of data within the USB stick (which all agree at a 32MB stick, with a similar-sized filesystem); it's between the USB stick, and the claim from the customer that this is a 256MB USB stick.

IMHO there is no possible hardware failure or random corruption, which would change those (previously 2 known - now 3) sets of values (CHS & partition size in the MBR, and the BPB in the volume boot sector) to valid, consistent, 30-ish MB values, from 256MB values.

It seems much more likely to me that the customer is just mistaken, and this is a 32MB USB stick. The NAND flash chip markings themselves (if any) might be helpful in establishing the flash drive size, but they are not conclusive, as this may be cheap, partially defective "larger" flash, where only a subset of the original size is being used.

So in short - I see too much reliance on the original customer's apparent statement of this being a 256MB stick. I don't believe it, given that all the actual evidence being provided suggests it's a 32MB stick, with 31MB usable space (hence the size of the disk image) and a 30MB (almost 31MB) filesystem on it.

When there is any real evidence that this is a 256MB stick, I look forward to seeing it. Until then, I continue to believe that everything related to 256MB is a big red herring

I understand. So if this is actually only a 32mb drive and I can still only retrieve corrupt docx files from it, then what are my options?

_________________
Mr. Anderson
TriStateData.com

pm sent

I can't fault Vulcan's analysis and conclusion. It all sounds reasonable to me.

However, ISTM that whichever utility was used to partition the drive is clearly flawed. I can't see any reason why the start and end CHS values should not match the actual partition size, except for laziness on the part of the programmer. In fact I'm betting that if the OP runs TestDisk against the drive, it will report the same inconsistency. However, I agree that if the OS ignores the CHS data and instead uses the LBA values, then it will find the volume at the correct location. FWIW, the boot sector reports that there are 32 sectors per track, and 15 logical heads, whereas the partition table appears to assume that there are only 2 heads.

The boot sector also reports that there are 0x3E sectors per FAT. Since each cluster requires a 2-byte entry in the FAT, then this is once again consistent with a 32MB volume ...

0x3E x (4 x 0x200) x (0x200 / 2) = 32 505 856 bytes

One other observation I'd like to make is that the stick is partitioned like a hard drive whereas all the low capacity sticks that I recall examining were formatted as "super floppies". That is, LBA 0 on my sticks was always a boot sector rather than an MBR. In fact my old no-name 128MB MP3 player is also set up this way. FWIW, its FAT16 boot sector reports 64 logical heads, 32 sectors per track, and 4 sectors per cluster. Therefore, I would say that the owner of the stick most probably partitioned the drive, instead of just reformatting it, or using FIXMBR on it. This begs the question, did the partitioning utility correctly detect the capacity and CHS geometry of the drive? If it assumed 2 heads instead of 15, could this explain the capacity difference???

Of course the capacity question is moot, since the structure of the FAT16 volume appears to be correct. Running CHKDSK or Scandisk in readonly mode should quickly tell us if the file system has any problems. If the file system is OK, then, AFAICS, the problem reduces to corrupt files.

FYI, here are two resources that I found useful:
http://en.wikipedia.org/wiki/File_Allocation_Table
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm

_________________
A backup a day keeps DR away.

@fzabkar:

There is no CHS geometry reported by a USB stick, so a partitioning utility can't detect it. The USB MSD spec means that there is no requirement for a mass storage device to support any command detailing any kind of geometry (unlike the (fake) geometry which is reported in the Identify Device response from a SATA disk, for example).

In short, usually USB Mass Storage devices support just the minimum 6 (SCSI) commands - none of which supplies (even fake) geometry information to the OS. Those commands are: Read(10), Write(10), Inquiry, Request Sense, Test Unit Ready & Read Capacity. Therefore if the partition table is empty, an OS has to generate a (fake) geometry to use for subsequently populating the partition table, based on the device capacity.

For one of the (non-Windows) OS which I was involved with, I worked with a colleague investigating the (device driver) routines which had to generate a fake geometry, for the OS to use for its own purposes (for example, when creating a new partition table ) - the generated CHS values multipled out as close as possible to, but less than or equal to, the reported device capacity (but also had other restrictions, at least for that OS). The point is that there is no "one right answer" for the geometry of USB MSD, and in any case, the geometry is not supplied by the USB device itself.

@MrAndersons:
I won't spend too long replying, as I may just be duplicating whatever info you received via PM from networks.

IMHO you need to give much more info about what you have discovered, and what you have done already, than that provided so far - without that, IMHO it's like asking for drugs to cure your disease, when the disease itself is not yet diagnosed

Since there are now big concerns over what the customer has said, then the questions I explained before, for you to ask the customer, need to be answered IMHO. For example (and this is just a sample): What exactly is the history of this USB stick? When were the requested docx files last read successfully from the stick? When were they first not read successfully? What changed between the dates given in the answers to the previous 2 questions? What prompted the customer to try to read the docx files from this stick - is it just a backup? Is it possible that they went to this backup due to their main PC docx files also being corrupt? (ie is it possible that the PC which saved the files onto this stick, saved them already corrupted due to a hardware fault etc. etc.) What exactly was the customer's first reported problem when trying to read the docx files from this stick - was it that they were reported by the application (Word?) as being corrupt, or some other initial problem (e.g. I/O error)? Has the customer done anything with the stick (e.g. run any disk recovery or other utility) since they first discovered they had a problem? Is it possible that the needed files exist elsewhere on some different 256MB stick, that the customer has been mis-remembering? And why have they been claiming that this was a 256MB stick, when all the evidence so far points against that?

Now on to the USB stick itself: What file types are there on the stick? Are all file types "corrupt"? Are all docx files corrupt or only a few? What is common between the "corrupt" docx files (size? date? machine used to save them?)? Have you compared good and "corrupt" docx files from this stick (or between a known good docx from elsewhere and a corrupt one from the stick) using a hex editor - what is different in the file structure? Do the "corrupt" files have a sane size? How exactly are you testing that the files are "corrupt"? Someone (drc?) reminded us recently that docx files are compressed xml data - have you tried opening some (corrupt and good) in 7zip or similar? As fzabkar suggested, a read only chkdsk would be helpful in confirming filesystem sanity, though not not correctness of the data itself.

Of course there are many different file carving utilities you could try, but if one of them works in your case, then you won't gain any understanding of the real problem, and if none of them work, then you also gain no useful insight from that result. That's why a more detailed manual approach is what I would be doing - hence those starting questions above, to try to "frame" the problem. Depending on the answers that you give to those questions above, then a recovery strategy should become clearer (although I'm not committing to spending unlimited time on this).

Alternatively, you might decide to outsource the recovery since you can provide a disk image, if you don't have the time to spend on the investigation yourself.

Good luck with whatever you decide

P.S. What is the date & time of the folder FOUND.000 in the root directory? Also, are there are any files named filennnn.chk in the root directory (where nnnn can be any number) - and if so, what date & time do they each have? This info is to help build a history of what has happened, regarding previous detected problems with the filesystem.

It's very strange because some files are able to be read correctly like the .doc files and maybe a few .docx, but nearly all of the .docx files are corrupt. I can't get anything out of the client other than he had other IT people look at it and nobody could help him and it was originally 256mb and now only shows 30mb...he doesn't want to spend much money on it so I said I would take a look, but there isn't enough money involved for outsourcing. I am just trying to understand this scenario for future cases. I have tried several tools and even docx to doc conversion, but I'm afraid carving may be the only way.

I really appreciate your shared knowledge, without it people like me would have a much more difficult time gaining experience in this wonderful field

_________________
Mr. Anderson
TriStateData.com

Yes the found.000 file has a date of 11/19/2009 11:58 PM

_________________
Mr. Anderson
TriStateData.com

Thanks for the info about those chkdsk output files. Assuming that the PC involved had an accurate clock, then obviously that event was in 2009. Whether that was actually the time that the docx files were corrupted, depends on the answers to some of the questions I asked previously.


Interesting. You sound uncertain about whether some of the docx files are readable or not. Finding differences between which files are readable & which are corrupt (e.g. as I mentioned before - type of files, date/time, PC used etc.) may be helpful to understand why only some files are affected. Therefore this may be worth you clarifying further.

Also, as I said before, seeing exactly how the corrupt files are different (using a hex editor to view good & corrupt docx files for comparison), may give an idea as to what caused that corruption. Are the corrupt files actually docx files at all, or are they a different file type which someone has renamed wrongly to docx?

Did you try the suggestion from fzabkar to run a read-only chkdsk on the USB stick yet?


That's bad news for resolving his problem - lack of help = lack of progress. Not supplying information to you, when doing so could benefit him, is unusual IMHO. Of special importance is the little that he did say...


So now we have an unknown number of "other IT people" who have had access to (and, for all we know, could have changed the data on) that USB stick. How do we know that the state of the USB stick now, is the same as immediately after "the problem" was first found? We don't!


With this new information, then that might be true (though I still doubt it), if some extreme changes were made by the "other IT people" who had that USB stick before you did. As I said before, IMHO all the various changes to partition table & volume boot sector could not be caused by corruption or a hardware fault in this case, but I could force all these changes to occur, through a long series of manual steps and some special software. I still think it is unlikely (Occam's Razor still applies), but now knowing that "other IT people" have been involved, all bets are off.

Just for grins, are there any markings on the top of the NAND flash chip (U1 on your board)? If so, what are they (all)?


You're welcome, though I don't guarantee to have all the answers, especially since I don't currently work in DR and most of my experience was gained in other data storage / OS areas Others here have much more DR experience than me...

Good luck!

Yes some of the .docx files are readable, but the majority are not. There is a what looks like a wave in pencil maybe on the NAND chip, I think you can see it in the first pictures I posted. I have not run checkdisk on the drive yet.

_________________
Mr. Anderson
TriStateData.com

Hi, On the Soft Center forum the same drive is shown as 256mb though the manufacturers stated they were able to prepare this model anywhere between 32mb to 2gb. In my personal experience I have seen both the 32 and 64mb versions and I would doubt if in 2006 they were producing them as 1 or 2gb devices.

Take a look at the LCU-111:
http://forum.soft-center.ru/viewtopic.php?t=379
The one in the photo has a single Hinix brand ic so it is just possible your usb stick had the branding removed and it was sold as a lower capacity drive. It might even have been hacked to represent a higher capacity.

Sometimes with these it is also a good idea to see if Dmde can throw up anything more than has been found. Also I see from the photo you provided at the beginning the nand chip appears to have very poor alignment between the legs and the pads. I would definately re-work those areas just to make sure as this can often be a cause of the corruption.

So maybe it is just bad contacts on a 32mb stick?

@MrAndersons:
I'll just reply briefly to one point here:

Yes, I saw that - I should have been clearer; I was asking about any manufacturer's markings on the NAND flash, like those you can see on the flash controller chip (i.e. laser-etched). I can't see any such flash chip markings in your photos, but I can't tell if that just due to focus/lighting, or not - hence my question.

@dick:
FYI, remember that this USB stick has a partition table & filesystem which are both 30-ish MB. IMHO there is no actual evidence yet seen, that this was ever a 256MB stick (even though, as you say, the controller chip could be used with a wide variety of different capacity flash) - unless you have seen such evidence that this is a 256MB USB stick, in the data presented by the OP here so far?

ok, it's an old topic, just wondered if there had been any success in solving this.. bootex.log on my flashdrive shows this: Checking file system on F:
The type of the file system is FAT32.

The volume is dirty.
Volume Serial Number is 1234-5678
\Playlists Errors in . and/or .. corrected.
Removing nonvalid long folder entry from \AUDIO...
\AUDIO\. is cross-linked on allocation unit 4211.
Folder truncated.
Removing nonvalid long folder entry from \AUDIO...
Convert lost chains to files (Y/N)? Yes
39985152 bytes in 10 recovered files.
Windows has made corrections to the file system.

256925696 bytes total disk space.
14336 bytes in 5 folders.
68753408 bytes in 19 files.
188151808 bytes available on disk.

2048 bytes in each allocation unit.
125452 total allocation units on disk.
91871 allocation units available on disk.
so once upon a time it was 256mb, now refuses to accept it is more than 32mb. yes, it was cheap, yes it probably isn't worth persuing this problem, but I like problems, can anyone point me in a sensible direction please?