On Wed, 29 Aug 2007 21:32:29 -0500, "Ken Maltby"
<kmaltby@sbcglobal.net> wrote:
>
>"kony" <spam@spam.com> wrote in message
>news:j9qbd3d0354a01npsscbl4af8hstl7h4au@4ax.com.. .
>> On Wed, 29 Aug 2007 15:18:02 -0500, "Ken Maltby"
>> <kmaltby@sbcglobal.net> wrote:
>>
>>>
>>>"Noozer" <dont.spam@me.here> wrote in message
>>>news:JkiBi.104337$rX4.39427@pd7urf2no...
>>>>> This may be a long shot, but try cleaning up any startup
>>>>> related software/OS drivers. Especially keyboard related,
>>>>> and in your case anything that might be connected to,
>>>>> wake on LAN, or such.
>>>>
>>>> How could ANY software/OS cause the PC to freeze during POST?
>>>>
>>>
>>> The OP was that it was "Inconsistent" and happening
>>>"within 4 min. of cold power up" and "on ONE occasion
>>>it locked up in the middle of entering the BIOS password".
>>>
>>> But to answer -your- question; in the same way a boot
>>>block virus works. There is more interaction possible
>>>than you appear to be aware of.
>>
>> There is less interaction possible than /you/ appear to be
>> aware of. A boot block virus isn't running until the system
>> attempts to boot from that drive.
>
> Which occurs right after the POST, well within the 4min.
>mentioned.
There is no software factor including boot sector viri,
which impede entering the bios menus. The machine has
already demonstrated it is a hardware failure at that point.
While it is /possible/ there is also a software failure,
untill the initial hardware failure is resolved it would be
premature to assume it.
>
> You are aware that there are programs that even rewrite
>the BIOS from XP?
Yes, they have to have some intelligence of the specific
board to work. Show us even one virus that can write to
this board.
> If interaction at the level of totally
>rewriting the BIOS are possible, why do you find it so hard
>to understand that some of the data that the BIOS must
>use can also be changed, is it just because I'm the one
>pointing it out?
What is theoretically possible, but never shown to exist
with capability to flash the OP's board, is a scenrio so
unlikely it would not be reasonable to consider unless there
was evidence suggesting it.
There are too many things to even enumerate that are
possible if we can't play odds at least a little bit. There
is no reason to think the bios has been written to, and
particularly not that it had been written to but remained
intact enough to POST the system only locking up soon
thereafter. The odds are far lower than 1 in a million.
>
> But I would also direct you to any definition of the term
>"Long Shot". This is based on an actual startup problem
>I had with one system of mine, and it did turn out to be
>caused by a keyboard driver problem. It would lock
>things up so that it wouldn't even POST. Pressing the
>Power Button or shorting the pins wouldn't start the sys,
>even with the little green light on the MB glowing.
On a restart maybe, but this was a problem from a
powered-off, cold start. No driver will effect getting into
the bios menu from a cold start.
>
> I have no way of knowing if this has anything to do
>with the OP's problem, but it is possible. It is a long
>shot worth the trouble of plugging in a different simple
>keyboard. (One not designed to work with whatever
>enhanced drivers there may be on the problem sys.)
If the OP feels the keyboard is faulty, certainly another
should be tried. If the keyboard otherwise works once the
system is running (which it seems to do once ran and
restarted), having the keyboard only exhibit this problem
upon a cold start is also exceedingly unlikely.
"kony" <spam@spam.com> wrote in message
newskmcd3l8l0shdkt0rasdech8vrpor72ndp@4ax.com...
> On Wed, 29 Aug 2007 21:32:29 -0500, "Ken Maltby"
> <kmaltby@sbcglobal.net> wrote:
>
>>
>>"kony" <spam@spam.com> wrote in message
>>news:j9qbd3d0354a01npsscbl4af8hstl7h4au@4ax.com. ..
>>> On Wed, 29 Aug 2007 15:18:02 -0500, "Ken Maltby"
>>> <kmaltby@sbcglobal.net> wrote:
>>>
>>>>
>>>>"Noozer" <dont.spam@me.here> wrote in message
>>>>news:JkiBi.104337$rX4.39427@pd7urf2no...
>>>>>> This may be a long shot, but try cleaning up any startup
>>>>>> related software/OS drivers. Especially keyboard related,
>>>>>> and in your case anything that might be connected to,
>>>>>> wake on LAN, or such.
>>>>>
>>>>> How could ANY software/OS cause the PC to freeze during POST?
>>>>>
>>>>
>>>> The OP was that it was "Inconsistent" and happening
>>>>"within 4 min. of cold power up" and "on ONE occasion
>>>>it locked up in the middle of entering the BIOS password".
>>>>
>>>> But to answer -your- question; in the same way a boot
>>>>block virus works. There is more interaction possible
>>>>than you appear to be aware of.
>>>
>>> There is less interaction possible than /you/ appear to be
>>> aware of. A boot block virus isn't running until the system
>>> attempts to boot from that drive.
>>
>> Which occurs right after the POST, well within the 4min.
>>mentioned.
>
> There is no software factor including boot sector viri,
> which impede entering the bios menus. The machine has
> already demonstrated it is a hardware failure at that point.
> While it is /possible/ there is also a software failure,
> untill the initial hardware failure is resolved it would be
> premature to assume it.
>
>
>>
>> You are aware that there are programs that even rewrite
>>the BIOS from XP?
>
> Yes, they have to have some intelligence of the specific
> board to work. Show us even one virus that can write to
> this board.
>
>> If interaction at the level of totally
>>rewriting the BIOS are possible, why do you find it so hard
>>to understand that some of the data that the BIOS must
>>use can also be changed, is it just because I'm the one
>>pointing it out?
>
> What is theoretically possible, but never shown to exist
> with capability to flash the OP's board, is a scenrio so
> unlikely it would not be reasonable to consider unless there
> was evidence suggesting it.
>
> There are too many things to even enumerate that are
> possible if we can't play odds at least a little bit. There
> is no reason to think the bios has been written to, and
> particularly not that it had been written to but remained
> intact enough to POST the system only locking up soon
> thereafter. The odds are far lower than 1 in a million.
>
>
>
>
>>
>> But I would also direct you to any definition of the term
>>"Long Shot". This is based on an actual startup problem
>>I had with one system of mine, and it did turn out to be
>>caused by a keyboard driver problem. It would lock
>>things up so that it wouldn't even POST. Pressing the
>>Power Button or shorting the pins wouldn't start the sys,
>>even with the little green light on the MB glowing.
>
> On a restart maybe, but this was a problem from a
> powered-off, cold start. No driver will effect getting into
> the bios menu from a cold start.
>
>
>>
>> I have no way of knowing if this has anything to do
>>with the OP's problem, but it is possible. It is a long
>>shot worth the trouble of plugging in a different simple
>>keyboard. (One not designed to work with whatever
>>enhanced drivers there may be on the problem sys.)
>
>
> If the OP feels the keyboard is faulty, certainly another
> should be tried. If the keyboard otherwise works once the
> system is running (which it seems to do once ran and
> restarted), having the keyboard only exhibit this problem
> upon a cold start is also exceedingly unlikely.
Well the keyboard that I replaced worked fine when the
system was running, and still runs fine in another system,
(without the enhanced drivers). It ran fine as a keyboard
except when it was killing the restart of the system. Even
when it was shutdown with the power key and the switch
on the PSU turned off for a while, cold enough for you?
I could agree that it is an odd, probably rare occurrence,
but it did happen to this one system of mine. It gets a
little tiring to listen to you saying that what I've seen with
my own eyes, is not possible. Let's see, Kony and his
theory or objective reality, I'll take the evidence of my own
eyes. It could be that it was a coincidence that when the
keyboard was changed and the drivers removed, the system
could be started reliably again. But I find that highly unlikely.
The OP has nothing to loose trying another keyboard, and
since it is a long shot, the odds are that it won't be the answer
to his problem. Why you are so dead set against even
considering the possibility, could be another question.
kony wrote:
>
.... snip ...
>
> There is no software factor including boot sector viri, which
> impede entering the bios menus. The machine has already
> demonstrated it is a hardware failure at that point. While it is
> /possible/ there is also a software failure, until the initial
> hardware failure is resolved it would be premature to assume it.
I have to disagree. To illustrate, consider a machine with a
pluggable ROM bios. Unnplug the bios. You will no longer be able
to boot, or to enter any bios menus, etc. Yet normal operation
would be unaffected if you could remove the ROM while running,
because normally the entire bios is over-ridden by opsys code.
If you just want to say 'unlikely', I will agree.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
On Thu, 30 Aug 2007 05:07:17 -0400, CBFalconer
<cbfalconer@yahoo.com> wrote:
>kony wrote:
>>
>... snip ...
>>
>> There is no software factor including boot sector viri, which
>> impede entering the bios menus. The machine has already
>> demonstrated it is a hardware failure at that point. While it is
>> /possible/ there is also a software failure, until the initial
>> hardware failure is resolved it would be premature to assume it.
>
>I have to disagree. To illustrate, consider a machine with a
>pluggable ROM bios. Unnplug the bios. You will no longer be able
>to boot, or to enter any bios menus, etc. Yet normal operation
>would be unaffected if you could remove the ROM while running,
>because normally the entire bios is over-ridden by opsys code.
>
>If you just want to say 'unlikely', I will agree.
Remember the system when cold/off, does post and run up
until the point where it locks up. This means it does read
and run the bios from the EPROM, but is then instable.
Unplugging the EPROM would make this much impossible, so
based upon what the system could do, but then where it
stopped, we have eliminated some things.
Maurice Batey wrote:
> On Wed, 29 Aug 2007 19:02:07 -0400, CBFalconer wrote:
>
>> What does this have to do with what?
>
> Merely to add that those tests were tried, rather than overlooked.
?? What tests? What problems? On what?
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
kony wrote:
> <cbfalconer@yahoo.com> wrote:
>> kony wrote:
>>>
>>... snip ...
>>>
>>> There is no software factor including boot sector viri, which
>>> impede entering the bios menus. The machine has already
>>> demonstrated it is a hardware failure at that point. While it is
>>> /possible/ there is also a software failure, until the initial
>>> hardware failure is resolved it would be premature to assume it.
>>
>> I have to disagree. To illustrate, consider a machine with a
>> pluggable ROM bios. Unnplug the bios. You will no longer be able
>> to boot, or to enter any bios menus, etc. Yet normal operation
>> would be unaffected if you could remove the ROM while running,
>> because normally the entire bios is over-ridden by opsys code.
>>
>> If you just want to say 'unlikely', I will agree.
>
> Remember the system when cold/off, does post and run up
> until the point where it locks up. This means it does read
> and run the bios from the EPROM, but is then instable.
>
> Unplugging the EPROM would make this much impossible, so
> based upon what the system could do, but then where it
> stopped, we have eliminated some things.
Ah, that's different than the scene I envisioned. Conceded.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
On Aug 30, 6:41 am, Maurice Batey <maur...@bcs.removethis.org.uk>
wrote:
> Will resume battle on return on Sunday.
> Many thanks for all your efforts to help; much appreciated...
> Have nice weekends, folks!
You have a long list of wild and wanton suggestions. A new keyboard
is not relevant to your problem. Either is some mysterious virus that
exists only in wild speculation.
Kony has provided a responsible list of suspect. This poster was
doing this stuff multiple generations ago. Kony's list is what you
should be concentrating on - and ignore so many other posts based only
in speculation - it could be this or could be that follows by "so
replace it".
The suspect list is where to begin looking for irrefutable facts -
where you 'follow the evidence'. Too many are saying "I suspect it
must be this, therefore it must be this; so replace this". That can
even make the problem exponentially more complex.
Notice after so much work, your accomplishment is zero. You still
don't even know what in the computer is good. Swapping also does not
verify things good.
Get a 3.5 digit multimeter. A tool so simple and so ubiquitous as
to be sold even to K-mart shoppers. IOW if you fear the meter, then
you have no business even trying to fix the computer. Get the meter.
Take some voltage measurements. Where to get those DC voltage numbers
from is listed in "When your computer dies without warning....."
starting 6 Feb 2007 in the newsgroup alt.windows-xp at: http://tinyurl.com/yvf9vh
In your case, most important numbers are voltages on any one of
orange, red, purple, and yellow wire from power supply to motherboard
just after power switch is pressed. Post those numbers here to learn
even more useful information. Now we have definitive facts - no more
"it could be ..."
IOW first establish power supply 'system' integrity. Yes the power
supply is only one part of that 'system'. If you don't establish
'system' integrity, then 'try this and try that' will take weeks.
Above procedure means the few technically informed here can then post
something useful. Numbers obtained in two minutes.
Another suggested BIOS battery. Only ten second with the meter
provides that number. We remove nothing (because a better number
means the battery stays connected to motherboard). We then know if a
battery is defective OR we know that battery is good. IOW we
accomplish something. But that means numbers and a meter.
Why so few useful responses? A direct reflection of information
provided in your posts. Having provided so few useful facts, then one
is even claiming some nonsense about a virus. Ignore those posters.
There is nothing wrong with the Eprom, as Kony posted - obviously.
But then so many who *know* computers don't even understand what he
posted about BIOS operation. They are the sources of wild speculation
even about overheating.
Take only two minutes. Get those power supply voltage numbers. Post
them here. Obtain useful replies. Only then have you accomplished
something by establishing one subsystem as good. Notice what it takes
to 'follow the evidence' AND accomplish something.
Currently you have a near zero list of good subsystems - and too
many useless replies. You want replies that are useful? Start by
defining what is 'definitively good' and 'definitively bad'. That
means numbers. Provided is where to look for facts:
> Cold power up problems tend to be either power supply, flaky
> motherboard capacitors, a bad mechanical connection or a PCB
> problem such as bad solder joints or board cracks, though
> the former two are a lot more common than the latter two.
Since the power supply can make anything or everything look
defective, then we first establish its integrity - two minutes with a
multimeter and then post those numbers.
IOW we fix things only by 'following the evidence'. Which item on
that list is know good after all this time? None. Nothing was
accomplished. That virus? Show me how he concluded by following the
evidence. He did not. That post demonstrated how many *computer
experts* don't even know how a computer works - don't even know how
electricity works - why they are experts only because they speculate.
Re: Hardware problem 
kmcd3l8l0shdkt0rasdech8vrpor72ndp@4ax.com...
Linear Mode
