TS vs other boards

[hillhopperwv]

It seems so far as a testimony of the objective that this forum is of better quality in technical scripting terms than others I've used. Stands to reason. I'm reminded of a comment made by an engineer at Intel about conputing errors. He said that most computer errors are not hardware malfunction, but programmer and writer errors in scripting assembly language for the processors to run. Very rarely do hardware components source out to be the culprit of errors. These machines in most cases will process anything that runs on it, whether it is true in the cultural sense or not. One has to violate the mathematical rules it recognizes in order to make it choke, not just tell it that white is black and vice versa. In short, when programmers script for machine language, they are feeding it binary logic which is a budgetary equation translated into intelligible output. Yes, you can make a computer lie to another human, but a human will have trouble convincing a machine that it not correct.

 

[Vigilante]

True. But you'd also be surprised to know that almost every hardware malfunction results in corrupted data within some program, thus having the appearance that something is wrong with the program.
Such as:

Bad hard drive can prevent a program from writing to the drive, thus causing it to freeze.
Bad RAM can send different data back to a program, causing the program to crash as it receives data it's not expecting.
Bad modem could cause a dialer to crash from wrong communications with the modem.

And the list goes on.

I'd have to say that RAM problems are the biggest cause of what might look like a software problem. I've even seen cases where only ONE program acts up, but it still turned out to be a RAM problem.

Not sure if this is the subject of your post but that's what I got out of it anyway.

 

[hillhopperwv]

Badware, soft or hard?

I suppose I should have included the fact of running diagnostic utilities such as,
"TuffTest", which checks the validity of hardware performance at the machine code level. This notwithstanding, will eliminate false positives when hardware/software processing errors are encountered. I only say this because it has proven true in my experience in running both for a good number of years. These utilities are indispensible when diagnosing errors especially when Windows runs in a "virtual reality" mode. Real time processing must preclude accuracy before virtual processing can be reliable. No? Comments welcome.

 

[Vigilante]

I think I tried TuffTest quite some time ago, don't believe I've seen it recently, I'll have to check it out.

I would guess, from what I've seen of messed up computers. That if there is a problem on a machine that has been "working fine" for a long time then suddenly doesn't, I'd give it a %90 chance that it is software related. Some random corrupt file or DLL, new spyware or a virus etc...
If the machine is new, or was just purchased, or hasn't been in service long, and it acts up, I give it more of a %70 chance of being software only problem. Especially because you don't know the working history of the system.

I use those two factors to decide whether I should tackle software diagnostics or hardware first. Although one might turn into the other. I have a pretty good sense of what side to check based on certain questions. "Anything new to the system?" (such as Antivirus or other software? Just went to high speed Internet? Got RAM upgrade a week ago? Uninstalled a program you thought was bad? Just moved from out of town? Etc...)

Even in super-rare occasions I've seen one side leak to the other. Case in point: If XP is installed on a machine that has bad RAM, thus causing problems in XP, and the RAM is replaced, XP may still act up. Not sure how, but corrupt data from bad RAM during install causes permanent errors in XP subsystem. Thus, replace the RAM, and have to reload again.

If you are talking about programming, then I would assume for SURE that a person would want to run hardware testers, TuffTest, benchmarks, stress testers, and so forth, to make sure the hardware is good during design time. To make sure any peculiars of his program isn't related to faulty hardware.

But surely, the easiest way to decipher whether a problem be hardware or software, is the drilling of information from the owner.
The only times I've seen a system have hardware problems on a machine that has a good history, would be things like:

Random hard drive crash
Invalid shutdowns (power out etc..)
System or CPU overheat
Underpowered power supply

And other such things that can happen over time. I see a lot of systems getting blown capacitors on the motherboard these days too. Likely from cheap OEM PS's that gradually decay over time.

Lastly, I'd say from all the systems I've worked on, software problems outweight hardware ones. But the hardware problems are not often easy to find without first reloading a machine to see if, what appears to be a software problem, will go away. But on the same note, what appears to be a software problem, can take hours from you when all it is is corrupt sector of the hard drive.

I guess that's why there aren't really any "hardware only" or "software only" techs out there.