Strange Problems with Pendrives

[LoneCrusader]

Ok, a couple of new developments.

I ran ScanDisk on the drive, and got this error:

I don't know what's with this image, it didn't look that way when I saved it

Test was run on another Win98 System, that's why the drive letter different in pic.

Since the error stated that the boot area was damaged or invalid, (and remembering what happened with the drive that started this thread), I canceled ScanDisk so we can investigate further before it gets modified.

I tried some of the tools jaclaz listed, I was able to make an image of the drive, broken into 1999MB blocks with Partition Saving. It should be noted that Roadkil's Diskimage cannot break the image up into <4GB parts, it appeared to run normally, and claimed the image was complete, but it only created a 3.99GB file and apparently did not realize it had stopped writing. Haven't done anything else with the images as yet.

As above, remembering the problems with the first drive, and the steps we took then, I put the drive back in XP and ran HDHacker on it. Here's the MBR and PBR output.

KDT8GB_MBRPBR.zip

Edited March 6, 2011 by LoneCrusader

[jaclaz]

As above, remembering the problems with the first drive, and the steps we took then, I put the drive back in XP and ran HDHacker on it. Here's the MBR and PBR output.

The MBR is a non-bootable one. (containing the string "Pen Drive Without Operating System.Remove Pen Drive And Reboot. ").

The partition is a FAT32 0C type, NOT Active, with really "weird" CHS/LBA data

Entry Type Boot  bCyl  bHead bSect  eCyl  eHead	 eSec	StartSector   NumSectors  
#0	 0C	 00	 0	 3	 4	 242	 121	 58	   192	 15673152

The CHS/LBA data is NOT "balanced", AND it breaks any known "standard" or "convention".

If we give as "good" the CHS, the LBA should be 192/3.895.219.

If we give as good the LBA, the CHS should be 0/3/4 975/158/15.

The "right" values should be:

0/1/1 974/254/63 63/15663312

The PBR it's a "normal" FAT32 bootsector invoking NTLDR, but it uses a geometry of 128/63 instead of the "usual" 255/63.

It is not strange that any tool/utility reports "something wrong" in the boot DATA.

jaclaz

[rloew]

As above, remembering the problems with the first drive, and the steps we took then, I put the drive back in XP and ran HDHacker on it. Here's the MBR and PBR output.

The MBR is a non-bootable one. (containing the string "Pen Drive Without Operating System.Remove Pen Drive And Reboot. ").

The partition is a FAT32 0C type, NOT Active, with really "weird" CHS/LBA data

Entry Type Boot  bCyl  bHead bSect  eCyl  eHead	 eSec	StartSector   NumSectors  
#0	 0C	 00	 0	 3	 4	 242	 121	 58	   192	 15673152

The CHS/LBA data is NOT "balanced", AND it breaks any known "standard" or "convention".

If we give as "good" the CHS, the LBA should be 192/3.895.219.

If we give as good the LBA, the CHS should be 0/3/4 975/158/15.

The "right" values should be:

0/1/1 974/254/63 63/15663312

The PBR it's a "normal" FAT32 bootsector invoking NTLDR, but it uses a geometry of 128/63 instead of the "usual" 255/63.

It is not strange that any tool/utility reports "something wrong" in the boot DATA.

jaclaz

The Partition's CHS entries and Geometry are strange but have no effect since a Type "0C" Partition is a LBA Accessed FAT32 Partition.

The CHS values are not used.

A FAT32 PBR is 3 Sectors long repeated with an offset of 6 Sectors. You need to grab 9 Sectors to get all of it.

I suspect the problem is in the FAT Table and/or Root Directory.

If you can grab 7840 Sectors starting from the MBR, you should have all of the relevant data.

[jaclaz]

The CHS values are not used.

Just for the record, not on the DOS/Win9x bootsector, and should not on any apps, but the NT bootsector does use some of the CHS data, on bothe NTFS and FAT32 partition type:

http://www.911cd.net/forums//index.php?sho...1702&st=129

http://www.boot-land.net/forums/index.php?...=8528&st=21

However nothing of the above seemingly "justifies" the different number of used space , at the most it can explain why the scandisk warning/error.

jaclaz

[dencorso]

If you can grab 7840 Sectors starting from the MBR, you should have all of the relevant data.

Yes, please do it and attach it as a compressed archive. And since 7840 is almost 4 MiB, while you're at it, grab instead 8192 sectors, so that we can look a little beyond, just in case.

[LoneCrusader]

If you can grab 7840 Sectors starting from the MBR, you should have all of the relevant data.

Yes, please do it and attach it as a compressed archive. And since 7840 is almost 4 MiB, while you're at it, grab instead 8192 sectors, so that we can look a little beyond, just in case.

Partition Saving didn't let me choose a sector count, so I set the split file size to 4mb and stopped it after the first one. If this doesn't work, or isn't what you need, Ill try something different.

EDIT: Bad file removed.

Edited January 18, 2010 by LoneCrusader

[dencorso]

No, sorry! It was a good idea but didn't work quite right. I think you can do it easily with MBRFix.

[LoneCrusader]

No, sorry! It was a good idea but didn't work quite right. I think you can do it easily with MBRFix.

Ok, how's this?

K8GB8192.7z

[rloew]

The CHS values are not used.

Just for the record, not on the DOS/Win9x bootsector, and should not on any apps, but the NT bootsector does use some of the CHS data, on bothe NTFS and FAT32 partition type:

http://www.911cd.net/forums//index.php?sho...1702&st=129

http://www.boot-land.net/forums/index.php?...=8528&st=21

However nothing of the above seemingly "justifies" the different number of used space , at the most it can explain why the scandisk warning/error.

jaclaz

The partition was not bootable, so the NT Boot Sector code is not used.

I did check the NT Boot Sector Code. It would have used CHS if the Partition were Bootable. The Code never checks the Partition Type.

The NTLDR code in Partition Sector 12 is missing but doesn't matter in this case.

Edited January 18, 2010 by rloew

[rloew]

No, sorry! It was a good idea but didn't work quite right. I think you can do it easily with MBRFix.

Ok, how's this?

I accidentally gave the number of sectors in hex. It should have been 30784 or a little less than 16MB.

I looked at what you sent.

It appears that the free space count in the second PBR sector is one less than it should be.

Windows 9X used the value and computed the allocation.

Windows XP may have scanned the Partition and determined the true allocation.

Try SCANDISK again. If you don't want to make changes, use "ignore" to go to the next step after each error.

[RodgerOver]

"Try SCANDISK again. If you don't want to make changes, use "ignore" to go to the next step after each error."

I can't advice to do that. See my exeperience at the beginning of this thread. Now I can't access my pendrive anymore !

Roger

[rloew]

"Try SCANDISK again. If you don't want to make changes, use "ignore" to go to the next step after each error."

I can't advice to do that. See my exeperience at the beginning of this thread. Now I can't access my pendrive anymore !

Roger

That's why I said to use "ignore" to step over errors without changing anything.

At some point it should report that the available space is incorrectly set.

Fixing it is an entirely different issue.

[dencorso]

RogerOver, the situation is different here: LoneCrusader has just recently made a full sector-by-sector pendrive image, just before we started. So, there is negligible risk at it, because if the pendrive gets fubar it's just a a matter of redeploying the saved image, and this can be done all over again, as many times as we decide it's wise. When you have a true up-to-date backup, it's safe enough.

Moreover, you disappeared from the topic, so I presumed you either had solved your problem but forgotten to report it, or, more probably, had given up...

Well, I, for one, think alongside the same lines as jaclaz: to give up is not an option, unless you're quite sure the hardware you're working with is truly fried, or by whatever other irreversible reason, beyond recovery, that is, quite dead. I'm sure that's not the case with your pendrive. So, welcome back to the thread. Maybe this time we'll get yours (if my crystal ball is working today, I predict we'll have to reprogram its controller) to work, too!

[LoneCrusader]

I accidentally gave the number of sectors in hex. It should have been 30784 or a little less than 16MB.

....

Try SCANDISK again. If you don't want to make changes, use "ignore" to go to the next step after each error.

Ran ScanDisk again, got same error, chose to Ignore. After that, ScanDisk finishes normally:

It seems that ScanDisk is seeing the correct amount of used space, however, the exact same incorrect value is still displayed in the "Properties" tab in Explorer.

Do you need me to image the first 16mb of the disk?

I can't advice to do that. See my exeperience at the beginning of this thread. Now I can't access my pendrive anymore !

Roger

Don't worry, the drive we're working on now is brand new and blank. This one's all for science, haha

So maybe we can get to the bottom of these bizarre flash drive errors. I'm beginning to think that the first thing to do after buying a new one is to repartition it and reformat it, so that way you know it will have "normal" settings

Edited March 6, 2011 by LoneCrusader

[dencorso]

Well, it seems scandisk is finding the error, all right. I'd say let it correct it, repeat the scandisk to be sure it doesn't find anything wrong after the corrective pass (it ought not to), test in both OSes and tell us how it went. Good luck!

I'm beginning to think that the first thing to do after buying a new one is to repartition it and reformat it, so that way you know it will have "normal" settings

That's been my most firm position about it, from the time I bought my 1st pendrive... I have nine of them nowadays, and didn't change opinion in the least. You cannot trust what the manufacturer puts in key places, period. And I like to have mine single partitioned, with the single FAT-32 LBA partition entry in the 4th sloth (Zip de-facto standard) and using the RPM standard IPL, and with the single partiion starting in 0/1/1, *not* 0/0/2, and, yes, I do check whether the resulting partition is CHS/LBA balanced. The partition, I format to FAT-32 in DOS and SYS it for a good boot sector. Then I remove the DOS system files to render it not bootable, and free the space. So it remais potencially bootable to DOS, if I so wish, and has a very definite structure without anything unusual. For all purposes it's an Iomega ZipDisk. This method never gave me grief, and, by now, I do it quite fast, in 98SE, with RPM, format and sys. In case I do want to use an unusual sector per cluster count, I do the formatting in XP with Fat32format, instead, but take it back to DOS for the finishing sys. This is my procedure for general use. Special uses demand special procedures, of course.