Motherboard killing my Hard Drives

  • Thread starter Thread starter Searcher7
  • Start date Start date
S

Searcher7

Over the last several days I lost the ability to boot from three hard drives. When one went down I plugged in another only to have it follow suit.

The following is the screen I get when I power on the PC.

http://i290.photobucket.com/albums/ll257/Statenislander/Computer/DriveProblem_zps181ee5ed.jpg

Obviously there is an issue with the motherboard because one can only give coincidence so much credit.

Each time it's happened was on "power up" after a previously successful "power off". So it wasn't as if the PC crashed beforehand or exhibited any unusual behavior to signify that the next boot up attempt would fail.

Can anyone tell me what the possible problems is and a solution so this system doesn't do the same to the fourth drive I just plugged in?

Thanks.

Darren Harris
Staten Island, New York.
 
Over the last several days I lost the ability to boot from three hard drives. When one went down I plugged in another only to have it follow suit.

The following is the screen I get when I power on the PC.

http://i290.photobucket.com/albums/ll257/Statenislander/Computer/DriveProblem_zps181ee5ed.jpg

Obviously there is an issue with the motherboard because one can only give coincidence so much credit.

Each time it's happened was on "power up" after a previously successful "power off". So it wasn't as if the PC crashed beforehand or exhibited any unusual behavior to signify that the next boot up attempt would fail.

Can anyone tell me what the possible problems is and a solution so this system doesn't do the same to the fourth drive I just plugged in?

Simple--don't plug a fourth drive in!

Obviously the port on the motherboard is doing something evil to the
drives. I've had a laptop die that way, it only took frying one more
drive to get the point across.
 
Over the last several days I lost the ability to boot from three hard drives. When one went down I plugged in another only to have it follow suit.

The following is the screen I get when I power on the PC.

http://i290.photobucket.com/albums/ll257/Statenislander/Computer/DriveProblem_zps181ee5ed.jpg

Obviously there is an issue with the motherboard because one can only give coincidence so much credit.

Each time it's happened was on "power up" after a previously successful "power off". So it wasn't as if the PC crashed beforehand or exhibited any unusual behavior to signify that the next boot up attempt would fail.

Can anyone tell me what the possible problems is and a solution so this system doesn't do the same to the fourth drive I just plugged in?

Thanks.

Darren Harris
Staten Island, New York.

Well, don't run any more drives on that system,
until you figure it out :-)

*******

I would take the dead drive, to a computer known not to be
killing drives, and test it there.

To protect that computer against damage, I might insert
a PCI IDE card in it, install a driver for the PCI IDE
card, then connect the suspect drive to the PCI IDE card.
If the PCI IDE card is ruined, the motherboard is protected
and only the PCI IDE card needs to be changed out. So that's
a relatively conservative approach, to protecting the
known-good computer. I have several Promise TX2 cards for that.

Once the test computer is booted, you can use TestDisk to
examine the suspect drive as a data drive, and look for data on it.
Maybe it's just the MBR got deleted, and the partitions
are still present.

First, on the known-good test computer, you check at BIOS
level, whether the dead drive can be detected. Enter the BIOS,
look in the disk interface section, and see if the model
number of the drive is listed. That's a basic I/O test,
proving the drive is running internally, and it is able to
send an identity string on demand.

If there is no sign of the drive at all, either an I/O interface
went overvoltage, or +5V/+12V went overvoltage. Something
a bit more physical, low level, and catastrophic.

If the drive is detected, but no sane data can be detected.
perhaps the bad computer has malware which is deleting the MBR
or the partitions.

(I've used this one. It's not a beginner level tool, as the
interface requires interpretation. *Do not* immediately
say yes, to any attempts to write the disk. Press
control-C if you need to exit at any time. This tool can list
files in a partition, for a limited set of file systems.)

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

Partition Find and Mount: Download
(I haven't used this one, just bookmarked it.
I don't know anything about it.)

http://findandmount.com/download/

Those are examples of tools you can try, on your
known-good computer.

*******

If all you owned, was the bad computer, you could:

1) Install a new IDE PCI card. Connect unbroken drive to that.
This covers an I/O voltage problem. It would not
solve potential driver problems though. Or an out-of-spec
ATX supply.
2) Check ATX power supply voltages with a multimeter.
If no multimeter is available, go to the BIOS
hardware monitor ("Health") page, and examine
the measured voltages there. 3.3V, 5V, 12V should
be mentioned, and standards say there is a +/-5% tolerance
on voltage. If you need help with that, post the
voltages you see in the Health page, and I can
quote sections of the formfactors.org docs that cover
those rails.
3) To examine the disk drive controller board for damage,
it helps if the components are facing the outside.
For a few years now, they've rotated the controller board,
such that the components are hidden. On the older
drives, you can look for burned transient suppressors
near the power input point, as proof the power supply
has been "burning" the drives. Now that the controller
boards are upside-down, you have to take the controller
board off to do such a check, which sucks. Because of
this development, it's probably easier now to use your
multimeter, and just check the suspect power supply directly
with the meter. Before, you also had the option of
inspecting for burn marks on the hard drive controller
board.

HTH,
Paul
 
Hench said:
I second this. It's happened to me. Paul told you why in his post.

It's easier to understand the power supply case. But I wouldn't
discount a problem on I/O. It's just a question of making up a
plausible theory, that fits the interface type. I'm too lazy to
spend the day, making up some theories for it :-)

Paul
 
Paul said:
Well, don't run any more drives on that system,
until you figure it out :-)

*******

I would take the dead drive, to a computer known not to be
killing drives, and test it there.

To protect that computer against damage, I might insert
a PCI IDE card in it, install a driver for the PCI IDE
card, then connect the suspect drive to the PCI IDE card.


Not all IDE interfaces are the same - especially plug in ones.

I recently added an IDE expansion to a MOBO that didn't have any IDE
headers, it wouldn't recognise the drives I'd taken from the previous MOBO
without a re-format.

Pretty lucky I'd backed them up!
 
Mike Tomlinson said:
It's the power supply. Motherboards don't kill hard drives.


Making such a sweeping generalisation isn't too smart.

I've had actual experience of a ESD damaged MOBO trashing a CD-RW drive & a
HDD on the same header.

OTOH - I've recovered (and still using) a drive from a MOBO that had bulged
electrolytic capacitors caused by the PSU.
 
Ian said:
Not all IDE interfaces are the same - especially plug in ones.

I recently added an IDE expansion to a MOBO that didn't have any IDE
headers, it wouldn't recognise the drives I'd taken from the previous
MOBO without a re-format.

Pretty lucky I'd backed them up!

If the original controller was RAID capable, and the driver
writes metadata to suit itself, that can affect interoperability.

RAID controllers have three choices, for a JBOD disk.

1) Use no metadata for JBOD, only add metadata when the
user builds an array.
2) Put metadata up near the end of the disk, then trim down
the declared size of the disk, so the metadata cannot get
overwritten (for as long as the drive resides on the RAID
controller port at least).
3) Put metadata up near the beginning. [Insert your own recipe
as to how this is possible - offset all accesses by 64KB etc.]

I moved an IDE drive, from a Promise controller (378???) to
the Southbridge, and the first partition would disappear. I
suspect this had something to do with metadata, but at the time,
didn't investigate the details. The partition would reappear,
when the drive was put back on the original controller.

I have investigated on another RAID capable setup, and on that
one, about 5MB of space is reserved down near the end, and 64KB of
metadata is written somewhere in the middle of it. I zeroed
the entire drive beforehand, so I could find that 64KB chunk.
And inside the 64KB chunk, was sufficient room to describe
up to 16 RAID arrays. (Data pattern repeated every 4KB, suggesting
each 4KB block described one array.)

So RAID metadata might have had something to do with it.

Paul
 
Over the last several days I lost the ability to boot from three hard
drives. When one went down I plugged in another only to have it
follow suit.

The following is the screen I get when I power on the PC.

http://i290.photobucket.com/albums/ll257/Statenislander/Computer/DriveProblem_zps181ee5ed.jpg

I had the PXE-thingy (on T22) like so, I solved it (and never saw it again)
by doing a fresh install of XP, rather than the Backups i'd been using.
Obviously there is an issue with the motherboard because one can only
give coincidence so much credit.

Each time it's happened was on "power up" after a previously
successful "power off". So it wasn't as if the PC crashed beforehand
or exhibited any unusual behavior to signify that the next boot up
attempt would fail.

I didn't get exactly above but found that it would boot if it went via
Hirens-boot-CD.
 
Paul said:
Ian said:
Not all IDE interfaces are the same - especially plug in ones.

I recently added an IDE expansion to a MOBO that didn't have any IDE
headers, it wouldn't recognise the drives I'd taken from the previous
MOBO without a re-format.

Pretty lucky I'd backed them up!

If the original controller was RAID capable, and the driver
writes metadata to suit itself, that can affect interoperability.

RAID controllers have three choices, for a JBOD disk.

1) Use no metadata for JBOD, only add metadata when the
user builds an array.
2) Put metadata up near the end of the disk, then trim down
the declared size of the disk, so the metadata cannot get
overwritten (for as long as the drive resides on the RAID
controller port at least).
3) Put metadata up near the beginning. [Insert your own recipe
as to how this is possible - offset all accesses by 64KB etc.]

I moved an IDE drive, from a Promise controller (378???) to
the Southbridge, and the first partition would disappear. I
suspect this had something to do with metadata, but at the time,
didn't investigate the details. The partition would reappear,
when the drive was put back on the original controller.

I have investigated on another RAID capable setup, and on that
one, about 5MB of space is reserved down near the end, and 64KB of
metadata is written somewhere in the middle of it. I zeroed
the entire drive beforehand, so I could find that 64KB chunk.
And inside the 64KB chunk, was sufficient room to describe
up to 16 RAID arrays. (Data pattern repeated every 4KB, suggesting
each 4KB block described one array.)

So RAID metadata might have had something to do with it.

The previous MOBO wasn't RAID capable but the add on card I put in the MOBO
with no IDE header was.

An IDE + SATA RAID capable add in card I bought since then is compatible
with both IDE & SATA drives formatted on the old MOBO.
 
It's the power supply. Motherboards don't kill hard drives.

It happened to me with a *LAPTOP* hard drive in the IDE era--the power
comes along with the data from the motherboard. The board would post
to the point of saying it couldn't find the OS. Neither drive ever
worked again even when connected to another machine.
 
Ian Field <gangprobing. said:
Making such a sweeping generalisation isn't too smart.

I's the most likely cause, based on my 27 years experience of PC repair,
but thank you for your condescension.
 
Over the last several days I lost the ability to boot from three hard drives. When one went down I plugged in another only to have it follow suit.

The following is the screen I get when I power on the PC.

http://i290.photobucket.com/albums/ll257/Statenislander/Computer/DriveProblem_zps181ee5ed.jpg

Obviously there is an issue with the motherboard because one can only give coincidence so much credit.

Each time it's happened was on "power up" after a previously successful "power off". So it wasn't as if the PC crashed beforehand or exhibited any unusual behavior to signify that the next boot up attempt would fail.

Can anyone tell me what the possible problems is and a solution so this system doesn't do the same to the fourth drive I just plugged in?

Thanks.

Darren Harris
Staten Island, New York.

For some strange reason, you're trying to boot from the network, not
from internal disks..

I don't have a second computer, so I can't check how one disabled that
function in the BIOS


--
 
tumppiw said:
For some strange reason, you're trying to boot from the network, not
from internal disks..

I don't have a second computer, so I can't check how one disabled that
function in the BIOS

PXE boot code typically runs, if a disk cannot be found.

On a good BIOS, you can go into the hardware setup, and
disable the boot ROM for the NIC, and stop those messages
from appearing.

The "disk boot failure", means that none of the devices
in the boot order, were located.

Paul
 
Loren Pechtel said:
It happened to me with a *LAPTOP* hard drive in the IDE era--the power
comes along with the data from the motherboard. The board would post
to the point of saying it couldn't find the OS. Neither drive ever
worked again even when connected to another machine.

I had better luck with a Next brand computer I found in the bin room at the
flats.

It was a pedestal flat screen with a single PCB - including the PSU. The PSU
had obviously suffered a catastrophic failure - there were bulged
electrolytics both in the PSU section and distributed on the rest of the
board.

I'm still using the pair of 1Gb memory sticks and the 250Gb HDD, after I
harvested some of the useful SMDs I put the remains back where I found it.
 
If the original controller was RAID capable, and the driver
writes metadata to suit itself, that can affect interoperability.

RAID controllers have three choices, for a JBOD disk.

1) Use no metadata for JBOD, only add metadata when the
user builds an array.
2) Put metadata up near the end of the disk, then trim down
the declared size of the disk, so the metadata cannot get
overwritten (for as long as the drive resides on the RAID
controller port at least).
3) Put metadata up near the beginning. [Insert your own recipe
as to how this is possible - offset all accesses by 64KB etc.]

I moved an IDE drive, from a Promise controller (378???) to
the Southbridge, and the first partition would disappear. I
suspect this had something to do with metadata, but at the time,
didn't investigate the details. The partition would reappear,
when the drive was put back on the original controller.

Yup, I've had the same thing happen. I pulled a drive out of an old
box where it was half of a RAID array--oops, I couldn't read it. I
had to put some bits in and fire up the old box to pull the file I
wanted.
 
I'm still using the pair of 1Gb memory sticks and the 250Gb HDD, after I
harvested some of the useful SMDs I put the remains back where I found it.

Worked with a guy with government connections. One year he got all
the old computers from an updated county budget. Hundreds. Would
have filled the floor space to average 2-bedroom home, half way to the
ceiling. Walked in on them cold, wandered around, even popped a
couple;- but when he told me to take what I want, I turned and walked
away without even a second look over my shoulder. (They either go
through greening/recycling, maybe at cost, although the other option
is through the community - churches, schools, organizations and
various projects for placement with children and suitable homes.)

There's just one rule for dealing with people with computers. Most
anything goes as long as I continue to enjoy them;- drudgery for
computer work isn't especially high among my priorities. (Know too
many people who want to act like they enjoy a computer, say they find
interesting programs inspiring, while all they're looking for is a
handy fix for working computer somebody will do for free. They really
do detest having to think through anything with a logical
proposition.) Reason why I repeatedly turned down opportunities with
IT.
 
Yup, I've had the same thing happen.  I pulled a drive out of an old
box where it was half of a RAID array--oops, I couldn't read it.  I
had to put some bits in and fire up the old box to pull the file I
wanted.

My suggestion on raid is to use the built in Windows 7 or Linux, OS
based raid, whenever possible.

Since the OS handles the raid, it means that if your machine crashes,
you can just pull the drive and put it into another box, and it will
be read like any other drive, with very little work. As long as you
stick with the same OS, or even an upgraded version of that OS, you
are good to go.

This is a lot better situation than a hardware raid, where you almost
always need compatible hardware to read the raid drives. And sometimes
compatible hardware is tough to find, as hardware companies are
upgrading their raid hardware on a yearly basis.
 
Since the OS handles the raid, it means that if your machine crashes,
you can just pull the drive and put it into another box, and it will
be read like any other drive, with very little work. As long as you
stick with the same OS, or even an upgraded version of that OS, you
are good to go.

This is a lot better situation than a hardware raid, where you almost
always need compatible hardware to read the raid drives. And sometimes
compatible hardware is tough to find, as hardware companies are
upgrading their raid hardware on a yearly basis.

Yup. The only reason I would use hardware raid is when the controller
actually implements it all in hardware. Software raid has the nasty
habit of faulting on a BSOD. This box is doggy for quite some time
after a BSOD while Windows rebuilds two Raid 1s.
 
Back
Top