Is my drive dead?

Hi,

I've had a strange problem for a while, with Windows resetting
occasionally without warning. Most of the time it works fine. I ran
chkdsk /4, and got stuck at 11% of stage 4. It does the same if I boot
from my spare hard drive, so I guess it can't be a software problem.
The seagate diagnostic tools (run from a boot CD) hang as soon as they
start the quick or the full disc check.

Seems fairly clear there's a hardware problem. Before I get a
replacement drive... is there a way to check that it is the drive at
fault and not the controller/motherboard? Some more sophisticated
diagnostic software, perhaps?

(Ideally I'd test the drive in another PC, but I don't really have
access to one.)

The drive is a SATA Barracuda 7200.8 and the motherboard Asus A8V.

thank you for your time!

Probably not.

zzzzara@my-deja.com wrote

> I've had a strange problem for a while, with Windows resetting
> occasionally without warning. Most of the time it works fine.

You dont normally get that with a bad hard drive.

> I ran chkdsk /4, and got stuck at 11% of stage 4.
> It does the same if I boot from my spare hard drive,
> so I guess it can't be a software problem.

Yes, but its also unlikely to be a bad hard drive too.

> The seagate diagnostic tools (run from a boot CD) hang
> as soon as they start the quick or the full disc check.

> Seems fairly clear there's a hardware problem.

Yes.

> Before I get a replacement drive...

Its unlikely to be a bad hard drive if you get the
same problem with two different hard drives.

> is there a way to check that it is the drive at fault
> and not the controller/motherboard? Some more
> sophisticated diagnostic software, perhaps?

Yes, check the event log and see what Win says about
why you are getting reboots if you are running 2K or XP.

> (Ideally I'd test the drive in another PC,
> but I don't really have access to one.)

OK, post the Everest SMART data for the drives.
http://www.majorgeeks.com/download.php?det=4181

> The drive is a SATA Barracuda 7200.8 and the motherboard Asus A8V.

zzzzara@my-deja.com wrote:
> Hi,
>
> I've had a strange problem for a while, with Windows resetting
> occasionally without warning. Most of the time it works fine. I ran
> chkdsk /4, and got stuck at 11% of stage 4. It does the same if I boot
> from my spare hard drive, so I guess it can't be a software problem.
> The seagate diagnostic tools (run from a boot CD) hang as soon as they
> start the quick or the full disc check.
>
> Seems fairly clear there's a hardware problem. Before I get a
> replacement drive... is there a way to check that it is the drive at
> fault and not the controller/motherboard? Some more sophisticated
> diagnostic software, perhaps?
>
> (Ideally I'd test the drive in another PC, but I don't really have
> access to one.)
>
> The drive is a SATA Barracuda 7200.8 and the motherboard Asus A8V.
>
> thank you for your time!

I'm thinking most likely jumper settings are at fault. Somethimes wrong
jumper settings like having 2 masters actually kinda sorta tries to
work, instead of the more usual: "you have dirves on this cable?
Really?".

Check to make sure everything is Kosher, as far as jumper settings go.
Master on the end of the cable, slave on the middle. If you use cable
select, it's all devices on the cable, or none of them.

Another posiblilty is bad cables themselves, though it's rare. Double
and triple check to see that everything is properly seated. Yet another
is bad ide controller. It's also possible to have TWO bad drives. Alas.

Since you've got the case open, check your motherboard for bad
capacitors (little soda cans), if any are bulging or leaking, they're
bad.

And blow out the dust, it's probably not your problem, but it's a
routine maintanence thing to be done anyway.

Download and run memtest86+ from www.memtest.org to check RAM.

A very powerful diagnostic is MHDD, use it as a boot CD. Ignore
anvanced features, just hit f4 twice to run a scan.

http://hddguru.com/content/en/software/2005.10.02-MHDD/

paulmd@efn.org wrote
> zzzzara@my-deja.com wrote

>> I've had a strange problem for a while, with Windows resetting
>> occasionally without warning. Most of the time it works fine. I ran
>> chkdsk /4, and got stuck at 11% of stage 4. It does the same if I
>> boot from my spare hard drive, so I guess it can't be a software
>> problem. The seagate diagnostic tools (run from a boot CD) hang as
>> soon as they start the quick or the full disc check.

>> Seems fairly clear there's a hardware problem. Before I get a
>> replacement drive... is there a way to check that it is the drive at
>> fault and not the controller/motherboard? Some more sophisticated
>> diagnostic software, perhaps?

>> (Ideally I'd test the drive in another PC, but I don't really have
>> access to one.)

>> The drive is a SATA Barracuda 7200.8 and the motherboard Asus A8V.


> I'm thinking most likely jumper settings are at fault.

Doesnt produce the symptom seen.

> Somethimes wrong jumper settings like having
> 2 masters actually kinda sorta tries to work,

Yes, plenty of drives work fine with bad jumpering.

> instead of the more usual: "you have dirves on this cable? Really?".

> Check to make sure everything is Kosher, as far as jumper
> settings go. Master on the end of the cable, slave on the middle.

That wont produce that symptom either if its not done like that.

> If you use cable select, it's all devices on the cable, or none of them.

Ditto.

> Another posiblilty is bad cables themselves, though it's rare.

Very rare indeed for that to produce spontaneous reboots.

The diag freezing in spades.

> Double and triple check to see that everything is
> properly seated. Yet another is bad ide controller.
> It's also possible to have TWO bad drives. Alas.

A bad drive wont produce spontaneous reboots, or the diag freezing,
and its very unlikely indeed to have two drives producing that effect.

> Since you've got the case open, check your motherboard for bad
> capacitors (little soda cans), if any are bulging or leaking, they're bad.

> And blow out the dust, it's probably not your problem,

Certainly not with the diag freezing.

> but it's a routine maintanence thing to be done anyway.

> Download and run memtest86+ from www.memtest.org to check RAM.

> A very powerful diagnostic is MHDD, use it as a boot CD.
> Ignore anvanced features, just hit f4 twice to run a scan.

> http://hddguru.com/content/en/software/2005.10.02-MHDD/

Currently my top theories are bad caps, jumpers, bad RAM, and bad IDE
controller. But ALL possibilties need to be checked and eliminated
before a diagnosis is made. Bad or Wrong cable is also on the list.

Little hardware problems that you don't think are the issue, often are.
They need to be addressed, and eliminated. At a minimum, They interfere
with a proper diagnosis, and they need to be fixed anyway, so no reason
not to fix them. And, well the other issues caused by them go away, so
all around a better way of doing things.

Dust, and associated heat issues, for example may cause an occasional
freeze, and random reset. So do bad caps and bad ram. Start by fixing
problem 1, and continue on until all the issues are fixed. Every fan
works, and every last thing is configured to spec. That way there
aren't lingering doubts.

As for why is the diagnostic hangin? Seatools says, right while it's
loading that certian types of hard drive problems may cause a hang (for
several minutes). And please be patient. It will continue eventually.
It disables the mouse during tests, too.

There is one last thing to try, which is a bios upgrade. Bios upgrades
often address hardware incompatibilties. But all other possibilities
need to be eliminated first.

paulmd@efn.org wrote:

> Currently my top theories are bad caps,

Yes, that can produce the symptoms he is seeing.

> jumpers,

Doesnt produce the symptoms he is seeing.

> bad RAM,

Unlikely to have just started to produce those symptoms.

> and bad IDE controller.

Doesnt produce that reboot effect.

> But ALL possibilties need to be checked
> and eliminated before a diagnosis is made.

Effective debugging is done by concentrating on the possibilitys
that can produce the symptoms seen, not wasting time on
possibilitys that dont produce the symptoms seen.

> Bad or Wrong cable is also on the list.

Nope, that wont produce the reboot effect either.

> Little hardware problems that you don't think are the issue, often are.

Only if you dont actually have a clue about
what can produce particular symptoms.

> They need to be addressed, and eliminated.

Not when the actual fault is elsewhere.

> At a minimum, They interfere with a proper diagnosis,

No they dont with symptoms like those seen.

> and they need to be fixed anyway, so no reason not to fix them.

Waste of time considering them until the fault is
found and you decide if the repair is economic.

If for example it is a bad motherboard, the owner may well
just prefer to buy a new system and move the drive contents
to the new system, and may not even want to have the old
drive in the new system, so minor config problems are irrelevant.

> And, well the other issues caused by them go away,
> so all around a better way of doing things.

Nope, particularly when its quite likely that the motherboard
is bad and that the owner will choose to buy a new system.

> Dust, and associated heat issues, for example may
> cause an occasional freeze, and random reset.

Not with the seagate diag.

> So do bad caps

Yes, but if those are bad, there isnt any point in mindlessly
cleaning out the dust, swapping the cables, etc etc etc, if
the owner is likely to buy a new system if it does have bad caps.

> and bad ram.

Ram doesnt usually go bad.

> Start by fixing problem 1, and continue on until all the issues are fixed.

Makes a lot more sense to first decide if the caps are bad
and dont bother with anything else if the owner decides to
buy a new system because the caps are bad and that its
a good reason to upgrade to a new system now.

> Every fan works, and every last thing is configured
> to spec. That way there aren't lingering doubts.

Stupidly inefficient way to diagnose a fault like that one.

> As for why is the diagnostic hangin? Seatools says, right while
> it's loading that certian types of hard drive problems may cause
> a hang (for several minutes). And please be patient. It will
> continue eventually. It disables the mouse during tests, too.

So the OP is likely to have seen that and waited long enough.

Much more likely that there is a serious hardware
problem like bad caps or a flakey power supply.

> There is one last thing to try, which is a bios upgrade.
> Bios upgrades often address hardware incompatibilties.

They dont just show up after the system has been working fine.

> But all other possibilities need to be eliminated first.

Wrong again. It can be the best thing to try if there is some
obvious hardware incompat. No need to clean the dust out first.

Rod Speed wrote:
> paulmd@efn.org wrote:
>
> > Currently my top theories are bad caps,
>
> Yes, that can produce the symptoms he is seeing.
>
> > jumpers,
>
> Doesnt produce the symptoms he is seeing.
>
> > bad RAM,
>
> Unlikely to have just started to produce those symptoms.

I must disagree. But in any case, it needs to be tested.
>
> > and bad IDE controller.
>
> Doesnt produce that reboot effect.
>
> > But ALL possibilties need to be checked
> > and eliminated before a diagnosis is made.
>
> Effective debugging is done by concentrating on the possibilitys
> that can produce the symptoms seen, not wasting time on
> possibilitys that dont produce the symptoms seen.

But leaving problems is bad form, and, they ARE problems.
>
> > Bad or Wrong cable is also on the list.
>
> Nope, that wont produce the reboot effect either.
>
> > Little hardware problems that you don't think are the issue, often are.
>
> Only if you dont actually have a clue about
> what can produce particular symptoms.

No, whether or not you think they can produce symptoms. What one
computer may be fine with, another may choke on. For example, some
newish dells actually require the cable select position, and just
aren't happy with master/slave.

>
> > They need to be addressed, and eliminated.
>
> Not when the actual fault is elsewhere.
>
> > At a minimum, They interfere with a proper diagnosis,
>
> No they dont with symptoms like those seen.
>
> > and they need to be fixed anyway, so no reason not to fix them.
>
> Waste of time considering them until the fault is
> found and you decide if the repair is economic.
>
> If for example it is a bad motherboard, the owner may well
> just prefer to buy a new system and move the drive contents
> to the new system, and may not even want to have the old
> drive in the new system, so minor config problems are irrelevant.

Lets say he gets a new board, and plops it into his old case,
misconfiguartions and all. The old problems resurface, lazarus-like. Or
a strange new set. All due to the stuff you dismissed as irrelivant.



>
> > And, well the other issues caused by them go away,
> > so all around a better way of doing things.
>
> Nope, particularly when its quite likely that the motherboard
> is bad and that the owner will choose to buy a new system.
>
> > Dust, and associated heat issues, for example may
> > cause an occasional freeze, and random reset.
>
> Not with the seagate diag.

Sure they can. With *any* program, windows, linux, dos or otherwise. If
the hardware is faulty, the symptoms will always be the same. No
progarm is immune to basic stuff like that.


>
> > So do bad caps
>
> Yes, but if those are bad, there isnt any point in mindlessly
> cleaning out the dust, swapping the cables, etc etc etc, if
> the owner is likely to buy a new system if it does have bad caps.
>

Of course not, but cleaning out the dust first makes bad caps easier to
see. And if the caps are so bad, that you can see right away before you
turn on the compresser..... you can of course stop there. And ask the
user what they want to do.

> > and bad ram.
>
> Ram doesnt usually go bad.

I've seen enough Bad ram to entirely disagree. It's real common.

>
> > Start by fixing problem 1, and continue on until all the issues are fixed.
>
> Makes a lot more sense to first decide if the caps are bad
> and dont bother with anything else if the owner decides to
> buy a new system because the caps are bad and that its
> a good reason to upgrade to a new system now.
>
> > Every fan works, and every last thing is configured
> > to spec. That way there aren't lingering doubts.
>
> Stupidly inefficient way to diagnose a fault like that one.

Thorough.
>
> > As for why is the diagnostic hangin? Seatools says, right while
> > it's loading that certian types of hard drive problems may cause
> > a hang (for several minutes). And please be patient. It will
> > continue eventually. It disables the mouse during tests, too.
>
> So the OP is likely to have seen that and waited long enough.

He didn't say so, therefore we can't assume.
>
> Much more likely that there is a serious hardware
> problem like bad caps or a flakey power supply.
>
> > There is one last thing to try, which is a bios upgrade.
> > Bios upgrades often address hardware incompatibilties.
>
> They dont just show up after the system has been working fine.

They can if new hardware is added to the mix we haven't been told
about.
>
> > But all other possibilities need to be eliminated first.
>
> Wrong again. It can be the best thing to try if there is some
> obvious hardware incompat.

Most hardware incompatibilites aren't obvious, and the changelogs on
bioses are often very vauge. Sometimes nonexistant. I normally do bios
upgrades anyway, at least on some of the better systems, like Dell,
where it can be done with mimimal time and risk, and a high degree of
certianty you got the right bios. Some boards I avoid bios upgrades on,
like Pcchips, as they aren't very good about listing all of their
boards, and you can get the wrong bios too easily.

> No need to clean the dust out first.

Yes there is, I always do just so my hands don't get icky. And it aids
with visual inspection. And it may just fix a heat problem.

My usual routine goes, open up the case, take an air compressor to it
if it needs it. Then look at the caps. If bad: issue identified. Ask
whether user wants a new motherboard or a new system.

If caps appear good, then continue on to the rest of the system: do
drives have the correct cables and jumper settings? If no, rearrange to
proper config.

Then power it up, do all the fans run? At least PSU fan, CPU fan, and
Northbridge and video card fan? These are sources of instability.
Failures of these key fans must be addressed to prevent further damage
to system. Case fans can be dealt with later. But they need to be dealt
with. Evenually.

Boot it up, to see it it's any obvious virus or windows problem.

Then sic diagnostic software on it: if it comes with a utility
partition with diagnostics, run it on the most thorough settings. (fix
other computers in meantime), check for heat issues whilst running
every so often.

If no onboard diagnostic partition, or only a limited set, the old
standbys of memtest will do, and I've come to really like MHDD (thanks
to Alan for pointing it out).

There are variations to this basic pattern, of course. Depending on
user complaints of symptoms. But I always do the basic visual
inspection, as very often the user has problems they didn't tell you
about. They usually tell you about the 1 or 2 most annoying. They
figure they can live with the rest, or figure they don't want to scare
you off with a giant laundry list. (I've seen giant laundry lists from
time to time, though :) )

paulmd@efn.org wrote
> Rod Speed wrote
>> paulmd@efn.org wrote

>>> Currently my top theories are bad caps,

>> Yes, that can produce the symptoms he is seeing.

>>> jumpers,

>> Doesnt produce the symptoms he is seeing.

>>> bad RAM,

>> Unlikely to have just started to produce those symptoms.

> I must disagree.

Your problem.

> But in any case, it needs to be tested.

Nope, not until the more likely possibilitys like bad caps are
checked for first, particularly as its one of the slower checks.

>>> and bad IDE controller.

>> Doesnt produce that reboot effect.

>>> But ALL possibilties need to be checked
>>> and eliminated before a diagnosis is made.

>> Effective debugging is done by concentrating on the possibilitys
>> that can produce the symptoms seen, not wasting time on
>> possibilitys that dont produce the symptoms seen.

> But leaving problems is bad form,

Not when the system is about to be discarded
because the motherboard caps have gone bad
and the owner has chosen to buy a new system.

Anyone with a clue just moves the data from the
system with a fault to the new system and discards
the system which has that serious a fault.

> and, they ARE problems.

You aint established that that system actually has any other problem.

>>> Bad or Wrong cable is also on the list.

>> Nope, that wont produce the reboot effect either.

>>> Little hardware problems that you don't think are the issue, often are.

>> Only if you dont actually have a clue about
>> what can produce particular symptoms.

> No,

Fraid so.

> whether or not you think they can produce symptoms.

I KNOW that a bad cable and incorrect jumpering
cant produce that reboot effect the OP is seeing.

> What one computer may be fine with, another may choke on.

Mindless waffle with that particular symptom.

> For example, some newish dells actually require the cable
> select position, and just aren't happy with master/slave.

STILL doesnt produce that REBOOT EFFECT, and
that wont produce a fault that shows up later either.

>>> They need to be addressed, and eliminated.

>> Not when the actual fault is elsewhere.

>>> At a minimum, They interfere with a proper diagnosis,

>> No they dont with symptoms like those seen.

>>> and they need to be fixed anyway, so no reason not to fix them.

>> Waste of time considering them until the fault is
>> found and you decide if the repair is economic.

>> If for example it is a bad motherboard, the owner may well
>> just prefer to buy a new system and move the drive contents
>> to the new system, and may not even want to have the old
>> drive in the new system, so minor config problems are irrelevant.

> Lets say he gets a new board, and plops it
> into his old case, misconfiguartions and all.

Not even worth considering UNTIL he
has decided to replace the motherboard.

> The old problems resurface, lazarus-like.

Wont happen if bad caps can be seen on the original motherboard.

> Or a strange new set. All due to
> the stuff you dismissed as irrelivant.

I didnt do that, I JUST SAID THAT THEY WONT
PRODUCE THE SYMPTOMS HE IS SEEING.

>>> And, well the other issues caused by them go away,
>>> so all around a better way of doing things.

>> Nope, particularly when its quite likely that the motherboard
>> is bad and that the owner will choose to buy a new system.

>>> Dust, and associated heat issues, for example may
>>> cause an occasional freeze, and random reset.

>> Not with the seagate diag.

> Sure they can.

Nope.

> With *any* program, windows, linux, dos or otherwise.

Wrong with stuff that makes few demands of the cpu.

> If the hardware is faulty, the symptoms will always be
> the same. No progarm is immune to basic stuff like that.

If there is JUST a bad cable, any decent diag wont just lock up.

>>> So do bad caps

>> Yes, but if those are bad, there isnt any point in mindlessly
>> cleaning out the dust, swapping the cables, etc etc etc, if the
>> owner is likely to buy a new system if it does have bad caps.

> Of course not, but cleaning out the dust
> first makes bad caps easier to see.

Bullshit. You dont get much dust accumulating on the tops of the caps.

> And if the caps are so bad, that you can see right away before
> you turn on the compresser..... you can of course stop there.

With the symptoms seen, no point in bothering with any
compressor, the only thing that makes any sense at all
is to check for bad caps and if there bad caps, ask the
owner what they want to do about that, because there
is no point what so ever in checking anything at all if
they just want to buy a new system and have the data
moved over from the old system.

> And ask the user what they want to do.

>>> and bad ram.

>> Ram doesnt usually go bad.

> I've seen enough Bad ram to entirely disagree. It's real common.

Pigs arse it is.

>>> Start by fixing problem 1, and continue on until all the issues are fixed.

>> Makes a lot more sense to first decide if the caps are bad
>> and dont bother with anything else if the owner decides to
>> buy a new system because the caps are bad and that its
>> a good reason to upgrade to a new system now.

>>> Every fan works, and every last thing is configured
>>> to spec. That way there aren't lingering doubts.

>> Stupidly inefficient way to diagnose a fault like that one.

> Thorough.

Stupidly inefficient and a complete waste of time when
the owner will normally decide to buy a new system
with a fault like that thats uneconomic to repair.

>>> As for why is the diagnostic hangin? Seatools says, right while
>>> it's loading that certian types of hard drive problems may cause
>>> a hang (for several minutes). And please be patient. It will
>>> continue eventually. It disables the mouse during tests, too.

>> So the OP is likely to have seen that and waited long enough.

> He didn't say so, therefore we can't assume.

Corse you can if you actually have a clue about efficient debugging.

Only when there is no obvious problem like bad
caps does it make any sense to actually try running
it yourself to see if the owner got confused there.

AFTER you have checked the event log to see
if that has any useful information on the reboots.

Essentially because its very unlikely indeed to be a
bad hard drive when the OP got the same systems
with two different hard drives, so the hard drive diag
is WAY down the list of what is worth trying if you
havent identified where the problem is.

>> Much more likely that there is a serious hardware
>> problem like bad caps or a flakey power supply.

>>> There is one last thing to try, which is a bios upgrade.
>>> Bios upgrades often address hardware incompatibilties.

>> They dont just show up after the system has been working fine.

> They can if new hardware is added
> to the mix we haven't been told about.

Its normally obvious enough if thats been added recently.

And if the caps look fine, it makes much more sense if the
event log doesnt show anything useful to see if the reboots
still happen with an absolute minimum of hardware than it
ever does to fart around checking jumpers and cables
which arent going to produce the symptoms seen.

Because if the reboots still happen with a bare minimum
of hardware, its very likely that the system will be discarded
so that other crap is likely to be a complete waste of time.

>>> But all other possibilities need to be eliminated first.

>> Wrong again. It can be the best thing to try
>> if there is some obvious hardware incompat.

> Most hardware incompatibilites aren't obvious,

Which is why anyone with a clue sees if the fault
remains with an absolute bare minimum of hardware.

> and the changelogs on bioses are often
> very vauge. Sometimes nonexistant.

Sure, but thats an separate issue to your silly claim that
all the other possibilitys need to be eliminated first.

Its usually pretty obvious what can be a bios problem.

> I normally do bios upgrades anyway, at least on some of the
> better systems, like Dell, where it can be done with mimimal
> time and risk, and a high degree of certianty you got the right
> bios. Some boards I avoid bios upgrades on, like Pcchips,
> as they aren't very good about listing all of their boards,
> and you can get the wrong bios too easily.

Sure, but thats an separate issue to your silly claim that
all the other possibilitys need to be eliminated first.

Its usually pretty obvious what can be a bios problem.

>> No need to clean the dust out first.

> Yes there is, I always do just so my hands don't get icky.

Your neurotic hangups are your problem.

> And it aids with visual inspection.

Dont need to do that BEFORE FLASHING THE BIOS.

> And it may just fix a heat problem.

Dont need to do that BEFORE FLASHING THE BIOS.

> My usual routine goes, open up the case, take an air compressor
> to it if it needs it. Then look at the caps. If bad: issue identified.
> Ask whether user wants a new motherboard or a new system.

Nothing like your original, you're flagrantly dishonestly slithering
off to somewhere completely different now after your nose has
been rubbed in the terminal stupidity of your original claims.

> If caps appear good, then continue on to the rest of the
> system: do drives have the correct cables and jumper settings?

Makes a hell of a lot more sense to check the event logs first in this case.

And to see what the minimal config does reboot wise
next if the event logs dont have anything useful in them.

And then try swapping the power supply next.

> If no, rearrange to proper config.

Waste of time with the symptoms seen.

> Then power it up, do all the fans run? At least PSU fan, CPU fan,
> and Northbridge and video card fan? These are sources of instability.

This stuff should be checked before the jumpers too.

> Failures of these key fans must be addressed to prevent
> further damage to system. Case fans can be dealt with
> later. But they need to be dealt with. Evenually.

Not necessarily, most obviously when they arent necessary.

> Boot it up, to see it it's any obvious virus or windows problem.

> Then sic diagnostic software on it: if it comes with a utility
> partition with diagnostics, run it on the most thorough settings.
> (fix other computers in meantime), check for heat issues
> whilst running every so often.

Makes a lot more sense to see if the
minimal config still exhibits the problem first.

> If no onboard diagnostic partition, or only a limited set,
> the old standbys of memtest will do, and I've come
> to really like MHDD (thanks to Alan for pointing it out).

It wont be a hard drive problem, because he gets
the same result with two different hard drives.

And its stupid having a mindless sequence regardless of the
fault seen, grossly inefficient way to diagnose systems.

> There are variations to this basic pattern, of course.
> Depending on user complaints of symptoms.

Stupid checking the jumpers first with the reported symptoms,
because they cant be the problem. Ribbon cable too.

> But I always do the basic visual inspection, as very
> often the user has problems they didn't tell you about.
> They usually tell you about the 1 or 2 most annoying.

Thats only worth doing AFTER the fault has been
fixed and is become clear that its economic to fix.

> They figure they can live with the rest, or figure they
> don't want to scare you off with a giant laundry list.
> (I've seen giant laundry lists from time to time, though :) )

Irrelevant to efficient fault finding.

On Tue, 22 Aug 2006 08:17:12 +1000, "Rod Speed" <rod.speed.aaa@gmail.com>
wrote:


>> and bad ram.
>
>Ram doesnt usually go bad.

That's probably the dumbest bloody thing you've uttered yet. But the night is
still young...

Rod Speed wrote:
> paulmd@efn.org wrote
> > Rod Speed wrote
> >> paulmd@efn.org wrote
>
> >>> Currently my top theories are bad caps,
>
> >> Yes, that can produce the symptoms he is seeing.
>
> >>> jumpers,
>
> >> Doesnt produce the symptoms he is seeing.
>
> >>> bad RAM,
>
> >> Unlikely to have just started to produce those symptoms.
>
> > I must disagree.
>
> Your problem.
>
> > But in any case, it needs to be tested.
>
> Nope, not until the more likely possibilitys like bad caps are
> checked for first, particularly as its one of the slower checks.

A complete check takes a long while indeed. But in over 90% of the
cases, if the ram is bad, it will be obvious within 5 minutes. Often
times, i do abort the test early.
>
> >>> and bad IDE controller.
>
> >> Doesnt produce that reboot effect.
>
> >>> But ALL possibilties need to be checked
> >>> and eliminated before a diagnosis is made.
>
> >> Effective debugging is done by concentrating on the possibilitys
> >> that can produce the symptoms seen, not wasting time on
> >> possibilitys that dont produce the symptoms seen.
>
> > But leaving problems is bad form,
>
> Not when the system is about to be discarded
> because the motherboard caps have gone bad
> and the owner has chosen to buy a new system.
>
> Anyone with a clue just moves the data from the
> system with a fault to the new system and discards
> the system which has that serious a fault.

Assumptions again.
>
> > and, they ARE problems.
>
> You aint established that that system actually has any other problem.

If I don't check, I never will. You see the problem?

>
> >>> Bad or Wrong cable is also on the list.
>
> >> Nope, that wont produce the reboot effect either.
>
> >>> Little hardware problems that you don't think are the issue, often are.
>
> >> Only if you dont actually have a clue about
> >> what can produce particular symptoms.
>
> > No,
>
> Fraid so.
>
> > whether or not you think they can produce symptoms.
>
> I KNOW that a bad cable and incorrect jumpering
> cant produce that reboot effect the OP is seeing.
>
> > What one computer may be fine with, another may choke on.
>
> Mindless waffle with that particular symptom.
>
> > For example, some newish dells actually require the cable
> > select position, and just aren't happy with master/slave.
>
> STILL doesnt produce that REBOOT EFFECT, and
> that wont produce a fault that shows up later either.
>
> >>> They need to be addressed, and eliminated.
>
> >> Not when the actual fault is elsewhere.
>
> >>> At a minimum, They interfere with a proper diagnosis,
>
> >> No they dont with symptoms like those seen.
>
> >>> and they need to be fixed anyway, so no reason not to fix them.
>
> >> Waste of time considering them until the fault is
> >> found and you decide if the repair is economic.
>
> >> If for example it is a bad motherboard, the owner may well
> >> just prefer to buy a new system and move the drive contents
> >> to the new system, and may not even want to have the old
> >> drive in the new system, so minor config problems are irrelevant.
>
> > Lets say he gets a new board, and plops it
> > into his old case, misconfiguartions and all.
>
> Not even worth considering UNTIL he
> has decided to replace the motherboard.
>
> > The old problems resurface, lazarus-like.
>
> Wont happen if bad caps can be seen on the original motherboard.
>
> > Or a strange new set. All due to
> > the stuff you dismissed as irrelivant.
>
> I didnt do that, I JUST SAID THAT THEY WONT
> PRODUCE THE SYMPTOMS HE IS SEEING.
>
> >>> And, well the other issues caused by them go away,
> >>> so all around a better way of doing things.
>
> >> Nope, particularly when its quite likely that the motherboard
> >> is bad and that the owner will choose to buy a new system.
>
> >>> Dust, and associated heat issues, for example may
> >>> cause an occasional freeze, and random reset.
>
> >> Not with the seagate diag.
>
> > Sure they can.
>
> Nope.
>
> > With *any* program, windows, linux, dos or otherwise.
>
> Wrong with stuff that makes few demands of the cpu.

Sorry, but just because an application isn't CPU intensive does NOT
mean the CPU won't overheat. And Seatools DOES make demands on the CPU.

>
> > If the hardware is faulty, the symptoms will always be
> > the same. No progarm is immune to basic stuff like that.
>
> If there is JUST a bad cable, any decent diag wont just lock up.

Assumptions again. Bad form.
>
> >>> So do bad caps
>
> >> Yes, but if those are bad, there isnt any point in mindlessly
> >> cleaning out the dust, swapping the cables, etc etc etc, if the
> >> owner is likely to buy a new system if it does have bad caps.
>
> > Of course not, but cleaning out the dust
> > first makes bad caps easier to see.
>
> Bullshit. You dont get much dust accumulating on the tops of the caps.

It accumulates heaviest on fans, and heatsinks to be sure. But believe
me, it does accumpulate on caps and every other place too. You can spot
slighter bulges, when they're clean.

>
> > And if the caps are so bad, that you can see right away before
> > you turn on the compresser..... you can of course stop there.
>
> With the symptoms seen, no point in bothering with any
> compressor, the only thing that makes any sense at all
> is to check for bad caps and if there bad caps, ask the
> owner what they want to do about that, because there
> is no point what so ever in checking anything at all if
> they just want to buy a new system and have the data
> moved over from the old system.
>
> > And ask the user what they want to do.
>
> >>> and bad ram.
>
> >> Ram doesnt usually go bad.
>
> > I've seen enough Bad ram to entirely disagree. It's real common.
>
> Pigs arse it is.

I've seen lots.
>
> >>> Start by fixing problem 1, and continue on until all the issues are fixed.
>
> >> Makes a lot more sense to first decide if the caps are bad
> >> and dont bother with anything else if the owner decides to
> >> buy a new system because the caps are bad and that its
> >> a good reason to upgrade to a new system now.
>
> >>> Every fan works, and every last thing is configured
> >>> to spec. That way there aren't lingering doubts.
>
> >> Stupidly inefficient way to diagnose a fault like that one.
>
> > Thorough.
>
> Stupidly inefficient and a complete waste of time when
> the owner will normally decide to buy a new system
> with a fault like that thats uneconomic to repair.


>
> >>> As for why is the diagnostic hangin? Seatools says, right while
> >>> it's loading that certian types of hard drive problems may cause
> >>> a hang (for several minutes). And please be patient. It will
> >>> continue eventually. It disables the mouse during tests, too.
>
> >> So the OP is likely to have seen that and waited long enough.
>
> > He didn't say so, therefore we can't assume.
>
> Corse you can if you actually have a clue about efficient debugging.


Efficient? Half-assed is closer.
>
> Only when there is no obvious problem like bad
> caps does it make any sense to actually try running
> it yourself to see if the owner got confused there.
>
> AFTER you have checked the event log to see
> if that has any useful information on the reboots.
>
> Essentially because its very unlikely indeed to be a
> bad hard drive when the OP got the same systems
> with two different hard drives, so the hard drive diag
> is WAY down the list of what is worth trying if you
> havent identified where the problem is.

Hence: visual inspect first.
>
> >> Much more likely that there is a serious hardware
> >> problem like bad caps or a flakey power supply.
>
> >>> There is one last thing to try, which is a bios upgrade.
> >>> Bios upgrades often address hardware incompatibilties.
>
> >> They dont just show up after the system has been working fine.
>
> > They can if new hardware is added
> > to the mix we haven't been told about.
>
> Its normally obvious enough if thats been added recently.
>
> And if the caps look fine, it makes much more sense if the
> event log doesnt show anything useful to see if the reboots
> still happen with an absolute minimum of hardware than it
> ever does to fart around checking jumpers and cables
> which arent going to produce the symptoms seen.
>
> Because if the reboots still happen with a bare minimum
> of hardware, its very likely that the system will be discarded
> so that other crap is likely to be a complete waste of time.
>
> >>> But all other possibilities need to be eliminated first.
>
> >> Wrong again. It can be the best thing to try
> >> if there is some obvious hardware incompat.
>
> > Most hardware incompatibilites aren't obvious,
>
> Which is why anyone with a clue sees if the fault
> remains with an absolute bare minimum of hardware.
>
> > and the changelogs on bioses are often
> > very vauge. Sometimes nonexistant.
>
> Sure, but thats an separate issue to your silly claim that
> all the other possibilitys need to be eliminated first.

I put this last for more than 1 reason:

1) It's a pain in the ass to get the proper bios in a lot of cases.
2) Small (but not zero) chace of rendering the computer non-bootable.
Not something to do "just because". I don't want to have to tell a
cuntomer that i accidently toasted the BIOS. You have GOT to have good
ram to do a bios flash, or you're taking a big risk.



>
> Its usually pretty obvious what can be a bios problem.

I argree, which is why it's low on the list.
>
> > I normally do bios upgrades anyway, at least on some of the
> > better systems, like Dell, where it can be done with mimimal
> > time and risk, and a high degree of certianty you got the right
> > bios. Some boards I avoid bios upgrades on, like Pcchips,
> > as they aren't very good about listing all of their boards,
> > and you can get the wrong bios too easily.
>
> Sure, but thats an separate issue to your silly claim that
> all the other possibilitys need to be eliminated first.
>
> Its usually pretty obvious what can be a bios problem.
>
> >> No need to clean the dust out first.
>
> > Yes there is, I always do just so my hands don't get icky.
>
> Your neurotic hangups are your problem.
>
> > And it aids with visual inspection.
>
> Dont need to do that BEFORE FLASHING THE BIOS.
>
> > And it may just fix a heat problem.
>
> Dont need to do that BEFORE FLASHING THE BIOS.

Yes I do, Bios flashing is not something to take lightly. You want to
maximise the chance of sucess by mimising potential for bad outcome.
>
> > My usual routine goes, open up the case, take an air compressor
> > to it if it needs it. Then look at the caps. If bad: issue identified.
> > Ask whether user wants a new motherboard or a new system.
>
> Nothing like your original, you're flagrantly dishonestly slithering
> off to somewhere completely different now after your nose has
> been rubbed in the terminal stupidity of your original claims.

I didn't tell you my usual method before. You assumed. That's a bad
trait in a supposed technician. And a constant failure of yours:
assumptions.

>
> > If caps appear good, then continue on to the rest of the
> > system: do drives have the correct cables and jumper settings?
>
> Makes a hell of a lot more sense to check the event logs first in this case.

No. Machine is already off, time is wasted powering up a machine to
check for logs, when there is an inspection to complete. It takes only
seconds, thirty at most. Booting can take minutes. In due time the
machine will be booted.

>
> And to see what the minimal config does reboot wise
> next if the event logs dont have anything useful in them.

Another reboot cycle lost. We can get to windows to check that shit
AFTER.
>
> And then try swapping the power supply next.

That's a good thing to try at some point, but, the problem is with the
hard drives, concetrate there first.

>
> > If no, rearrange to proper config.
>
> Waste of time with the symptoms seen.
>
> > Then power it up, do all the fans run? At least PSU fan, CPU fan,
> > and Northbridge and video card fan? These are sources of instability.
>
> This stuff should be checked before the jumpers too.

Not a GREAT deal difference here. As long as they're checked before
it's booted into Windows.
>
> > Failures of these key fans must be addressed to prevent
> > further damage to system. Case fans can be dealt with
> > later. But they need to be dealt with. Evenually.
>
> Not necessarily, most obviously when they arent necessary.

A detemination to make later.
>
> > Boot it up, to see it it's any obvious virus or windows problem.
>
> > Then sic diagnostic software on it: if it comes with a utility
> > partition with diagnostics, run it on the most thorough settings.
> > (fix other computers in meantime), check for heat issues
> > whilst running every so often.
>
> Makes a lot more sense to see if the
> minimal config still exhibits the problem first.

Not yet. Especially for very occasional freezes and hangs. You can wait
hours for something to happen. If you're gonna spend hours waiting, you
may as well spend it on something productive.

>
> > If no onboard diagnostic partition, or only a limited set,
> > the old standbys of memtest will do, and I've come
> > to really like MHDD (thanks to Alan for pointing it out).
>
> It wont be a hard drive problem, because he gets
> the same result with two different hard drives.

You can't eliminate hard drive failure until you actually test the hard
drives. Otherwise, it's being half assed.
>
> And its stupid having a mindless sequence regardless of the
> fault seen, grossly inefficient way to diagnose systems.
>
> > There are variations to this basic pattern, of course.
> > Depending on user complaints of symptoms.
>
> Stupid checking the jumpers first with the reported symptoms,
> because they cant be the problem. Ribbon cable too.

Assumptions again. It's not efficency, it's plain laziness and willful
neglect.
>
> > But I always do the basic visual inspection, as very
> > often the user has problems they didn't tell you about.
> > They usually tell you about the 1 or 2 most annoying.
>
> Thats only worth doing AFTER the fault has been
> fixed and is become clear that its economic to fix.

Since visual inspection IDENTIFIES the most common non-economical
fault: bad caps, it's worth always doing first. You can save a 2+ hour
virus removal project, if you would just open up the case.


>
> > They figure they can live with the rest, or figure they
> > don't want to scare you off with a giant laundry list.
> > (I've seen giant laundry lists from time to time, though :) )
>
> Irrelevant to efficient fault finding.

My computers STAY fixed, do yours?

paulmd@efn.org wrote
> Rod Speed wrote
>> paulmd@efn.org wrote
>>> Rod Speed wrote
>>>> paulmd@efn.org wrote

>>>>> Currently my top theories are bad caps,

>>>> Yes, that can produce the symptoms he is seeing.

>>>>> jumpers,

>>>> Doesnt produce the symptoms he is seeing.

>>>>> bad RAM,

>>>> Unlikely to have just started to produce those symptoms.

>>> I must disagree.

>> Your problem.

>>> But in any case, it needs to be tested.

>> Nope, not until the more likely possibilitys like bad caps are
>> checked for first, particularly as its one of the slower checks.

> A complete check takes a long while indeed. But in over
> 90% of the cases, if the ram is bad, it will be obvious
> within 5 minutes. Often times, i do abort the test early.

Still makes a lot more sense to check for bad caps and
bad power supply first, because bad memory should have
been obvious before the fault showed up, and if it wasnt,
you're going to need the longer run to see marginal memory.

And it isnt due to the memory going bad either,
it will be due to the motherboard not liking the
ram. It will work fine in a different system.

>>>>> and bad IDE controller.

>>>> Doesnt produce that reboot effect.

>>>>> But ALL possibilties need to be checked
>>>>> and eliminated before a diagnosis is made.

>>>> Effective debugging is done by concentrating on the possibilitys
>>>> that can produce the symptoms seen, not wasting time on
>>>> possibilitys that dont produce the symptoms seen.

>>> But leaving problems is bad form,

>> Not when the system is about to be discarded
>> because the motherboard caps have gone bad
>> and the owner has chosen to buy a new system.

>> Anyone with a clue just moves the data from the
>> system with a fault to the new system and discards
>> the system which has that serious a fault.

> Assumptions again.

Nope, no assumption what so ever. Just checking the
possibilitys that are likely to be uneconomic to fix first
so a minimum time is wasted on those systems which
are going to be discarded.

Its only worth checking jumpering if its very likely that
the system will be economic to repair and the fault has
been identified and you want to ensure that the system
setup properly once the fault has been identified and fixed.

>>> and, they ARE problems.

>> You aint established that that system actually has any other problem.

> If I don't check, I never will. You see the problem?

Not UNTIL the fault has been identified and fixed and you are
ensuring that there arent any other minor problems still extant.

>>>>> Bad or Wrong cable is also on the list.

>>>> Nope, that wont produce the reboot effect either.

>>>>> Little hardware problems that you don't think are the issue,
>>>>> often are.

>>>> Only if you dont actually have a clue about
>>>> what can produce particular symptoms.

>>> No,

>> Fraid so.

>>> whether or not you think they can produce symptoms.

>> I KNOW that a bad cable and incorrect jumpering
>> cant produce that reboot effect the OP is seeing.

>>> What one computer may be fine with, another may choke on.

>> Mindless waffle with that particular symptom.

>>> For example, some newish dells actually require the cable
>>> select position, and just aren't happy with master/slave.

>> STILL doesnt produce that REBOOT EFFECT, and
>> that wont produce a fault that shows up later either.

>>>>> They need to be addressed, and eliminated.

>>>> Not when the actual fault is elsewhere.

>>>>> At a minimum, They interfere with a proper diagnosis,

>>>> No they dont with symptoms like those seen.

>>>>> and they need to be fixed anyway, so no reason not to fix them.

>>>> Waste of time considering them until the fault is
>>>> found and you decide if the repair is economic.

>>>> If for example it is a bad motherboard, the owner may well
>>>> just prefer to buy a new system and move the drive contents
>>>> to the new system, and may not even want to have the old
>>>> drive in the new system, so minor config problems are irrelevant.

>>> Lets say he gets a new board, and plops it
>>> into his old case, misconfiguartions and all.

>> Not even worth considering UNTIL he
>> has decided to replace the motherboard.

>>> The old problems resurface, lazarus-like.

>> Wont happen if bad caps can be seen on the original motherboard.

>>> Or a strange new set. All due to
>>> the stuff you dismissed as irrelivant.

>> I didnt do that, I JUST SAID THAT THEY WONT
>> PRODUCE THE SYMPTOMS HE IS SEEING.

>>>>> And, well the other issues caused by them go
>>>>> away, so all around a better way of doing things.

>>>> Nope, particularly when its quite likely that the motherboard
>>>> is bad and that the owner will choose to buy a new system.

>>>>> Dust, and associated heat issues, for example may
>>>>> cause an occasional freeze, and random reset.

>>>> Not with the seagate diag.

>>> Sure they can.

>> Nope.

>>> With *any* program, windows, linux, dos or otherwise.

>> Wrong with stuff that makes few demands of the cpu.

> Sorry, but just because an application isn't CPU
> intensive does NOT mean the CPU won't overheat.

Minor dust wont see the cpu overheat when running that diag.

Yes, once the fault has been identified and fixed it is THEN
worth doing some checks that the system doesnt have any
other outstanding problems and the best way to do that is
to monitor the cpu temp while running something cpu intensive
to check the basics like whether the heatsink and fan have
been installed properly etc.

Pointless doing that until the fault has been identified and
its clear that the system is economic to fix and that the
owner isnt going to use the fault as a good excuse to
do what its been intending to do for a while now, just
replace the system with a new one, with someone else
needing to be convinced that the new system is justified etc.

> And Seatools DOES make demands on the CPU.

Like hell hit does cpu heating wise.

>>> If the hardware is faulty, the symptoms will always be
>>> the same. No progarm is immune to basic stuff like that.

>> If there is JUST a bad cable, any decent diag wont just lock up.

> Assumptions again.

No assumption what so ever. It doesnt happen.

> Bad form.

Pathetic excuse for mindless bullshit.

>>>>> So do bad caps

>>>> Yes, but if those are bad, there isnt any point in mindlessly
>>>> cleaning out the dust, swapping the cables, etc etc etc, if the
>>>> owner is likely to buy a new system if it does have bad caps.

>>> Of course not, but cleaning out the dust
>>> first makes bad caps easier to see.

>> Bullshit. You dont get much dust accumulating on the tops of the caps.

> It accumulates heaviest on fans, and heatsinks to be sure. But
> believe me, it does accumpulate on caps and every other place too.

Like hell it does.

> You can spot slighter bulges, when they're clean.

Mindlessly silly.

>>> And if the caps are so bad, that you can see right away before
>>> you turn on the compresser..... you can of course stop there.

>> With the symptoms seen, no point in bothering with any
>> compressor, the only thing that makes any sense at all
>> is to check for bad caps and if there bad caps, ask the
>> owner what they want to do about that, because there
>> is no point what so ever in checking anything at all if
>> they just want to buy a new system and have the data
>> moved over from the old system.

>>> And ask the user what they want to do.

>>>>> and bad ram.

>>>> Ram doesnt usually go bad.

>>> I've seen enough Bad ram to entirely disagree. It's real common.

>> Pigs arse it is.

> I've seen lots.

You're wrong. The vast bulk of what is claimed to be bad ram is ram
that that motherboard doenst like much or which the motherboard hasnt
been configured for properly and which works fine in a different system.

>>>>> Start by fixing problem 1, and continue on until all the issues
>>>>> are fixed.

>>>> Makes a lot more sense to first decide if the caps are bad
>>>> and dont bother with anything else if the owner decides to
>>>> buy a new system because the caps are bad and that its
>>>> a good reason to upgrade to a new system now.

>>>>> Every fan works, and every last thing is configured
>>>>> to spec. That way there aren't lingering doubts.

>>>> Stupidly inefficient way to diagnose a fault like that one.

>>> Thorough.

>> Stupidly inefficient and a complete waste of time when
>> the owner will normally decide to buy a new system
>> with a fault like that thats uneconomic to repair.

>>>>> As for why is the diagnostic hangin? Seatools says, right while
>>>>> it's loading that certian types of hard drive problems may cause
>>>>> a hang (for several minutes). And please be patient. It will
>>>>> continue eventually. It disables the mouse during tests, too.

>>>> So the OP is likely to have seen that and waited long enough.

>>> He didn't say so, therefore we can't assume.

>> Corse you can if you actually have a clue about efficient debugging.

> Efficient? Half-assed is closer.

Never ever could bullshit its way out of a wet paper bag.

Nothing half arsed about initially assuming that the user isnt
a fool and only checking something like that if it looks like the
system is fine and the problem is just that the user didnt wait
long enough. When it spontaneously reboots and chkdsk locks
up, its MUCH more likely that the diag is locking up too.

AND you dont gain a damned thing by proving that the user
didnt wait long enough with the diag if its still locking up when
chkdsk is run and its still spontaneously rebooting anyway.

Its an irrelevant detail of no significance what so ever.

>> Only when there is no obvious problem like bad
>> caps does it make any sense to actually try running
>> it yourself to see if the owner got confused there.

>> AFTER you have checked the event log to see
>> if that has any useful information on the reboots.

>> Essentially because its very unlikely indeed to be a
>> bad hard drive when the OP got the same systems
>> with two different hard drives, so the hard drive diag
>> is WAY down the list of what is worth trying if you
>> havent identified where the problem is.

> Hence: visual inspect first.

Pity you never said that initially, just now when your nose has
been rubbed in your terminally stupid approach to fault finding.

>>>> Much more likely that there is a serious hardware
>>>> problem like bad caps or a flakey power supply.

>>>>> There is one last thing to try, which is a bios upgrade.
>>>>> Bios upgrades often address hardware incompatibilties.

>>>> They dont just show up after the system has been working fine.

>>> They can if new hardware is added
>>> to the mix we haven't been told about.

>> Its normally obvious enough if thats been added recently.

>> And if the caps look fine, it makes much more sense if the
>> event log doesnt show anything useful to see if the reboots
>> still happen with an absolute minimum of hardware than it
>> ever does to fart around checking jumpers and cables
>> which arent going to produce the symptoms seen.

>> Because if the reboots still happen with a bare minimum
>> of hardware, its very likely that the system will be discarded
>> so that other crap is likely to be a complete waste of time.

>>>>> But all other possibilities need to be eliminated first.

>>>> Wrong again. It can be the best thing to try
>>>> if there is some obvious hardware incompat.

>>> Most hardware incompatibilites aren't obvious,

>> Which is why anyone with a clue sees if the fault
>> remains with an absolute bare minimum of hardware.

>>> and the changelogs on bioses are often
>>> very vauge. Sometimes nonexistant.

>> Sure, but thats an separate issue to your silly claim that
>> all the other possibilitys need to be eliminated first.

> I put this last for more than 1 reason:

> 1) It's a pain in the ass to get the proper bios in a lot of cases.

Not in the particular case being discussed.

> 2) Small (but not zero) chace of rendering the computer
> non-bootable. Not something to do "just because".

Pity you said you do that anyway with this particular motherboard.

Cant even manage a consistent line in mindless bullshit.

> I don't want to have to tell a cuntomer that i accidently toasted the BIOS.

Pity you said you do that anyway with this particular motherboard.

Cant even manage a consistent line in mindless bullshit.

> You have GOT to have good ram to do
> a bios flash, or you're taking a big risk.

Bullshit.

>> Its usually pretty obvious what can be a bios problem.

> I argree, which is why it's low on the list.

Shouldnt even be on the list at all with that set of symptoms
unless every other possibility has been carefully eliminated
and the only alternative is to discard the system or replace
the motherboard.

>>> I normally do bios upgrades anyway, at least on some of the
>>> better systems, like Dell, where it can be done with mimimal
>>> time and risk, and a high degree of certianty you got the right
>>> bios. Some boards I avoid bios upgrades on, like Pcchips,
>>> as they aren't very good about listing all of their boards,
>>> and you can get the wrong bios too easily.

>> Sure, but thats an separate issue to your silly claim that
>> all the other possibilitys need to be eliminated first.

>> Its usually pretty obvious what can be a bios problem.

>>>> No need to clean the dust out first.

>>> Yes there is, I always do just so my hands don't get icky.

>> Your neurotic hangups are your problem.

>>> And it aids with visual inspection.

>> Dont need to do that BEFORE FLASHING THE BIOS.

>>> And it may just fix a heat problem.

>> Dont need to do that BEFORE FLASHING THE BIOS.

> Yes I do, Bios flashing is not something to take lightly. You want to
> maximise the chance of sucess by mimising potential for bad outcome.

Mindlessly silly with normal dust levels.

>>> My usual routine goes, open up the case, take an
>>> air compressor to it if it needs it. Then look at the
>>> caps. If bad: issue identified. Ask whether user
>>> wants a new motherboard or a new system.

>> Nothing like your original, you're flagrantly dishonestly slithering
>> off to somewhere completely different now after your nose has
>> been rubbed in the terminal stupidity of your original claims.

> I didn't tell you my usual method before. You assumed.

Like hell I did, I read what you posted to the OP.

Not a shred of assumption involved whatever.

> That's a bad trait in a supposed technician.

Having fun thrashing that straw man are you child ?

> And a constant failure of yours: assumptions.

Not a single assumption what so ever.

Just your pathetic excuse for bullshit/lies.

>>> If caps appear good, then continue on to the rest of the
>>> system: do drives have the correct cables and jumper settings?

>> Makes a hell of a lot more sense to
>> check the event logs first in this case.

> No.

Yep.

> Machine is already off, time is wasted powering up a machine
> to check for logs, when there is an inspection to complete.

Mindlessly silly when the event logs are very likely to have useful
information in them and should have been checked first anyway.

> It takes only seconds, thirty at most. Booting can
> take minutes. In due time the machine will be booted.

Makes a hell of a lot more sense to boot the system first
before even bothering to open it to check the event logs.

>> And to see what the minimal config does reboot wise
>> next if the event logs dont have anything useful in them.

> Another reboot cycle lost.

Taint lost a thing if the system performs fine in that config.

> We can get to windows to check that shit AFTER.

Anyone with a clue does that first with those symptoms,
after the event logs and a check for bad caps.

>> And then try swapping the power supply next.

> That's a good thing to try at some point, but, the
> problem is with the hard drives, concetrate there first.

Not a shred of evidence of any problem with any hard drives.

Even someone as stupid as you should have noticed that
the symptoms didnt change with two different hard drives.

>>> If no, rearrange to proper config.

>> Waste of time with the symptoms seen.

>>> Then power it up, do all the fans run? At least PSU fan, CPU fan,
>>> and Northbridge and video card fan? These are sources of instability.

>> This stuff should be checked before the jumpers too.

> Not a GREAT deal difference here.

Wrong. Its a hell of a lot easier to check for fans spinning.

> As long as they're checked before it's booted into Windows.

Mindlessly silly. Thats what should be done first.

>>> Failures of these key fans must be addressed to prevent
>>> further damage to system. Case fans can be dealt with
>>> later. But they need to be dealt with. Evenually.

>> Not necessarily, most obviously when they arent necessary.

> A detemination to make later.

Pity you claimed they need to be dealt with. Not necessarily.

>>> Boot it up, to see it it's any obvious virus or windows problem.

>>> Then sic diagnostic software on it: if it comes with a utility
>>> partition with diagnostics, run it on the most thorough settings.
>>> (fix other computers in meantime), check for heat issues
>>> whilst running every so often.

>> Makes a lot more sense to see if the
>> minimal config still exhibits the problem first.

> Not yet. Especially for very occasional freezes and hangs.

Pity the OP didnt say that. And that is why the system should
be booted first, to see what the freeze and hang rate is.

> You can wait hours for something to happen.

Pointless if the boot logs dont indicate anything useful and
the system worked fine while they were being inspected.

Makes a hell of a lot more sense to check for
bad caps next if the event logs arent useful.

> If you're gonna spend hours waiting,

Only a fool would be stupid enough to do that.

> you may as well spend it on something productive.

Pointless wasting your time on jumpers and ribbon
cables at that stage with a fault that is rarely seen.

The other real possibilitys should be elimated first,
particularly a quick check for bad caps because it
wont usually be economic to do anything more to
the system if its got bad caps.

>>> If no onboard diagnostic partition, or only a limited set,
>>> the old standbys of memtest will do, and I've come
>>> to really like MHDD (thanks to Alan for pointing it out).

>> It wont be a hard drive problem, because he gets
>> the same result with two different hard drives.

> You can't eliminate hard drive failure
> until you actually test the hard drives.

Pointless testing the sound system too when
changing the drive made no difference.