Can incorrect HD jumper settings cause corruption??

Status
Not open for further replies.
If anyone has seen this happen, please let me know -- I have Googled the entire Internet it seems, but haven't found anything similar. This problem has happened to me twice in similar situations -- or am I imagining this?? The scenerio:

When adding/moving around a hard drive or a CD-ROM to a system, I have accidentally left both the CD-ROM and the hard drive jumpers in the Master position (or both in the Slave, I'm not sure which) on the same IDE channel. Afterwards, upon the next boot, I have communicated with the CD-ROM, installing software in each case... first time it was a CD burning program, the second time it was Windows 2000... at some point things weren't quite right and I discovered my jumpering error and fixed it.

In case #1, Windows 98 on the hard drive got corrupted and wouldn't boot. Damaged registry I think.

In case #2, the hard drive is now not recognized by the BIOS... EXCEPT when I jumper it to 32GB max!!... then it sees the drive, the model, the size, but does not recognize a logical drive (as if it was not formatted -- which it was [NTFS] -- the term it uses is "unallocated"). This just happened, and it's not my data, so I'm a bit desparate to understand what has happend to know how to proceed with recovery.

So... my basic question is this: Has anyone experienced jumper settings causing corruption to a drive, especially when a CD-ROM drive is involved?

If so, why does this happen? And why can the drive be seen in 32GB mode while it can't with normal jumpering? I've searched to try and find out EXACTLY what happens across the interface when the BIOS detects a drive... any help there as well?

Thanks for any help anyone can give me.
 
older machines with older bios usually dont recognize any drive over 32 GB. did this bios EVER recognize the drive as larger? if you gave us more info on the spec's of your machine it would help.
 
Thanks for the reply.

Yes, this drive has been on the machine in question for a few years with no problems. So shouldn't be machine-related... but here's more info:

File System = NTFS

OS = NT4

Disk = IBM Deskstar 46GB production date March 2001 (I know it has a high failure rate, but nowhere I've found does it explain WHAT the common failures look like). This was the second drive on the system, not the boot drive.

Partitions = One, to the full 46GB

System = Pentium II 400

The drive worked on this system up to the end...

I replaced the guts of the PC with a new AMD 64 3000+ on an Abit AN8 Ultra. I moved the drive both physically and to a different logical position -- on the second IDE channel instead of the first. That's when the trouble began. That's when I failed to re-set the jumpers (or whatever I did to cause this). I was loading Win2k and it got to a point where you choose which drive to use to put the OS on... and I noticed that this disk was reported as having no file system or it was corrupted. Uh oh!

So when the new mobo and CPU began to blue screen during Win2K installation, and I rebooted and saw the same 'no file system' message, I took the drive out. I then took the system (and the removed HD) to the computer shop where I bought the components, and while they were looking at the mobo problem, they agreed to put my questionable drive on their system (WinXP) and see what they could. It showed no file structure or logical dives present. Not detected by the BIOS.

So two *other* systems reported the problem, one Win2k (install) and one WinXP.

So I took the HD home and put it BACK on the original MoBo to see if it would respond to that. It would not show up during BIOS detection, so I moved the jumpers to 32GB limiting mode... and lo and behold it was detected by BIOS!

I just ran the very first part of TestDisk with the jumpers set this way, and it reported the drive size as 32GB, but also gave a report of "bad relative sector", which maybe makes sense if it is reading the partition table as 46GB and the HD geometry as 32GB.

But I don't get why it wouldn't recognize the disk when in the normal Master setting if it is seen in the 32GB mode. I just don't know enough about exactly what happens *in the hard drive* during the BIOS detection step. Can anyone shed some more light on this?

Is it possible that by coincidence 1) Win2K and XP can't read the drive but 2) the drive is actually OK but the BIOS on the PII mobo got reset somehow and is now back to detecting only up to 32gb?? How could that happen? Doesn't sound likely to me.

Thanks for any help.
 
Never heard of a master/slave or miscabling causing any damage do any disk.

Most likely you messing around with the drives gave the DeathStar the final blow (literally).

Run the IBM drive fitness test on the thing. And upgrade the firmware if you haven't done so.
 
Thanks, I'll try that. Although the thing I DON'T want to do is write to it. It hasn't been written to since the problem showed up, and I want to recover the data.

I just ran TestDisk on it (in 32gb mode, obviously), and although it scanned for partitions without any apparent problem (no noises), it didn't find any. Not looking good. Well, its initial report before scanning was "1 E Extended" and "5 L HPFS FT mirror - V/S set" and "bad relative sector", then you're given the option to scan, which it did with nothing found.

The problem with this is that it was formatted NTFS, not HPFS. Weird. I read that previous file systems can show up like this... the drive may have been used by a business before being reformated and installed (I don't know; it's not my PC), but was HPFS (O/S-2) being used much anymore in 2001 when the drive was built? Business applications maybe? I'm trying to figure out if it's corruption or an overwrite condition.

Anyone got a guess as to what makes sense here? What to do next??
 
NTFS and HPFS have identical partition ID codes and for a simple partitions utility it is impossible to tell the difference. The "bad relative sector" message is because the end of your NTFS partition is marked beyond 32GB (which is the current size of the drive) and thus impossible.
 
OK. Now it's making sense. Thank you!!

Where is this 'end-of-partion' mark on the platters??? At the beginning or the end? When trying to be detected, does the drive have to search the platters all the way to the end to find some kind of "end of partition" marking?? If so, then that could be the problem when jumpered 'correctly' -- the real end of partition marking can't be read for some reason, but the "forced" EOP mark allows detection.

Just to confirm then, would that cause the BIOS to hang forever rather than eventually move on to detect the next drive?

More important, could the partition actually BE HPFS?? I mean, would NT4 be able to use this file system as if it were NTFS?? I ask because I was looking at a chart of file system identifiers and noticed that the two systems' IDs were one bit different from each other -- but not actually identical per se. So why wouldn't this utility, which is able to report either HPFS or NTFS, report it correctly? I could agree if the utility had only the ability to see and/or report FAT, FAT32, or NTFS... but it can recognize and report all the ID codes.

I'm trying to determine if we have corruption on the platters or a stuck interface bit here.

TIA
 
Unfortunately that cannot be easily determined since all partitioning utilities each do it a little bit differently.
Best bet DLoad a Knoppix iso and burn it to CD. It will be bootable without writing to that drive.
Seeif you can read the data on that drive if so burn it to CD then use a disk utility to wipe that drive partition and start over.

patio. :cool:..
 
All info about (primary and extended) partitions is kept on the first track of the hard drive. You get the error from TestDisk because it gets confused by the partition being described bigger as the whole disk.

Hard drive detection has nothing to do with the contents of the drives. Whatever is on your drive comes to play when you start booting from somewhere. If your BIOS really hangs while detecting drives then your problems are deeper than plain hard drive contents corruption.

HPFS and NTFS type identificators are the same - 07.. Where did you get the info that they were not? http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
 
Nodsu, you are right. I was looking at C7 and 87 because of the info TestDisk had given.

Is it possible that the two file systems are actually identical???

The info you gave me was one of the things I was looking for. OK, so the hanging is probably a drive-interface-board problem (normal jumpering is doing God-knows-what to the interface), or else I screwed up the original system so it doesn't recognize drives beyond the 32GB barrier. I would bet that if I could get it to recognize the drive, I could somehow retrieve the data (damaged partition info or not). Isn't there a second copy of the partition table in NTFS? Should I try to find it with the TestDisk utility? Or is there a better way?

Patio, is there something similar to Knoppix but not Linux-based? I have no experience with Linux. Also, I want to retrieve the data on the disk, not start over.

Thanks to you both. I'll try a few more things based on this info, and report back.
 
The nice thing about Knoppix is it runs "live" from a CD nd doesn't need to install anything to your system...
Ultimate BootCD would be another choice but be careful there are some powerful utilities on there...

patio. :cool:
 
One of the biggest dangers of using HPFS is that if the Super Block is lost or corrupted due to a bad sector, so are the contents of the partition, even if the rest of the drive is fine. It would be possible to recover the data on the drive by copying everything to another drive with a good sector 16 and rebuilding the Super Block. However, this is a very complex task.MSDN blurb
is this like ntfs?? doesn't look like it there's more on this type of file system at msdn
 
Does NTFS have a Super Block? If so, does it suffer the same problem (I suppose it would)?

The drive was formatted and installed by someone else whom I don't know, for my friend... so i don't know exactly how it was formatted. It always showed as an NTFS drive when viewing in NT4.

Does the Knoppix CD allow me to view the contents of the drive without any partition being recognized?
 
I used a utility to directly view the contents of the drive, and copied over whatever would fit on a floppy just to see what was there, if anything. Here are the contents of the partition tables (starting at 01BE):


01B0: 00 00 00 00 00 00 00 00 B0 AC 15 D8 00 00 00 00
01C0: 01 01 05 3F E0 FF 00 08 00 00 00 50 5E 05 00 00
01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

So it shows only one partition on the disk (true), as follows:
00 00 01 01 05 3F E0 FF 00 08 00 00 00 50 5E 05

Not bootable (true)
Starting head etc. (don't know)
File system = 05 = Extended partition (should be 07 NTFS??)


Help me, please. I've seen how a logical partition resides "in" an extended partiotion, but I've also seen that extended partitions are needed only when creating more than 4 partitions, meaning that an extended partition is not needed here... so what is true?? This machine had one FAT16 partition on the C: drive (physically a different drive), then one NTFS partition on this drive, then one NTFS partition on another physically different 120GB drive. Thats 3 partitions no matter how you look at it.

Is the 05 a corruption of the NTFS 07 flag (one bit zeroed)? Or should it be an "05"?

But if it is supposed to be an extended partition, then where do I find the logical partition table for the 46GB NTFS partition?

Thanks.
 
You can partition a disk to contain nothing but an extended partition afaik. It's no problem. You could try the Ranish Partition Manager - it lets you change and view the partitons in realtime.

NTFS does not have a super block. Also, the file tables are duplicated, so no single block failure can destroy filesystem metadata.
 
"You can partition a disk to contain nothing but an extended partition afaik."

...but then how would anything know what the file system is for that partition? (To my knowledge the file system is indicated in that byte that is now 05 - extended partition. How would NT have known it was NTFS?)
 
Acoustic Jimmy said:
I've seen how a logical partition resides "in" an extended partiotion, but I've also seen that extended partitions are needed only when creating more than 4 partitions, meaning that an extended partition is not needed here... so what is true??
Some partitioning tools - particularly Win9x fdisk - insist that there can be only one primary partition, all after that must be logical partitions. So yes, extended are needed for more than four partitions, but they can be used with two to four partitions as well.

But you can't have an extended partition alone, you need a primary partition. That's why there's something wrong with the current partition layout. I agree with Nodsu, try with Ranish Partition Manager to change it to primary NTFS partition.

This machine had one FAT16 partition on the C: drive (physically a different drive), then one NTFS partition on this drive, then one NTFS partition on another physically different 120GB drive. Thats 3 partitions no matter how you look at it.
All on different drives. They don't share partition tables.
 
Yes, all on different drives... so I understand that the primary would be the C: drive and its table would be on the C: drive.

So if I can assume for the moment that Win9X Fdisk *was* used to partition all the drives, and that the D: drive here is therefore an extended drive, I still want to know how NTFS would be indicated on this D: drive when the file system indicator says only that it is an extended partition.

Thanks in advance.
 
OK... the mystery is finally solved. I'll explain in case anyone else runs into this...

Recall that I reassembled everything as it was before the drive has issues, yet the drive was not detected by the old motherboard (BIOS).

Nodsu, you put me on the right track with your info, and saying that if the drive could only be detected with the 32gb jumper, then my problems were deeper than drive contents. It indeed *couldn't* be detected unless the jumper was on 32 GB limiting on the old machine it had been in. But everything else about the drive seemed OK as I tested it more widely; it could read data fine, it had a partition table in the right place, it wasn't making any noises when it read... it only couldn't be detected without the 32GB jumper. Yet, the guy at the computer repair shop had said that it was detected on their machine as 46GB -- just no file system. Must be my BIOS.

What was confusing was that it had been displayed in the old machine as having its full 46GB of capacity. So I assumed that the BIOS had detected the full capacity (meaning that the 32 GB jumper was never on)... however most everything on the Internet pointed to a BIOS that couldn't detect drives above 32GB. So to be sure, I bought a new 40GB drive, and hooked it up. I got nothing -- no detection. So how could I possibly have seen the full 46GB from NT4?? Either the BIOS had 'broke' or something else was going on... so I looked up what the BIOS at my revision was capable of, and it seemed that it could NOT detect drives over 32GB. Hmmm. I couldn't fathom any way that the BIOS could have 'reverted' from being capable of detecting larger drives, so the BIOS wasn't broke -- and never was, apparently. But then how could it have detected the full 46GB on the drive?

The answer came from a post somewhere; a guy said that he was using a "disk overlay" that allowed the use of larger drives but needed the 32GB jumper in place...!! That clicked -- my experience was that the jumper HAD to be in place because the BIOS couldn't detect it otherwise, and now I could see how the full capacity was being shown in NT4... and furthermore, it might account for the weird partition table entries and other anomalies.

But if there was an overlay in the boot process, how come I couldn't get it to work when I put everything back like it was originally?

Apparently when I moved the drive to the new IDE channel, I had to rejumper it and didn't notice that it was 32GB limited -- I hadn't even considered it because the drive was showing as 46GB all the time. So I had moved the 32GB limit jumper to get it to "normal" Master mode.

It was after that point when the Win2000 installation program reported that the drive was unformatted or corrupted (-- because of the weird partition table caused by the overlay program). Same with the machine at the computer repair shop. When I reassembled everything back home and tried to reboot, the jumper was not on the 32gb limiting, so the BIOS hung.

In the end, I inferred that the jumpers should be 32GB, Slave... and prayed for an overlay program to kick in upon boot... and it must have loaded (I didn't see any message) because the drive is visible and working now. The guy who had installed the drive took the cheap way out, using an overlay program instead of upgrading the BIOS.

I'm relieved that I got my friend's 30+ GB of data back, but it was a hard lesson learned.

Thanks for all your help, everyone. It all helped. I hope this wasn't too long to read.

Any thoughts?
 
Another lesson learned :)

Your patience and will to study (and to share what you have learned) are commendable. It would be great to have you stay with us on these forums.
 
Thanks. I'll check back in as time permits and contribute as best I can. If I can help it will be a small payment for finding this fix. I was about ready to ship the drive out and pay $500 to have an expert reclaim the data!! Lol.
 
Nodsu, I may have spoken too quickly... I think that although the drive is being detected and read, perhaps the drive overlay is not installed anymore (remember that I said I didn't see any message as such). I get errors when reading some of the files on that drive ("...device error"), as if maybe the data under the 32GB limit is being read but the data "above" that limit is not. Also, I received a message from BIOS when I removed all disk drives from the system... something about resetting parameters I think... it came and went so fast I couldn't make out exactly what it was about.

My question is this:
How does a drive overlay work? I read that it apparently has to do with a CMOS patch, which would make it reversible. I need all the info I can get on the technical details. How does a CMOS patch work???

Thanks to anyone who can enlighten me.
 
A Disk overlay program installs itself in the bootsector of the hard drive (so it is always run) and registers itself in place of BIOS disk access calls. So when a program requests a disk operation using a BIOS function the request is processed by the disk overlay program instead.

This can be done because the BIOS functions (or interrupts as they are called) are loaded in a table in system RAM. The table basically lists the entry points of the interrupt routines in system memory - replacing the entry point with something in your own program is trivial.
 
OK, but the BIOS does its detection pre-OS-boot. And you had said that the disk is not read during the detection phase (I think you said that the contents of the disk were not involved).

So how can the info in the bootsector allow the drive to be detected, when it isn't read until after the drive is detected?
 
Overlays cannot help with drive detection. That's why you have to set the drive size to 32GB when you use the overlay program - the BIOS still needs to find the drive (no matter the size is wrong) and try to boot from it in order for the overlay program to get loaded. Once the overlay kicks in it no longer matters what the BIOS thinks about the drive.
 
Status
Not open for further replies.
Back