Just
like for Kony it's always a heat related problem or failing
capacitors.
I again invite you to look over my past posts and prove your
statement that I frequently claim "it's always a heat
related problem", with the exception of cases where the OP
had already indicated as much, or there was a direct link
like a failing fan.
If you haven't seen much gear with failing capacitors, I
suggest you haven't seen much gear. I can't will a cap to
pop, but once it does there is little speculation needed -
to merely look inside a computer is an obvious enough
suggestion to make when troubleshooting hardware, and while
one is inside, they might as well move an eyeball or two
towards the vicinity of the capacitors. It is quick, easy,
free, and requires no special ability on the part of the
person looking except to recognize that a cap should be flat
on top, stand up straight, and not have crusty residue
leaking out.
If I had ever seen or even heard of one single virus that
flashed any semi-modern motherboard bios and this resulted
in the board posting but then locking up, I might then
consider it worth mentioned from time to time. Instead I
only mention things that have any reasonable chance of
happening without some indication of an unusual
circumstance.
My posting about a similar situation where the cure turned
out to be replacing the keyboard and its drivers, was offered
because it was one rare case where traditional troubleshooting
didn't provide the answer. It was a "long shot" that I wouldn't
expect to be considered, in the normal troubleshooting process.
(Which is the very reason I felt it needed bringing up.) Because
it fixed a very similar problem I thought it might benefit the OP.
There's no need to be defensive, we're all just throwing out
ideas. Nobody is going to guess right immediately, 100% of
the time, but some things are far less likely and/or
contrary to the evidence presented. Group collaboration can
reduce the magnitude of things someone troubleshooting would
need try, and hopefully reduce the time and expense to get
the system working right again.
Most of the ammunition for your arguments against the postings
here comes not from statements addressing the OP's problem, but
from my replies to Kony's knee jerk reaction to my posting.
That's an interesting statement, considering I had posted
nothing to this thread yet when you wrote:
"Have you and "Grinder" been replaced by "kony" clones?"
While your suggestion about drivers and bios can help, maybe
even solve some seemingly related problems, in this case
there was a specific reason to believe it could be ruled
out. The only way to narrow the focus and have someone try
a few targeted things, is to also rule out the hundreds if
not thousands of things that don't need to be considered.
When a cold-off system locks up before one can even get into
the bios menu, which is necessarily before it has ever tried
to read anything from the hard drive, when the only thing
running as of yet is the decompressed bios, we know there is
no software issue because there is no software running yet,
nor any chance a volatile register held the wrong values -
because it was a clean boot from cold off, something the
system had to have been doing correctly up until the problem
started.
I
foolishly thought I could provide some information to show why
it is possible, countering Kony's claims that it wasn't. I should
have known that nothing I could say, would allow Kony (or such
as you) to see that anything but their suggestions could have merit.
I suppose if I was a virus writer, and knew the specific
board someone had, it would be possible to target them and
write something to NV memory that would allow a system to
POST but be instable, and yet, there'd be a checksum error
and if this was just an inappropriate configuration value
that prevented the board from running stabily, clearing CMOS
should resolve it. I suppose if we wanted to stretch things
even further, it might be possible to redo the entire bios
such that it passed the checksum test and then was instable,
but how many hours of work and motherboards would the hacker
have to have, identical to the target system? Some ideas
are just so "out there" that until there is one single
example, we have to ignore what is theoretically possible.
If we want to talk theory, in theory a snake might have
crawled inside and done some damage. I have actually had a
system someone brought that had a snake in it (they had
removed the snake before bringing it), and I vaguely recall
a web picture of a snake in a PSU. With these two examples
of snakes in systems, I have more reason to suggest looking
for snakes than you would to wonder about a bios flashing
virus that leaves the system posting, and yet you are
welcome to scavenge my posts to see if I've ever mentioned
snakes in systems except for this example - because it's
just not likely enough to mention.
I don't actually know if the possible explanations I provided were
the ones at work in the situation I was describing, I do know that
the actions I took and described, fixed the problem. It is certainly
possible that totally different factors were in play, that I did not
detect. I do know that what I did worked, when changing good
MBs, cases, processors, memory, and yes power supplies, did
not isolate or fix the problem.
I certainly hope that the readers don't buy into Kony's or your
position that only postings that meet your approval or that you
originate, are worth considering.
I'm sorry I got you bent into a knot Ken, the goal here is
to solve the OP's problem and if I know based on the
evidence that it can't be software or drivers, shouldn't I
have mentioned that instead of having the OP try things that
won't fix the problem? The OP made no mention of changing
drivers just prior to the onset of the problem, and the
system is now 3 years old. While we can't be guaranteed the
OP has not changed drivers, we can only go on what has been
written, and have to assume if there is no driver change
mentioned, there is no driver change... and if there is no
driver change, it should not now be locking up because of a
driver when it had ran same driver previously, UNLESS there
is some other hardware problem too... and if there is some
other hardware problem, it'll have to be solved at least
enough that the system is not locking up even at entry to
the bios before drivers can even be considered.
We don't know that there isn't a driver problem, but we do
know there is at least one problem not related to drivers,
causing an instability. It is exceedingly difficult to try
to troubleshoot OS or drivers when the hardware isn't even
stable yet before loading any software.
